Every Tool Call Succeeded. The Workflow Still Failed.

TL;DR for operators

An AI agent can complete every reported tool call while leaving a business workflow in an inconsistent state. The critical distinction is between successful invocations and the external effects that remain after the workflow commits or aborts.

A study of 98,291 remotely discovered Model Context Protocol (MCP) tools found that 74.0% emitted at least one standard annotation field. Yet the standard annotation vocabulary could not fully express any of eight transactional capabilities identified by the researchers.

For organizations automating payments, reservations, approvals, and other multi-step operations, the practical requirements extend beyond retries and error handling:

• Resolve uncertain outcomes: Establish whether an external action actually happened before retrying, committing, or compensating.
• Control effect lifecycles: Prevent premature externalization, track dependencies, and verify that compensation neutralizes the intended effects.
• Coordinate external interactions: Mediate conflicting actions on shared resources and account for consequences produced by independent observers.

These requirements point toward explicit transactional contracts between agent runtimes and tool providers. The study establishes an architectural framework, not a tested guarantee that adopting such contracts will eliminate workflow failures.

Successful calls can leave inconsistent business outcomes

Consider an AI agent coordinating a payment, a reservation, and a customer notification. The payment service confirms a charge, the reservation system accepts an update, and the messaging service sends a confirmation.

Every API call may appear successful. Yet if the reservation is subsequently canceled while the customer has already acted on the notification, the workflow can leave consequences inconsistent with its intended resolution.

The reliability question is therefore about the entire business process: which effects occurred, which remain, and whether they agree with the workflow’s decision to commit or abort.

In When Tool Calls Succeed but Workflows Fail: Anomalies at the Agent-Tool Boundary, Artem Trofimov and Boris Novikov develop a framework for analyzing these failures.¹

Their starting distinction is between two records that an agent runtime may otherwise conflate: what happened in the external world and what the runtime observed.

A payment request, for example, may reach the provider even if its acknowledgment never reaches the agent. The payment either occurred or did not; the runtime’s uncertainty does not create a third external outcome.

The authors formalize this distinction through an effect-history model spanning individual tool operations and the workflows that compose them. It records execution attempts, external effects, compensation, dependencies, observations, and workflow resolutions.

An effect survives when it was externalized and has not been neutralized. Whether surviving effects agree with the workflow’s final resolution becomes the basis for evaluating transactional consistency.

Eight anomalies expose three different control problems

The paper identifies eight forbidden patterns, grouped by the mechanisms that produce them.

Source: Section 3, Table 2. The catalog is coverage-oriented; its formal completeness is not established.

The uncertainty family describes three hazards following an ambiguous result. Retrying can duplicate an effect (A1). Committing can assert completion despite a missing required effect (A2). Issuing compensation before resolving the original outcome can create an orphaned compensation action (A3).

These failures cannot be eliminated merely by instructing an agent to retry carefully. Safe recovery requires an authoritative way to establish the outcome of a logical operation.

The workflow family concerns when effects become visible and how they depend on one another.

An aborted workflow may leave an uncompensated effect (A4). A speculative action may become externally visible before its survival is determined (A5). A committed effect may depend on another effect that is subsequently removed (A6).

Consider an approval workflow that sends a downstream instruction before the approval decision is final. Even if the instruction is later canceled, a committed downstream action may already depend on it. Preventing this pattern requires understanding dependencies and controlling release, not simply executing compensation afterward.

The interaction family adds independent execution and observation. Two workflows can create conflicting, non-commuting effects on a shared resource (A7). An outside actor can also respond to an effect that is later compensated, leaving a consequence the runtime cannot retract (A8).

A refund may neutralize a charge without reversing decisions made by someone who observed the original transaction.

These patterns are not interchangeable final-state errors. In particular, A3 concerns the decision to compensate under uncertainty, while A5 and A7 express preventive conditions. Their exclusion depends on the applicable safety guarantee and available controls.

Why runtime recovery cannot guarantee everything

The authors derive four guarantee boundaries from the anomaly model.

First, ambiguous execution outcomes require authoritative resolution. An idempotency hint alone cannot establish whether an earlier attempt took effect or ensure that a re-issued request retrieves the original result.

Second, conflicting irreversible operations that do not commute generally require coordination before externalization, unless an operation-specific reconciliation mechanism is available.

Third, compensation cannot generally reverse independent consequences produced by external observers. Once another party has responded, restoring the originating system’s state may be insufficient.

