When you give an AI agent a list of functions to call, you are giving it a phone book with no descriptions. The agent knows the number. It does not know when to call, what to say when someone picks up, or what happens if it calls the wrong number at the wrong time.
\n\nFunction calling works. It is genuinely useful. But it has a gap that becomes visible the moment agents start doing things that matter. In regulated industries, in financial systems, in anything that needs to be auditable, \"the agent called a function and something happened\" is not an acceptable record.
\n\nThe current state of AI tool use
\n\nToday's function calling pattern looks like this: you define a function with a name, a description string, and a parameter schema. You pass it to the model. The model decides when to call it based on context and the description. The result comes back and the model continues.
\n\nThis works well for read-only lookups, simple calculations, and deterministic transformations. The description gives the model enough context to make reasonable decisions most of the time.
\n\n\"Most of the time\" is the problem.
\n\nA description string is natural language. It is ambiguous. It does not tell the model whether the function has side effects. It does not tell the model what state must be true before calling it. It does not tell the model what the output actually guarantees. The model is reasoning from prose, and prose leaves gaps.
\n\nWhat function definitions do not tell the agent
\n\nTake a function called apply_discount. Here is roughly what a typical function definition tells an agent:
- \n
- Name:
apply_discount\n - Description: \"Applies a discount to an order\" \n
- Parameters:
order_id(string),discount_code(string) \n - Returns: updated order total \n
Here is what the definition does not tell the agent:
\n\n- \n
- Whether the discount has already been applied to this order (calling twice is an error) \n
- Whether the discount code is single-use (calling it burns the code) \n
- Whether there is a minimum order value required \n
- What happens if the order is in a locked state \n
- Whether the function writes to a database (it does) \n
- What the audit requirements are for this operation \n
None of that is in the function definition. The agent does not know to ask. It calls the function when \"apply a discount\" seems like the right move, and the preconditions are the runtime's problem.
\n\nWhat happens when agents guess wrong
\n\nI have seen a few patterns emerge as teams put agents into production with real function calling.
\n\nThe most common failure is calling a function with inputs that look valid but violate an implicit precondition. The function signature accepts the inputs fine. The business logic rejects them. The agent gets a generic error message, does not understand why, and tries again with slightly different inputs. Sometimes it succeeds on a second attempt in a way that causes a duplicate operation.
\n\nThe second pattern is sequencing errors. The agent calls operations in the wrong order because nothing in the function definitions told it about dependencies. finalize_order gets called before confirm_inventory. The system is now in a partial state that requires manual cleanup.
The third pattern is the audit problem. Something went wrong. You need to reconstruct what the agent decided and why. You have the function call logs but not the agent's reasoning about preconditions. You have outputs but not the guarantees the agent was relying on. The trace is incomplete.
\n\nWhat a contract adds
\n\nA contract is a machine-readable description of a capability's behavior. Not a prose description. A structured definition that a runtime can validate against before execution happens.
\n\nFor an AI agent, a contract provides four things that a function definition cannot:
\n\nPreconditions. Conditions that must be true before the capability can execute. The agent can check these before calling. If a precondition is not met, the agent knows not to call yet rather than calling and handling a cryptic error.
\n\nPostconditions. Guarantees about what will be true after the capability executes. The agent can rely on these when planning subsequent steps. \"After calling this, the order total will reflect the discount\" is a statement the agent can reason about.
\n\nSide effects. An explicit declaration of what the capability changes. \"This capability writes to the orders table and consumes the discount code\" is information an agent needs for correct sequencing and idempotency reasoning.
\n\nFailure modes. Named failure cases with structured descriptions. Instead of parsing error strings, the agent receives a typed failure that it can match against expected cases and handle appropriately.
\n\nHow MCP fits in
\n\nThe Model Context Protocol gives agents a standard way to discover and call tools at runtime. It is a good protocol. What it does not specify is what metadata those tools should carry about their behavior.
\n\nTraverse exposes governed capabilities as MCP tools. Each tool corresponds to a capability with a full contract. When the agent calls the tool, the Traverse runtime validates the call against the contract before executing the WASM module. The agent gets a structured response that includes postcondition confirmation and a trace ID.
\n\nHere is the difference in practice. Same capability, two interfaces:
\n\nThe agent calling the Traverse capability knows the order must be open before calling. It knows the operation is not idempotent. It knows the specific failure codes to handle. It knows a trace will be emitted. None of this requires a longer prose description. It is machine-readable structure.
\n\nWhy this matters for regulated industries
\n\nFinancial services, healthcare, insurance, legal technology. Any domain where decisions have regulatory consequences.
\n\nIn these domains, \"an AI agent made a decision\" is not acceptable. What is required is: what information did the agent have, what capability did it invoke, what were the inputs, what were the outputs, what guarantees did the system make, and when did each of these things happen.
\n\nA Traverse trace artifact contains all of this. The capability ID, version, and contract hash. The validated inputs. The outputs and the postconditions they satisfy. The placement decision. The timestamp and duration. A cryptographic trace ID that links to the full execution record.
\n\nThis is not primarily about compliance checkbox-ticking. It is about building AI systems you can actually debug when something goes wrong. The agent made a sequence of decisions. You need to reconstruct that sequence. Contracts and traces give you the structure to do that.
\n\nThe alternative is parsing log files and reading prompt histories and hoping the agent's reasoning was coherent. That approach does not scale to production systems with real consequences.
\n\n