The problem
An agent decides to act, a human approves, and the action is executed against an external API. If the process dies between approval and execution, nobody knows whether it happened.
The shape
- The approval and the intended action are written to an
actionstable in the same transaction. - A relay reads pending actions, executes them with an idempotency key, and records the outcome.
- The agent observes the outcome through the same table, never through the API response.
Trade-offs
- Plus: complete audit trail, safe retries, replay after an outage, one place to enforce permissions.
- Minus: one more hop of latency, one more component to run, eventual consistency the UI must show honestly.
Where it sits
On the Tools node of the AI Application map, between the gateway and the systems of record. The MCP gateway decision explains why the gateway alone is not enough.
Key takeaways
- Record the intended action and the approval in one transaction, then execute from the outbox.
- The outbox gives you audit, retry and replay for free.
- Latency goes up by one hop. For writes that matter, that is the right trade.
More on these topics
Comparison · · 1 min read
LangGraph vs the OpenAI Agents SDK
Two ways to write the same supervisor. Compared on control flow, tracing, provider coupling, testing and what each makes hard.
Deep dive · · 6 min read
Every question your AI readiness review asks was answered months ago
The last six days of a sixty-day series, and the pattern is that operability gets bought early or it does not get bought at all.
Checklist · · 24 checks
Working with Claude, practices that hold up
Prompting, agents and tools, Claude Code, evaluation and safety. The habits that make Claude-based systems reliable, as a checklist you can run against your own setup.
Discussion