The three events
A long-running agent often has to wait for a person: approve a contract, release a payment, sign off on a deploy. Actae records the request and the verdict as ordinary channel events — replayed, streamed, and visible in the dashboard like any other event.
approval.requested— the agent asks, with a summary, optional details, and an optional timeout.approval.decided— a human or service answersapprovedorrejected, with an optional reason.approval.expired— the wait timed out.
The agent does not stay alive
When a timeout is set, Actae schedules a persisted wake-up so the deadline survives restarts. The agent can exit after the request; a worker that later replays the channel sees the decision and continues. Actae never resolves the request and never resumes the agent — the application reads the verdict and acts.
Request, decide, wait
The SDKs expose three helpers over the events. request_approval records the request (and the wake-up); decide_approval records the answer; wait_for_approval observes it (poll-based, restart-safe), or use stream() for lower latency.
- Idempotent per decision: a retried or duplicated decision replays the original event. A different decision is recorded as a new event — the application applies last-wins.
- Durable across restarts: the request, decision, and timeout live in PostgreSQL.
- Not an authorization system: Actae records that a decision was made; it does not authenticate the approver. Put that in your application or control plane.
Pair it with a fork's tool policy so an approved fork cannot re-fire the side effect the approval was about.