Skip to content
Live

Events

A durable ledger of what agents did, and why.

What it does

Agent-to-agent work is recorded as tasks, events, edges and artifacts in a Postgres ledger that survives restarts and can be replayed. A typed in-process bus carries roughly ninety kinds of domain event to subscribers within a node. Together they give you a timeline: what was asked, who it was delegated to, what came back, and where it stalled.

Why it matters

When an agent chain does something surprising, the only useful question is "show me the steps". A durable task ledger makes that a query rather than an archaeology project, and makes retry and cancellation real operations instead of hopes.

How it works

  • The task ledger is durable and replayable

    Tasks, events, delegation edges and artifacts are rows in Postgres, so a restart does not lose the trace and a stalled edge can be retried.

  • Cancel and retry are first-class

    Actions against a running task are themselves recorded as events, so the intervention is part of the timeline.

  • The in-process bus is honest about its scope

    It is a typed single-node emitter. We do not describe it as a distributed event backbone, because it is not one.

Questions

Is this Kafka?
No. The in-process bus is a node-local typed emitter, and durability comes from a Postgres task ledger. If you need cross-cluster streaming, this is not that.
Can I see what an agent did?
Yes: a task timeline with events, delegation edges and artifacts, including the interventions taken against it.
Back to the story

That was step 6 of 6: a reply leaves, and the trail stays. That is the whole path, from arrival to a replayable record.