{"slug": "an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result", "title": "An AI agent can be approved and still leave you with an unknown result", "summary": "A developer's reproduction of Agent Work Layer (AWL), Murthy G's tool-call approval gateway, confirmed that approved agent actions can end in an `unknown` state when a remote service receives a call but the gateway dies before recording the answer. Murthy changed unanswered or interrupted effects to `unknown` in PR #43 (agent-work-layer-mcp 0.8.1), retaining the uncertainty and avoiding automatic resends. The maintainer-side run at commit 493157a passed 42 tests with zero failures, though recovery still required manual stale-lock removal and the receiver was a fake local service, not a production endpoint.", "body_md": "An approval answers whether an agent may attempt an action. It does not tell\n\nyou whether a remote service completed it.\n\nThat distinction became concrete in a public discussion with Murthy G, the\n\ndeveloper of [Agent Work Layer](https://github.com/probita-ai/agent-work-layer).\n\nAWL stages selected tool calls until a manager approves the work. I asked what\n\nhappens when a service receives a call, but the gateway dies before it records\n\nthe answer.\n\nThe useful outcome was a change we could inspect and rerun.\n\nConsider one approved operation:\n\nA missing result after step 2 does not establish that nothing happened. Sending\n\nagain may duplicate an effect. Refusing to send again may leave an operation\n\nunfinished if the gateway actually stopped before step 2.\n\nMurthy [clarified the intended at-most-once behavior](https://dev.to/murthyg/comment/3j4aj)\n\nand changed unanswered or interrupted effects to `unknown` in\n\n[PR #43](https://github.com/probita-ai/agent-work-layer/pull/43), associated with\n\n`agent-work-layer-mcp` 0.8.1. The gateway retains that uncertainty and avoids\n\nautomatically sending the operation again. Calls also carry `awl/ref` and\n\n`awl/order` metadata. A real receiver still needs its own verified handling of\n\nthose identifiers; metadata alone does not establish deduplication.\n\nOn October 27, 2026, the maintainer-side reproduction checked out PR #43's exact\n\nhead, `493157aee3391ec89fe1ffd301a402ae6e61861c`, on Linux x86_64 with Node\n\nv24.22.1. These commands ran from the repository root:\n\n```\nnpm ci --ignore-scripts --no-audit --no-fund\nnpm run build -w agent-work-layer\nnode --test packages/mcp/test/cli.test.ts packages/mcp/test/gateway.test.ts\n```\n\nThe focused suite finished with **42 passing tests, zero failures and zero skips**, exit 0, in about 21.95 seconds. This tested a source checkout, rather\n\nThe [CLI tests](https://github.com/probita-ai/agent-work-layer/blob/493157aee3391ec89fe1ffd301a402ae6e61861c/packages/mcp/test/cli.test.ts)\n\nuse a separate local MCP receiver over stdio. It writes its own delivery file,\n\nseparate from the gateway log. The passing assertions cover:\n\n| Situation | Bounded observation | \n|---|---|\n| Gateway killed after the receiver records the call, before its answer | After manual stale-lock removal, recovery retains `unknown` ; further commit does not add a delivery | \n| Receiver records the call and exits without answering | Outcome remains `unknown` across repeated commits; delivery count stays one | \n| Successful result recorded, then commit repeats | Earlier `ok` result is retained; delivery count stays one | \n\nTwo limitations deserve equal billing with the green result.\n\nFirst, recovery from the killed process includes manual lock removal.\n\n[Issue #44](https://github.com/probita-ai/agent-work-layer/issues/44) tracked that\n\nstale-lock problem. AWL 0.9.0 ([PR #48](https://github.com/probita-ai/agent-work-layer/pull/48)),\n\nmerged after this reproduction, reports that a later run on the same machine\n\ntakes over a lock whose process is gone. I have not rerun that release, so this\n\nrun does not establish automatic crash recovery.\n\nSecond, the [gateway test](https://github.com/probita-ai/agent-work-layer/blob/493157aee3391ec89fe1ffd301a402ae6e61861c/packages/mcp/test/gateway.test.ts)\n\nrepresenting the before/after-send ambiguity injects a `running` log entry.\n\nIt does not kill a real gateway immediately before dispatch. The separate\n\nreceiver is a fake local service; no Gmail delivery, production idempotency or\n\npower-loss durability was tested.\n\n[Issue #45](https://github.com/probita-ai/agent-work-layer/issues/45) proposed\n\nletting someone settle an unknown effect after checking the receiver.\n\nThat introduces two decisions worth recording separately:\n\nMurthy has since [refined that proposal](https://github.com/probita-ai/agent-work-layer/issues/45#issuecomment-6431421646):\n\nsettlement records evidence, while a separate retry step rechecks authority and\n\nkeeps the operation identity across attempts. Who may settle and who may retry\n\nremained open questions in that comment.\n\nThe same PR #48 then shipped an implementation. According to its description,\n\na worker settles an `unknown` effect as `ok` or `not_run` with a required note,\n\nand settling never runs anything. Only a manager allows a retry. `--retry`\n\nrechecks the approval and the staged call, then sends the same `awl/ref` with\n\n`awl/try: 2`. I have read that description only; the reproduction above does\n\nnot verify the settlement or retry implementation.\n\nAn absent receiver record can be incomplete evidence. An earlier approval can\n\nalso describe a different recipient, payload or request instance from the one\n\nnow pending. A retry needs a deliberate policy for current authority and\n\nlogical operation identity. These remain acceptance questions for the new\n\nrelease, not features established by the rerun.\n\nA separate [trollshell discussion](https://github.com/vibec0re/trollshell/issues/1557#issuecomment-6431287998)\n\nmade the request-instance boundary particularly clear: comparing an approval\n\nclick with the last-polled UI snapshot leaves a later server-side race. The\n\nauthor distinguishes that existing UI protection from a proposed server-side\n\ncompare-and-set. Our [source-based response](https://github.com/vibec0re/trollshell/issues/1557#issuecomment-6431391150)\n\nkeeps the upstream work's dormant scope intact. No GTK or hive runtime test\n\nwas run in that review.\n\nI maintain [Agent Role Contracts](https://github.com/suirindo/agent-role-contracts),\n\nan offline declaration checker. The discussion informed a bounded fixture pack\n\ntracked in [#71](https://github.com/suirindo/agent-role-contracts/issues/71) and\n\n[#69](https://github.com/suirindo/agent-role-contracts/issues/69#issuecomment-6408121908).\n\nThe [fixtures, runner and raw results](https://github.com/suirindo/agent-role-contracts/tree/main/experiments/outreach-fixtures)\n\nare public, with reproduction commands in the README.\n\nThe pack groups eighteen offline cases into:\n\nThe runner uses existing G0/G1/G3 APIs and retains resolved inputs and raw\n\nresults. All eighteen expected calculations matched in the local run. The\n\noutput also records **zero runtime cases executed**, with authority `UNKNOWN`\n\nand runtime `NOT_RUN`. A lifecycle declaration can be consistent while the\n\nseparate supplied trace remains unresolved. A hidden recipient resolution\n\ncannot be discovered by hashing the unchanged declaration.\n\nThe permission comparator agrees with an equally informed, modeled native-style\n\npredicate. That overlap matters: the fixture pack provides a repeatable\n\nworksheet, while incremental value over a real host's complete controls and\n\nhuman maintenance cost remain unmeasured. The six evidence worksheets are\n\nsynthetic inputs, separate from AWL's executed receiver tests.\n\nFor an uncertain operation, a useful record keeps the exact reviewed subject,\n\nlogical operation identity, individual attempt, current authorization decision,\n\ndispatch observation, receiver observation and response separate. It also\n\nnames who supplied each record, what was actually verified and what remains\n\nunobserved.\n\nThat separation lets an operator preserve uncertainty without turning a green\n\ndeclaration check into a claim of delivery. In this exchange, a concrete test\n\nproposal led to inspectable external changes and a bounded reproduction. The\n\nremaining recovery and reconciliation questions stay visible alongside it.", "url": "https://wpnews.pro/news/an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result", "canonical_source": "https://dev.to/suirindo/an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result-27e6", "published_at": "2026-10-27 03:04:54+00:00", "updated_at": "2026-10-27 03:11:59.613581+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-safety", "agent-protocols", "developer-tools"], "entities": ["Agent Work Layer", "Murthy G", "agent-work-layer-mcp", "GitHub", "Node.js"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result", "markdown": "https://wpnews.pro/news/an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result.md", "text": "https://wpnews.pro/news/an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result.txt", "jsonld": "https://wpnews.pro/news/an-ai-agent-can-be-approved-and-still-leave-you-with-an-unknown-result.jsonld"}}