Opbox runs AI agents under a real org chart, and every move an agent makes goes through the same governed front door a person does. The agent log is where you watch that work: the queue of tasks the agents are pulling from, the stream of actions an agent took on a matter or table while you were away, and the runs of automated flows, each with its status and last error. Nothing here is a separate logging system - every panel is a read over the one permanent, tamper-evident record the kernel already keeps, so what you see is exactly what happened.
What it does
The agent-task queue, read-only. Agents work from a task queue, and the log shows it: each task with its verb, its status, its last error if one was set, and the matter it belongs to. You can narrow the list to a single status. This is observability, not control - there is no task-creation or approval action on this surface, only the live picture of what the workforce is doing.
The per-matter agent-action feed. Open a matter or a table and you can replay exactly what an agent did to it: the verbs it called, who the actor was, where the call came in from (the command line, the web front door, or the agent’s own MCP channel), and when. This is the retrospective “what did the agent touch while I was away” view, scoped to one matter or table and read-gated to people who can already see that record. It is a projection over the audit log, not a second store, so it can never drift from the truth.
The run roster and a run’s detail. Automated flows execute as runs. The log lists them - kind, status, and the last error if one occurred - and opening a run row shows that run’s full status inline. From the detail you can act: cancel an in-flight run, retry a failed one, or resume a failed one from where it last checkpointed. Cancelling fires the abort signal the connector honours mid-read, so a long-running flow stops cleanly rather than being left to finish.
The workspace audit search. Above the agent surfaces sits a faceted search over the full audit log: filter by verb, by actor, and by a since-timestamp, then search. This is the admin lens on the permanent record - every governed call, by every actor, written append-only. The same record underpins the per-matter feed; this is the unscoped, workspace-wide view of it.
Convenings, when you need the chain of command. When an agent convenes another agent or a panel, that hand-off is itself a queryable, attributed record. You can read one convening with its seats’ status, verdicts, and spend, or list the live and recent convenings in the workspace - the attributed trail of which agent asked which other agent to do what.
One record, four windows. The task queue, the action feed, the run roster, and the audit search are not four databases. They are four read shapes over the same governed event log and work tables the kernel writes on every call. Because an action by an agent and an action by a person pass through the identical front door, they leave the identical kind of record, so the log treats them the same and proves the same things about both.
How you use it
Watch the queue. Open the agent tasks view to see the workforce’s current load: every task, its verb, its status, and its matter. Narrow to a single status, or to a single matter, when you want to focus.
Replay what an agent did to a matter. From a matter or a table, open the agent-action feed and read the stream of actions. Filter by actor or by verb to home in on one slice, and read each row’s verb, actor, source, and timestamp to reconstruct precisely what changed - including whether the call came in from chat and the web front door, the command line, or the agent’s MCP channel.
Steer a run. Open the ops console, find the run in the roster, and click into it for the full status. From there, cancel a run that should stop, retry one that failed, or resume a failed one from its last checkpoint - the same governed verbs, audited as you fire them.
Search the record. Use the audit search to answer a specific question - what did this actor do, when did this verb last fire - by setting the verb, actor, and since filters and searching. An empty result tells you to broaden the filters rather than guessing.
Trace a hand-off. When one agent convened another, read the convening to see its seats, their verdicts, and what each spent, so a multi-agent decision is as legible after the fact as a single action.
The kernel verbs behind it
Each goes through the one front door - permission-checked and audited before it runs (see Security & permissions). These are the verbs most specific to the agent log.
The agent-task queue and its lifecycle:
agenttask.list- the read over the agent-task queue, with each task’s status and last error (the queue view; no new store).agenttask.create- put a task on the queue for an agent to pick up.agenttask.claim- claim a task for the current actor.agenttask.checkpoint- record progress on an in-flight task.agenttask.escalate- raise a task up the chain when it needs a higher hand.agenttask.requeue- put a task back on the queue to be tried again.
Runs of automated flows:
run.list- the run roster, scoped to what you can see.run.status- one run’s full state and last error.run.start- begin an execution of a flow.run.cancel- cancel an in-flight run (fires the abort signal the connector honours mid-read); a re-cancel of a terminal run is a no-op.run.retry- run a failed execution again.run.resume- re-drive a failed run from its last checkpoint.
The action feed, convenings, and the permanent record:
data.audit.feed- the per-matter or per-table, actor-filtered stream of what an agent did, with the cells and rows touched.agent.convening.get- read one convening with its seats’ status, verdicts, and spend.agent.convening.list- list the live and recent convenings in the workspace.audit.query- search the immutable, append-only event log by verb, actor, and time.audit.feed- follow the workspace-wide audit stream.audit.chain.verify- prove the audit chain has not been tampered with.
See the full set in the agenttask, run, and audit verb references.