Agent loop

The agent loop runs host-side. A turn is many model requests and tool calls, each under its own wall, and each tool call is one tenant invocation judged against the turn’s authority.

The prompt

The system prompt is static per workspace release — the kernel prompt, the brief (+agent.md, or +agent.external.md for external members), an envoy’s task, and the skills list — and byte-identical from turn to turn, so providers can cache it. Per-turn facts come in each message’s sender header, or from the context tool.

Authority

An in-app turn runs as the member. An envoy turn runs as the envoy under its policies, joined in a direct message by the linked member’s own authority. The tool catalogue is filtered by the turn’s grants and capabilities on every turn.

Steps and budgets

A turn has at most 40 steps. Tool results are bounded — rows to 16 KiB, with clipped cells saying so — and read_output reads the rest. Compaction runs when the previous request’s input exceeds 90% of the model’s window, or on overflow, at most three times per turn.

Receipts

Every write outcome of a turn is appended to its reply — an outcome card in the app, a fixed line in a conversation — and a held write is reported as awaiting approval. Internal error text never reaches a public sender.

Triage

With triage on, a message that is not a mention, a reply or send-now waits as pending, and a debounced sys_1 decision admits it (respond), waits for more (wait), or, in a group, leaves it ambient (ignore). A direct conversation is always for the agent, and a failed decision admits.

Delegation, plans and goals

With delegation enabled the agent has subagent: a sub-agent turn runs under the delegating turn’s authority, never wider. A plan’s completion is checked by an independent verifier run, and an incomplete verdict sends the plan back to work.