Intention vs Contract

The debate is framed wrong

Most people think the AI challenge in enterprise is about connecting agents to APIs.

That is an architecture mistake.

The real problem runs deeper. Our systems are built to execute deterministic contracts. Agents operate on interpreted intent. And between those two things, there is no standard architectural layer in existence today.

This is not about protocols. MCP, function calling, tool use, all of these are well-designed and necessary. But none of them answer the fundamental question. They give the agent the means to act. They say nothing about the boundaries within which it should act.

Those are two entirely different problems. Conflating them means building on a flawed premise from the start.

We spent twenty years engineering ambiguity out of our systems. AI is not fixing that. It is bringing ambiguity back in, and making it the execution model.

What enterprise architecture was built to do

Enterprise systems rest on a principle that has proven itself over decades: deterministic contracts.

An API is a contract. It specifies inputs, outputs, error codes, and invariants. It is versioned, documented, and tested. When a system calls POST /orders, it knows exactly what it is sending, what it expects back, and what happens when something goes wrong.

A BPMN workflow encodes a sequence of states. Every transition is explicit. Responsibilities are assigned. Compensations are defined. Idempotency is deliberate. Traceability is baked in from the start.

An Avro or Protobuf schema is a message contract. Every producer and every consumer is bound by it. Compatibility can be verified mechanically, without human judgment.

This model holds up because it is predictable. Same input, same context, same outcome. Responsibility is traceable. Auditability is built in. Compliance is provable.

Thirty years of enterprise architecture, SOA, microservices, EDA, all of it rests on this foundation. The paradigms evolved. The principle never changed.

What agentic AI actually introduces

An AI agent does not operate by contract. It operates by interpreted intent.

A user states a goal: “process this customer file and send a confirmation if everything checks out.” The agent interprets that goal, builds a plan, selects tools dynamically, chains calls together, and adjusts its path based on each intermediate result.

That behavior is probabilistic. The same instruction, in a slightly different context, a rephrased prompt, an ambiguous API response, a missing field, can produce a completely different execution path. Not because the system is broken. Because it was designed to interpret, not to execute mechanically.

An API executes a contract. An agent navigates a decision space. Modern architecture now has to bridge those two worlds.

MCP standardizes how agents connect to tools. That matters. But MCP does not encode business invariants. It does not constrain execution trajectories. It does not validate semantic consistency across a chain of calls. It does not enforce least-privilege at the tool-selection level. It hands the agent a catalog of available actions. What the agent does with that catalog remains probabilistic.

The paradigm fracture

Placing an agent against a contractual system creates a structural tension that most architectures have never had to address.

The system speaks the language of contracts: valid inputs, correct sequences, verified identities, consistent state. The agent speaks the language of intent: goals to reach, tools to use, outputs to interpret.

This is not a technology mismatch. It is a fundamental incompatibility in execution paradigm.

Deterministic systems execute. Agents interpret. And the gap between interpreting and executing is a surface of ambiguity that classical architectures never needed to manage, because their clients were themselves deterministic.

When the client is another microservice, the call sequence is hard-coded. When the client is an agent, the sequence emerges at runtime. That shift in the nature of the client challenges every design assumption baked into the exposed systems.

Where things break in production

These incidents do not look like classic technical failures. They are subtler, and usually more damaging.

The most dangerous failure is not a technical error. It is a call that is technically valid but business-invalid. Everything appears to work. Until the system quietly drifts off course.

These are not edge cases. They are documented, reproducible patterns.

The agent calls POST /payment/validate with syntactically correct parameters, inside a business-incoherent context. The contract holds. The business invariant breaks. The system approves. The fraud goes through.

The agent interprets an ambiguous objective and chains cancel_order followed by create_order instead of update_order. Both operations are individually valid. The sequence is systemically broken. Neither system flags the problem.

The agent replays a tool call after a timeout, with no way of knowing whether the first attempt succeeded. The target system is not idempotent on that specific operation. The order is created twice. The audit traces the root cause three weeks later.

The agent has access to ten tools. On an edge case, it activates one it should never have used in that context, because nothing explicitly prevents it, and the apparent intent seemed to justify the choice. Least-privilege is violated not through malice, but through interpretation.

The agent receives a 200 with a degraded payload. It keeps going. The problem surfaces during end-of-day accounting reconciliation.

Behavioral debt : the threat no one is accounting for yet

What makes these incidents so dangerous is not how often they happen. It is that they are invisible.

Technically, everything looks fine. APIs respond. Calls are valid. Logs are clean. But at the business level, the system is drifting.

This is a new category of technical debt. Not debt tied to code quality. Debt tied to execution trajectories. It accumulates through implicit decisions, uncontrolled sequences, and unvalidated interpretations. And unlike classical technical debt, it does not live in the codebase. It lives in the behavior of the system over time.

