Temporal jest dojrzalszym fundamentem durable execution. Nie jest gotowym Organization OS: role, kontrakty organizacyjne, domenowe rekordy, polityki akcji i interfejsy pracy ludzi trzeba zaprojektować w aplikacji.
Gdzie zakres się pokrywa
Temporal utrwala historię workflow i wznawia wykonanie po awarii. Signals i Updates pozwalają zatrzymać workflow na decyzję człowieka. Wzorce agentowe traktują wywołania LLM i narzędzi jako Activities, dzięki czemu efekty nie są ponawiane podczas replay. Subactor również prowadzi długotrwałe procesy, lecz definiuje je jako kroki URI powiązane z aktorami, zatwierdzeniami i oczekiwaniami dowodu.
| Obszar | Temporal | Subactor |
|---|---|---|
| Podstawowy artefakt | Workflow napisany w kodzie | Kontrakt + plan + URI Process |
| Odporność na awarie | Replay historii i trwałe Activities | Stan ticketu, retry, receipts i kontrolery |
| Human-in-the-loop | Signals/Updates oraz logika aplikacji | Osobne zadania ludzi, approvals i routing kanałów |
| Polityka uprawnień | Budowana w aplikacji | Kontrakty aktorów, delegacje i exact URI |
| Model organizacji | Brak gotowego modelu | Kanoniczne domeny i rekordy Organization Core |
Najważniejsza różnica
Temporal jest warstwą niezawodnego wykonania aplikacji. Nie narzuca języka organizacyjnych kontraktów ani modelu odpowiedzialności. Subactor narzuca te granice i dopiero potem wybiera trasę wykonania. Z drugiej strony Temporal ma silniejsze, wieloletnie prymitywy replay i durable state; Subactor nie powinien przedstawiać własnego runtime'u jako zamiennika tych gwarancji bez wspólnego benchmarku awarii.
Kiedy wybrać lub połączyć
- Temporal: długotrwałe, kodowe procesy rozproszone, w których kluczowe są retry, replay i odporność na awarie.
- Subactor: gdy problemem jest także przypisanie uprawnień, ról, domen organizacyjnych, kanałów reakcji i dowodów wykonania.
- Razem: Temporal może realizować trwałą semantykę URI Process, a Subactor pozostać control plane kontraktów i odpowiedzialności.