When Tool Calls Succeed, Agents Need Transactional Contracts

A successful tool call is one of the most comforting lies in an AI agent trace.

The model asked the CRM to create a record. The tool returned success: true. The orchestrator moved to the next step. The demo looked clean. But production work is not judged by whether a function returned a green check. It is judged by whether the outside world is now in the right state.

That gap is where long-running agents get dangerous.

A workflow can retry after a timeout and create two records. It can abort a plan after a human rejection, while a side effect from the rejected branch survives. It can speculatively call a tool, later choose a different path, and leave provisional work behind. It can continue from a checkpoint that knows what the runtime observed, but not what actually happened in the external system.

In other words: the call can succeed while the workflow fails.

That is the useful framing in the new arXiv paper “When Tool Calls Succeed but Workflows Fail: Anomalies at the Agent-Tool Boundary”. The authors argue that modern agents are increasingly executing long-running workflows with real external effects, and that retries, partial failures, concurrency, and speculative execution can leave the external world inconsistent with the workflow’s intended resolution. Their proposed lens separates two things teams often blur together: events that happened in the outside world, and observations the agent runtime has about those events.

That distinction sounds small. It is not.

If an agent sends a refund request and then loses network connectivity, the runtime may only know that the request was attempted. It may not know whether the refund posted, whether it is still pending, whether a retry will duplicate it, or whether there is a safe way to reverse it. A normal tool response schema can describe the shape of the return value. It does not automatically describe the life cycle of the effect.

This is why production agents need transactional tool contracts.

A transactional contract does not mean every tool needs to become a distributed database. It means the boundary between the agent and the tool must expose enough semantics for the orchestrator to make safe decisions. At minimum, a serious side-effecting tool should be able to answer questions like these:

• Did an external effect actually occur?
• Is the operation idempotent under a caller-provided key?
• Can the effect be staged before commit?
• Can it be compensated or reversed?
• What does abort mean after the call has started?
• Which durable receipt proves the current external state?
• Can a later replay join runtime history to external-system history?

Without those answers, the agent is not recovering. It is guessing.

The Model Context Protocol shows both the progress and the remaining gap. The MCP tool specification lets servers expose tool names, descriptions, input schemas, optional output schemas, and annotations such as read-only, destructive, idempotent, and open-world behavior. That metadata is valuable. It gives clients and agent harnesses a better vocabulary than an undifferentiated bag of functions.

But call-level annotations are not the same as a transaction boundary. “Idempotent” is useful, but useful to whom and under what key? “Destructive” is a warning, not a recovery protocol. An output schema can say what fields come back, but not necessarily whether the action is staged, committed, compensatable, or externally observable through a durable receipt. The paper’s measurement of annotation usage across registered MCP tools, supported by the authors’ mcp-annotation-census artifact, points to the same conclusion: current shared metadata is helpful, but still too coarse to express the capabilities needed to rule out whole classes of external-effect anomalies.

MCP also includes progress notifications, which matter for long-running operations. A user or orchestrator should know that a tool is halfway through an import, still indexing documents, or waiting on a downstream service. But progress is not proof of correctness. A progress event says the work is moving. A transactional receipt says what changed, where, under which operation identity, and what can safely happen next.

For enterprise teams, this changes how agent infrastructure should be reviewed.

Do not only ask whether the model can call the tool. Ask whether the tool can participate in recovery. A calendar scheduler, ticketing integration, billing API, deployment runner, EHR connector, or document automation service should not be wrapped with the same thin interface as a read-only search function. The wrapper should carry effect semantics.

A practical contract might include a caller-generated operation ID, an idempotency key, a declared effect class, a staged-versus-committed status, a compensation endpoint or explicit “not compensatable” marker, a durable external receipt, and a reconciliation method that can be called after timeout or restart. The agent trace should store those fields as first-class evidence, not as incidental text in a model transcript.

That design also improves human oversight. A manager approving an agent’s proposed action should not see only “send invoice.” They should see whether the action will be staged for later commit, immediately sent to the customer, reversible, or irreversible. If approval is revoked, the system should know whether it is canceling a pending operation or compensating an already-committed one.

This is where many agent demos are still too optimistic. They treat tools like synchronous subroutines. Production tools are often closer to business processes: they queue jobs, trigger emails, mutate third-party state, fan out to other systems, and fail ambiguously. The agent runtime cannot make that complexity disappear by placing a JSON schema over it.

The better pattern is to make effect state explicit.

Before calling a side-effecting tool, the runtime should generate an operation identity. During execution, it should record observations separately from confirmed external receipts. After interruptions, it should reconcile before retrying. When a workflow is abandoned, it should compensate only where compensation is actually supported. When compensation is not supported, the system should escalate instead of pretending rollback exists.

This may sound heavier than the current agent builder experience. Good. Side effects should feel heavier than autocomplete.

The good news is that teams do not need to solve every distributed-systems problem at once. They can start by classifying tools into read-only, reversible write, irreversible write, and staged write. They can require idempotency keys for common mutations. They can reject wrappers that return only “success” for consequential operations. They can log durable receipts in the same place they log prompts and model decisions. They can test failure modes by forcing timeouts after the external system receives the request but before the agent receives the response.

Those drills reveal whether an agent platform has real recovery semantics or just a prettier transcript.

The operating principle is simple: an agent should never have to infer whether the world changed from a vague success message. If the workflow matters, the tool boundary needs to say what happened, what is safe to repeat, what can be undone, and what evidence proves it.

That is the difference between an agent that performs actions and an agent system that can be trusted to finish work.