It does not break things suddenly. It erodes coherence, reliability, and trust gradually. This is erosion, not explosion.

Microservices created an infrastructure debt that organizations are still paying down years later. Agents will create a behavioral debt. And that debt will be harder to see, because it leaves no manifest, no changelog, no diff. It lives in the implicit decisions of a model that carries no memory between runs.

The illusion of control

There is a specific cognitive trap in agentic architectures. And it is one of the most dangerous.

You see the calls in the logs. You see the responses. You have monitoring. Everything looks controlled.

But you cannot see why the agent made that specific choice, at that specific moment, with that specific data. You are observing behavior. You are not observing reasoning.

In a deterministic system, understanding behavior means understanding reasoning, because the reasoning is encoded in the system. In an agentic system, you can watch perfectly normal behavior for weeks and completely miss the fact that the underlying reasoning is slowly drifting.

Your dashboards are green. Your system is degrading.

When the drift finally becomes visible, a malformed order, an inconsistent validation, a corrupted record, it is usually too late to reconstruct the causal chain. Because the agent has a trace of its actions. It has no trace of its reasoning.

This is not a tooling maturity problem. It is a structural property of the paradigm. You cannot fix it by adding more dashboards. You fix it by rethinking the architectural layer that sits between intent and execution.

Operational sovereignty : the issue no one is naming yet

There is a deeper concern still, and one that most organizations have not yet put into words.

The sovereignty of your systems.

In a classical system, execution logic is under your control. Rules are coded. Flows are defined. Decisions are traceable. You know why your system does what it does.

With agentic AI, part of that logic migrates into an interpretation space driven by an external model. The consequence is direct: you no longer fully control how your system makes decisions.

Even if your APIs are locked down. Even if your data is protected. Even if access is tightly managed. The actual orchestration logic has partially slipped out of your hands.

And that raises a question too few technical leaders are asking explicitly.

Who actually controls the behavior of your system? Your architecture? Your business rules? Or the interpretation of an external model?

Without an explicit mediation and governance layer, you progressively lose operational sovereignty over your information system. That loss is silent. It does not register in technical metrics. It shows up in decisions, in drifts, in business inconsistencies. And by the time it becomes visible, you are already behind.

Rethinking what integration actually means

“Plug the agent into your APIs” is technically accurate. It is architecturally wrong.

It frames the problem as connectivity. The actual problem is semantic mediation: translating intent into a sequence of actions that is contractually valid, business-coherent, secured, and traceable.

Without that mediation layer, the agent sees a catalog of tools. The exposed system sees an unpredictable source of calls. And between them, architecture is absent.

MCP gives the agent the means to act. Semantic mediation gives it the constraints within which to act. These are two complementary concerns. Treating one as a substitute for the other means shipping a system without governance and calling it architected.

The missing layer : from intent to contract

Robust agentic architectures require an explicit intermediate layer between the agent’s intent and the contractual execution of downstream systems.

This is not an API gateway. It is not a classical workflow orchestrator. It plays a specific role: to constrain, validate, enrich, trace, and secure the translation of intent into execution.

It constrains available capabilities based on context, role, and current system state. The agent cannot do everything simply because it has access to everything. It can do what is authorized in this specific context.

It validates the coherence of call sequences against business invariants, before execution, not after the fact. Business rules do not belong in the APIs. They belong in this layer.

It enriches intent with context the agent cannot directly access: workflow state, session history, regulatory requirements, retention policies.

It traces not just the technical call, but the intent that triggered it, the tools that were considered, and the decision that was made. Auditability in an agentic system means capturing a reasoning trace, not just an execution log.

It secures by enforcing capability governance: which tools, for which agents, in which contexts, with what scope constraints.

This layer is what reintroduces determinism where interpretation has eroded it. It is what makes agents governable without making them useless.

Conclusion

Enterprise systems spent thirty years learning to contractualize interfaces, govern flows, and trace execution. Agentic AI repositions those hard-won foundations on probabilistic ground, not through poor design, but by nature.

The temptation is to treat this as a connectivity problem, because connectivity is the visible layer. The real problem sits underneath. It is architectural.

AI does not only introduce complexity. It introduces invisible debt, an illusion of control, and a genuine risk of losing sovereignty over your own systems. No protocol resolves that. Agents will not simplify your systems. They will surface every structural weakness in them. Without an intent-to-contract mediation layer, you are not building an intelligent system. You are building an uncontrollable one.

The real architecture work does not begin when you connect an agent to your APIs. It begins when you design the layer that translates intent into governed, validated, traceable, contractual execution.

Agentic integration is not a connectivity problem. It is an architectural responsibility.

The architects who name this fracture today will be the ones shaping the systems of tomorrow.