You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/understand/agent-runtime.md
+13Lines changed: 13 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,15 @@ A task is a small JSON document in a diary-scoped queue that says "someone wants
16
16
17
17
Every task lives inside a diary. Whoever can read the diary can see the task; whoever can write the diary can claim it. Pack-like artifacts (rendered packs, context packs) flow through the same queue as judgments and reviews — the type is how you tell them apart.
18
18
19
+
For producer-style task types (`fulfill_brief`, `curate_pack`, `render_pack`,
20
+
`run_eval`), the server normalizes the stored `input` before computing the
21
+
task's `inputCid`. If the caller did not provide `input.successCriteria`, the
22
+
server creates it and injects a built-in `submit-output` gate. That gate says,
23
+
in effect: "call `submit_<task_type>_output` exactly once with valid structured
24
+
output." This matters because the submit-tool call is part of the promise body,
25
+
not an executor-only implementation detail. The stored input, the prompt the
26
+
claimant reads, and the later audit trail all describe the same contract.
27
+
19
28
### Imposer vs claimant boundary
20
29
21
30
The runtime model depends on keeping the two roles cleanly separated.
@@ -195,6 +204,10 @@ The guarantees are worth naming, because they shape everything else:
195
204
196
205
-**Claims are agent-initiated.** The queue never pushes. Agents that want work call `claim()`; agents that don't, don't. `task.claim` requires a Keto permit — capability without obligation.
197
206
-**Promises are content-addressed.** The imposer's brief is pinned by an `input_cid`; the claimant's output is pinned by an `output_cid` and optionally signed. Both sides have cryptographic proof of what was promised and what was delivered.
207
+
-**Basic completion gates live inside the promise.** For producer task types,
208
+
"did I submit the structured output?" is represented as a built-in
209
+
`successCriteria.gates[]` item, so the claimant self-assesses it like any
210
+
other criterion instead of the substrate pretending it can coerce the action.
198
211
-**Abandonment is benign.** A crashed or timed-out claimant loses the lease; the task returns to the queue. Nothing is recorded as a failure on the agent's identity — the promise simply wasn't kept, and someone else can pick it up.
199
212
-**Cancellation is asymmetric.** The claimant can walk away (withdraw consent to finish); a diary writer can also take the task back (withdraw the offer). Both are state transitions, not blame.
200
213
-**The runtime has no retry logic.** Retries happen at the queue level, as fresh claims by whoever's next. There's no catching and re-dispatching inside the executor — one attempt, one outcome, the workflow decides what's next.
0 commit comments