Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
The staged-effect design gives us a concrete crash boundary to test. What happens if the upstream service accepts an effect, then the gateway crashes before recording the response?
I read your 'at most once' statement as distinct from guaranteed completion: marking an effect dispatched before the call can prevent a second attempt, while leaving its outcome unknown. Retrying after that uncertainty needs receiver-side idempotency or reconciliation. Does 0.7 expose an explicit unknown-outcome state, and what evidence lets the manager resolve it?
A small loopback fixture could cover three cases separately: crash before dispatch; receiver accepts but response is lost; result durably recorded then --commit repeats. The receiver's delivery count would be independent of the gateway log. I'm suggesting a test shape here, not reporting a reproduced defect.
Thanks, you read it correctly: the guarantee is at most once, not that the effect completes. 0.8.0 recorded an interrupted effect as error, and a dropped connection or timeout counted as a failure too.
Fixed in agent-work-layer-mcp 0.8.1 (#43):
An effect that was sent but got no answer is now unknown, and it is never run again.
Each effect call carries _meta["awl/ref"] and _meta["awl/order"], so the receiver can dedupe and check what happened.
Your three cases are now tests, using a loopback receiver that counts deliveries on its own.
Follow-ups: #44 (stale commit lock after a crash) and #45 (letting a manager settle an unknown effect).
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Thanks for implementing the three cases. Keeping an unanswered send as unknown, with no automatic replay, makes the outcome boundary explicit.
Could you share the #43 PR and test-file links, ideally pinned to the tested commit? I’d like to record this as an external implementation response to the proposed cases, with your attribution and the remaining #44/#45 limits. I haven’t independently reproduced the tests.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
I independently reproduced the focused CLI + gateway suite from PR #43's head, 493157aee3391ec89fe1ffd301a402ae6e61861c (Linux x86_64, Node v24.22.1): 42 passed, 0 failed, 0 skipped. Commands after checkout: npm ci --ignore-scripts --no-audit --no-fund, npm run build -w agent-work-layer, then node --test packages/mcp/test/cli.test.ts packages/mcp/test/gateway.test.ts.
The separate stdio receiver records one delivery through gateway kill-after-receipt, lost response, and repeated commit after a recorded result. The crash/lost-response outcomes remain unknown and are not resent; the receiver also checks awl/ref and awl/order.
Two coverage limits matter: the killed-process test manually removes the stale lock before recovery (#44), and the before/after-send ambiguity is tested by injecting a running log record, rather than actually killing immediately before dispatch. This supports the bounded local fixture, not guaranteed completion or production receiver deduplication.
For #45, I'd keep evidence-based settlement separate from permission to retry: an absent receiver record alone may be incomplete evidence of non-execution, and a retry should recheck current authority while retaining the logical operation identity. Thanks for making the changes and tests inspectable.
Thanks for reproducing it independently. Agreed on both limits: the stale lock is #44, and the before/after-send case is only simulated through the log, which is the boundary the fixture is meant to cover. I'm not claiming guaranteed completion or that real receivers dedupe.
Good points for #45. I'll keep recording what happened separate from permission to retry, make a retry recheck current authority, and keep the same awl/ref across retries. I'll add them to the issue.
Staff Software Engineer @ Navan, ML Flow & Cypress Ambassador, Docker Captain and creator of agent-inspect, writing about production AI agents, TypeScript, observability, testing, and developer tools.
The Work Order / Work Report split is a useful handoff contract, especially if the MCP gateway can bind tool permissions to a specific order. I'd keep an immutable order ID and policy revision on each tool-call evidence record; otherwise a resumed agent may inherit a report without knowing which authority was in force when an action ran. Do you model retries and handoffs as new report revisions, or append events to one execution history?
Good question. It's one execution history per order, with nothing replaced:
The order never changes after it's created. The desk has no edit operation. The order id is therefore the policy revision: anything that ran under wo_1 ran under exactly those tools, budget and deadline.
Retries add to the same order. When a manager sends work back for rework, the worker's next report is added with an incremented attempt. Every transition is an event with an increasing seq, and earlier reports stay in the record. The gateway numbers tool calls per order across reworks (filings/search#7), and those refs are what the report cites as evidence.
A handoff to a different worker is a new order. The manager can copy the previous worker's handoff (decisions, what was tried, open questions) into it. The spec treats a handoff as the previous worker's account, not verified fact.
You've found a real gap, though, and I've opened two follow-ups:
A call record knows its order only because the log is one file per order. Each record will carry its order id, the report attempt, and the id of the signed Delegation Pass it ran under, so evidence stays tied to the authority in force when it's carried across a resume: github.com/probita-ai/agent-work-l...
A reissued order has no formal link back to the one it continues. parent_id covers sub-orders, not "this replaces wo_1". A new continues field will let a resumed agent trace which order, and so which authority, applied to each earlier action:
Update: both follow-ups are fixed and released in agent-work-layer 0.5.0.
Every gateway call record now carries its order_id, report attempt, and the jti of the signed Delegation Pass it ran under (#17).
A reissued order can set continues to link back to the finished order it replaces, so you can trace the whole chain (#19).
The staged-effect design gives us a concrete crash boundary to test. What happens if the upstream service accepts an effect, then the gateway crashes before recording the response?
I read your 'at most once' statement as distinct from guaranteed completion: marking an effect dispatched before the call can prevent a second attempt, while leaving its outcome unknown. Retrying after that uncertainty needs receiver-side idempotency or reconciliation. Does 0.7 expose an explicit unknown-outcome state, and what evidence lets the manager resolve it?
A small loopback fixture could cover three cases separately: crash before dispatch; receiver accepts but response is lost; result durably recorded then --commit repeats. The receiver's delivery count would be independent of the gateway log. I'm suggesting a test shape here, not reporting a reproduced defect.
Thanks, you read it correctly: the guarantee is at most once, not that the effect completes. 0.8.0 recorded an interrupted effect as error, and a dropped connection or timeout counted as a failure too.
Fixed in agent-work-layer-mcp 0.8.1 (#43):
An effect that was sent but got no answer is now unknown, and it is never run again.
Each effect call carries _meta["awl/ref"] and _meta["awl/order"], so the receiver can dedupe and check what happened.
Your three cases are now tests, using a loopback receiver that counts deliveries on its own.
Follow-ups: #44 (stale commit lock after a crash) and #45 (letting a manager settle an unknown effect).
Thanks for implementing the three cases. Keeping an unanswered send as unknown, with no automatic replay, makes the outcome boundary explicit.
Could you share the #43 PR and test-file links, ideally pinned to the tested commit? I’d like to record this as an external implementation response to the proposed cases, with your attribution and the remaining #44/#45 limits. I haven’t independently reproduced the tests.
github.com/probita-ai/agent-work-l...
I independently reproduced the focused CLI + gateway suite from PR #43's head,
493157aee3391ec89fe1ffd301a402ae6e61861c(Linux x86_64, Node v24.22.1): 42 passed, 0 failed, 0 skipped. Commands after checkout:npm ci --ignore-scripts --no-audit --no-fund,npm run build -w agent-work-layer, thennode --test packages/mcp/test/cli.test.ts packages/mcp/test/gateway.test.ts.The separate stdio receiver records one delivery through gateway kill-after-receipt, lost response, and repeated commit after a recorded result. The crash/lost-response outcomes remain
unknownand are not resent; the receiver also checksawl/refandawl/order.Two coverage limits matter: the killed-process test manually removes the stale lock before recovery (#44), and the before/after-send ambiguity is tested by injecting a
runninglog record, rather than actually killing immediately before dispatch. This supports the bounded local fixture, not guaranteed completion or production receiver deduplication.For #45, I'd keep evidence-based settlement separate from permission to retry: an absent receiver record alone may be incomplete evidence of non-execution, and a retry should recheck current authority while retaining the logical operation identity. Thanks for making the changes and tests inspectable.
Thanks for reproducing it independently. Agreed on both limits: the stale lock is #44, and the before/after-send case is only simulated through the log, which is the boundary the fixture is meant to cover. I'm not claiming guaranteed completion or that real receivers dedupe.
Good points for #45. I'll keep recording what happened separate from permission to retry, make a retry recheck current authority, and keep the same awl/ref across retries. I'll add them to the issue.
The Work Order / Work Report split is a useful handoff contract, especially if the MCP gateway can bind tool permissions to a specific order. I'd keep an immutable order ID and policy revision on each tool-call evidence record; otherwise a resumed agent may inherit a report without knowing which authority was in force when an action ran. Do you model retries and handoffs as new report revisions, or append events to one execution history?
Good question. It's one execution history per order, with nothing replaced:
The order never changes after it's created. The desk has no edit operation. The order id is therefore the policy revision: anything that ran under wo_1 ran under exactly those tools, budget and deadline.
Retries add to the same order. When a manager sends work back for rework, the worker's next report is added with an incremented attempt. Every transition is an event with an increasing seq, and earlier reports stay in the record. The gateway numbers tool calls per order across reworks (filings/search#7), and those refs are what the report cites as evidence.
A handoff to a different worker is a new order. The manager can copy the previous worker's handoff (decisions, what was tried, open questions) into it. The spec treats a handoff as the previous worker's account, not verified fact.
You've found a real gap, though, and I've opened two follow-ups:
A call record knows its order only because the log is one file per order. Each record will carry its order id, the report attempt, and the id of the signed Delegation Pass it ran under, so evidence stays tied to the authority in force when it's carried across a resume: github.com/probita-ai/agent-work-l...
A reissued order has no formal link back to the one it continues. parent_id covers sub-orders, not "this replaces wo_1". A new continues field will let a resumed agent trace which order, and so which authority, applied to each earlier action:
github.com/probita-ai/agent-work-l...
Would those have covered your case? Feedback on either issue is welcome.
Update: both follow-ups are fixed and released in agent-work-layer 0.5.0.
Every gateway call record now carries its order_id, report attempt, and the jti of the signed Delegation Pass it ran under (#17).
A reissued order can set continues to link back to the finished order it replaces, so you can trace the whole chain (#19).
dev.to/murthyg/my-spec-called-the-...