Fourth, a runtime cannot universally guarantee atomic release of several irreversible effects across independent tools without their participation in an atomic commitment mechanism. A crash between releases can leave an unrecoverable partial outcome.

The paper organizes possible protections into unknown-safe, compensation-safe, speculation-safe, and externally-mediated profiles. These describe which anomalies a protocol can exclude under specified assumptions, not a universal hierarchy of runtime quality.

A qualitative comparison of six systems—ACRFence, RAC, Atomix, Cordon, CoAgent, and Shepherd—finds partial, differently conditioned coverage. Atomix, for example, addresses staged execution and dependency tracking but retains limitations around uncertain outcomes and atomic multi-effect release. None is shown to cover the entire catalog, and the authors identify no mechanism among them that controls the exogenous reactions underlying A8.

This comparison evaluates reported mechanisms and assumptions rather than experimentally verified guarantees.

MCP annotations describe tools, but not their transactional contracts

The paper then examines whether existing tool interfaces declare the capabilities the framework requires.

Using the official MCP registry snapshot dated July 27, 2026, the researchers retained the latest version of each registered server and queried 9,234 remote discovery targets. Of those, 4,838 returned tools, yielding 98,291 tool definitions.

The census produced several notable measurements:

The four examined fields were readOnlyHint, destructiveHint, idempotentHint, and openWorldHint.

Although 66 of the 81 possible annotation signatures appeared, the distribution was concentrated. Even frequently emitted metadata does not necessarily provide operationally meaningful guarantees.

The distinction is especially clear with idempotentHint. It can suggest that repeating an operation is safe, but it does not supply a logical-operation identifier, an authoritative result, or a general exactly-once guarantee.

Likewise, the standard annotations do not specify compensation correctness, staging, dependency relationships, commutativity, or external visibility control.

The expressibility comparison finds limited representation for A1 through an idempotence hint and no corresponding standard declarations for the required A2–A8 capabilities.

This is an interface limitation, not evidence that 98,291 tools are transactionally unsafe. The census did not execute tools, verify annotations, or inspect their internal guarantees.

Transactional contracts change what enterprises should verify

The architectural proposal is to expose reusable transactional contracts at the agent-tool boundary.

Such contracts would describe what a runtime can reliably discover or control: operation identity, authoritative outcomes, compensation semantics, release timing, resource identity, dependencies, and coordination requirements.

For enterprise operators, Cognaptus draws three practical implications.

Tool procurement should test guarantees, not just invocation compatibility. A payment provider claiming idempotence should be evaluated for how logical operations are identified, how uncertain results are resolved, and what evidence is available after a failed acknowledgment.

Workflow design should separate reversible work from irreversible release. Where providers support staging or controlled commitment, speculative decisions can remain provisional. Where they do not, approval gates and explicit acceptance of residual risk may be necessary.

Audit systems should track effects rather than only successful calls. A reliable record needs evidence of externalization, outcome resolution, compensation, and dependencies. A log showing HTTP success or agent completion is not sufficient to establish that the business workflow reached a coherent state.

These are design implications of the framework, not measured reductions in incident rates or demonstrated financial returns.

What remains unproved

The study’s strongest empirical evidence concerns the standardized metadata exposed by reachable remote MCP servers. Unreachable and package/stdio-only implementations were excluded. Annotation values may also reflect SDK defaults rather than deliberate declarations.

Its broader contribution is conceptual. The anomaly catalog’s completeness and independence are not formally proved, the four guarantee boundaries remain informal arguments, and no standardized transactional contract protocol is implemented or benchmarked.

The framework also excludes semantic planning mistakes, authorization failures, read-side anomalies, and liveness problems. Transactional consistency would not establish correctness on those dimensions.

Future evaluation needs to test whether declared contracts match actual provider behavior, whether conforming runtimes exclude the intended anomalies, and what staging or coordination costs relative to the failures they prevent.

The boundary must support the guarantee

Agent reasoning can choose actions and runtime orchestration can sequence them. Neither can reliably determine an unobservable external outcome or reverse every consequence produced by independent actors.

Trofimov and Novikov’s contribution is to make these boundaries explicit: eight anomaly patterns, corresponding capability requirements, and evidence that today’s standard MCP annotations cannot fully describe those requirements.

For organizations deploying agents into consequential business processes, the next reliability question is not simply whether a tool call succeeds. It is whether the interface supplies enough evidence and control to verify what the complete workflow actually did.

Cognaptus: Automate the Present, Incubate the Future.