The Intent-to-Contract Framework
The previous article named the missing layer. This one names the framework.
That distinction matters. A layer is an architectural responsibility. A framework is the grammar that makes that responsibility repeatable across teams, domains, and systems.
In this article, grammar is not a metaphor. The framework carries three explicit grammars, each named in its own section: a binding grammar that anchors responsibilities on typed objects, a composition grammar that defines how those objects combine into trajectories, and a lifecycle grammar that governs how the composition unfolds in time. Each grammar names something different: verbs and nouns, compositions, and time. Together, they turn agentic execution into something architecture can govern.
Without a framework, every organisation will rediscover the same problem locally. One team will add a policy engine. Another will add prompt guardrails. A third will wrap APIs with a gateway. A fourth will build an agent-specific workflow. Each move will solve something real. None of them will create a shared way to govern the translation from intent into execution.
The result is predictable: local controls, inconsistent semantics, fragmented auditability, and a governance model that exists only because everyone hopes the pieces behave together. That is not architecture.
A mediation plane tells us where the responsibility sits. The Intent-to-Contract Framework tells us how to design it.
Four composition blocks, ten typed objects, one lifecycle, six maturity levels. A single image to anchor everything that follows.
1. From a missing layer to a formal framework
The agentic problem is not that agents call tools. The problem is that agents turn goals into trajectories.
A user expresses an objective. The agent interprets it, decomposes it, selects tools, sequences actions, adapts to responses, and proposes a path through the enterprise. That path may be technically valid at every step and still be business-invalid as a whole. This is the gap classical architecture was never asked to own.
Traditional enterprise architecture governed contracts between deterministic systems. API contracts, message schemas, process flows, state machines, and integration patterns all assumed that the caller already knew what it was doing. The client submitted a request. The system validated and executed it.
Agentic systems change the caller. The caller now interprets the goal. It does not merely invoke a predefined operation; it composes a candidate execution path. That means the architectural object to govern is no longer only the interface. It is the trajectory.
A framework is needed because trajectories cannot be governed with isolated technical controls. They require typed artefacts, lifecycle stages, shared invariants, decision traces, and recovery semantics.
The framework exists for one reason: to make the passage from interpreted intent to contractual execution explicit, governable, testable, and auditable.
2. The framework in one sentence
The Intent-to-Contract Framework is a formal model for transforming an interpreted business intent into a governed execution trajectory, constrained by contextual capabilities, validated against business invariants, executed through enterprise contracts, and reconciled through recorded facts.
In simpler terms: the framework turns what the agent thinks should happen into what the enterprise can safely allow to happen.
It does not replace agents. It does not replace APIs. It does not replace workflows, policy engines, gateways, or event platforms. It gives them a common governance structure.
The agent remains useful because it can interpret, plan, and adapt. The enterprise remains safe because execution is mediated through explicit contracts, declared policies, validated trajectories, and traceable outcomes.
The framework is the boundary object between two regimes: the agentic regime, where intent is interpreted, and the enterprise regime, where execution must be contractual. That boundary cannot be improvised.
3. The core idea: intent is not authority
The first principle of the framework is simple. An intent is not an execution authority.
A user may ask an agent to resolve a customer dispute, approve an exception, update a contract, refund a payment, or adjust a workflow. The request may be legitimate. The agent may understand it correctly. The proposed action may even be reasonable. None of that makes the action authorised.
In classical systems, authority is usually attached to identity and operation. If a user has the role, and the operation is exposed, the call is allowed. That model is too weak for agentic execution. Agents do not perform isolated calls. They compose paths.
Authority must therefore apply not only to who is acting and what tool is invoked, but also to why the tool is invoked, in which context, at which stage of a trajectory, under which business constraints, with which downstream consequences, and with what recovery path if the interpretation proves wrong. This is why tool access is not governance.
Visibility is not permission. Permission is not coherence. Coherence is not auditability. Auditability is not recovery.
The framework separates these concerns so that they can be designed deliberately instead of absorbed accidentally by the agent, the prompt, or the backend service.
4. The binding grammar: from responsibilities to objects
The previous article named six responsibilities the mediation plane must hold: enrich, constrain, validate along the trajectory axis, and secure, trace, recover continuously across it.
Naming a responsibility is a precondition for governing it. It is not yet governance.
A responsibility becomes governable when it is anchored on a typed object the architecture can reason about. Naming the responsibility is not enough; the framework must also define what it operates on.
The framework closes this gap by binding each responsibility to one or more typed objects. This binding is the framework’s first grammar. Responsibilities act as verbs, typed objects as nouns, and governance emerges only when the two are bound by explicit rules. A responsibility named without an object is a slogan; an object typed without a responsibility is a data structure; only the binding produces a governable control.
Enrich anchors on Intent and Context Envelope: it turns a raw goal into a governed situation. Constrain scopes Capability: it decides what the agent may do in this specific context. Validate evaluates a Trajectory against Invariants and contract preconditions before invoking Contracts. Secure spans Capability, Trajectory, Contract, Event, and Decision Trace, because authorisation, integrity, and accountability must hold before, during, and after execution. Trace produces the Decision Trace and links it to Events. Recover is anchored on Compensation and Escalation, but consumes Events and Decision Traces to open a governed corrective trajectory.
The six responsibilities of the mediation plane become governable when bound to ten typed objects. Responsibilities act as verbs; typed objects act as nouns; the binding is the rule that makes governance explicit.
Once each responsibility has a typed anchor, the next move is to type the objects themselves.
5. The composition grammar: how typed objects form trajectories
The binding grammar names which responsibility owns which object. The composition grammar shows how those objects combine to produce a trajectory. The composition grammar starts with a metamodel.
Not because architects need more diagrams, but because untyped concepts become ungoverned runtime behaviour. If an organisation cannot name the objects it governs, it cannot govern them consistently.
The metamodel is best read in four composition blocks: the upstream objects that carry the goal, the decision objects that turn the goal into a candidate path, the downstream objects that record what the system has committed to, and the transverse objects that hold the trajectory together across time.
Upstream objects
The upstream block holds what the system knows before it decides.
Intent is the interpreted objective submitted to the system. It may originate from a human instruction, a business process, another agent, an event, or an automated trigger. It is not yet executable. It is a hypothesis about what should happen.
The framework treats intent as input to governance, not as a command. An intent should carry at least: the requester, the objective, the target business object, the expected outcome, the urgency, the declared constraints, and the confidence level of interpretation.
Context Envelope is the governed view of the situation. It includes facts the agent may not know: customer status, workflow state, regulatory constraints, risk signals, contractual obligations, previous decisions, data quality markers, open incidents, and policy conditions.
The context envelope is not just enrichment. It is the factual boundary within which the intent will be judged. Poor context produces false freedom: the agent appears autonomous because the system failed to expose the constraints that should have shaped its choices.
Decision objects
The decision block holds what the system uses to turn the goal into a candidate path.
Capability is a business-level action surface exposed to the agentic system under governance. It is not the same thing as an API endpoint. An endpoint is a technical contract. A capability is the governed meaning of an action: what it allows, when it can be used, under which preconditions, with what side effects, and under which scope restrictions.
The framework forces a distinction between available tools and authorised capabilities. Visibility is never permission.
Invariant is a business condition that must remain true across the trajectory. Some invariants are local: a field must be present, a status must be allowed, a balance must not be negative. The important invariants in agentic execution are cross-step invariants: refund must not precede dispute suspension, cancellation must not bypass retention rules, notification must follow consent, escalation must precede high-risk execution. These invariants often live nowhere today. The framework gives them a home.
Trajectory is the candidate path from intent to outcome. It contains the proposed sequence or graph of actions, dependencies, checkpoints, assumptions, compensations, and expected facts. This is the central object of the framework.
A single call can be valid while the trajectory is wrong. A trajectory can be valid at the start and become invalid mid-execution when new facts appear. A trajectory can require escalation even if each underlying tool is technically available.
Downstream objects
The downstream block holds what the enterprise has actually committed to.
Contract is the deterministic execution surface of the enterprise. It may be an API, a command, a message schema, a workflow transition, a batch operation, or a service interface. Contracts remain essential. They are the point where the enterprise commits to execution. But contracts alone are local: they validate the step, not the trajectory.
Event is the recorded fact produced by execution. In the framework, events are the contract surface of truth. Intent remains a hypothesis. Events become facts. This distinction protects the enterprise from trusting the agent’s interpretation as if it were already business reality.
The composition reads in one direction: the trajectory invokes one or more contracts, and contract execution emits events. The framework never lets a trajectory emit an event directly. Events are facts because they are the observable consequence of a commitment, not the prediction the agent made about that commitment.
Transverse objects
The transverse block holds what spans the trajectory rather than living at any single point in it.
Decision Trace is the audit artefact of agentic governance. It is not an execution log. The execution log records what happened. The decision trace records why a trajectory was allowed, constrained, rejected, escalated, compensated, or modified. It links intent, context, policies, candidate trajectories, rejected alternatives, selected path, execution contracts, emitted events, human interventions, and compensation decisions.
Without a decision trace, the system may be observable but not explainable.
Compensation is a governed corrective action. It is not a hidden rollback. It does not pretend nothing happened. It emits new facts that restore coherence while preserving history. Compensation is not an operational afterthought. It is part of the trajectory design.
Escalation is the transfer of a decision to a human or higher-level policy authority when the framework cannot safely reduce uncertainty. Human oversight is not a patch for weak automation. It is a governed control point for ambiguous, high-impact, or policy-sensitive execution.
Ten typed objects compose. Intent and context envelope shape decision conditions. Capability and invariant constrain what the trajectory may look like. The trajectory invokes contracts; contract execution emits events. Decision trace, compensation, and escalation are transverse responsibilities that govern the composition over time.
6. The lifecycle grammar: from interpreted goal to recorded fact
Binding gives the framework its verbs and nouns. Composition gives it its sentences. The lifecycle gives it tense: the rules under which the sentences unfold in time. The lifecycle is the framework’s third grammar, and the one that turns governance from a static design into a continuous operation.
The framework becomes operational through a lifecycle.
The lifecycle is not a rigid workflow. It is a canonical sequence of responsibilities that can be implemented differently across domains. It is also not strictly linear: reconciliation feeds back, compensation reopens governed trajectories, and escalation branches at any decision point where uncertainty exceeds the framework’s tolerance.
1. Capture the intent
The system receives the interpreted goal. At this stage, the intent is not trusted. It is normalised, classified, and attached to an identity, a business object, a domain, and an expected outcome.
The key question is not what the agent wants to do. The key question is what business objective is being proposed, and under whose authority.
2. Build the context envelope
The framework assembles the facts needed to judge the intent. This may include state from core systems, workflow history, risk scoring, data quality indicators, previous customer interactions, regulatory constraints, and policy obligations.
The agent should not be allowed to reason on a thin context while the enterprise holds thicker constraints elsewhere.
3. Scope the capabilities
The framework computes the subset of capabilities available in this precise context. This is dynamic. It depends on identity, role, business state, risk level, regulatory status, time, thresholds, previous actions, and the trajectory already taken.
Static tool catalogues are insufficient because they expose possibility, not acceptability.
4. Generate or receive a candidate trajectory
The agent proposes a path. Depending on the architecture, the plane may let the agent generate the candidate trajectory, generate it jointly, or constrain the agent through a predefined set of trajectory templates. What matters is that the trajectory becomes explicit before execution. The enterprise should not discover the path only by reading logs after the fact.
5. Validate the trajectory
The trajectory is evaluated against business invariants, policies, preconditions, sequencing rules, separation-of-duty constraints, data consistency requirements, and recovery feasibility. Validation is not only syntactic. It asks whether the path makes business sense.
6. Execute through contracts
Only after validation does the framework invoke enterprise contracts. The backend systems remain deterministic. They are not asked to understand the intent. They execute validated commands, transitions, or messages. This preserves the enterprise contract model while allowing agentic flexibility upstream.
7. Record facts and decision trace
Each execution step produces events or state changes. The framework links those facts to the decision trace: original intent, context, policies applied, trajectory selected, human decisions, rejected options, and compensation points. This is the difference between logging activity and governing behaviour.
8. Reconcile outcome against intent
Execution is not the end. The framework compares recorded facts with the intended outcome. Did the trajectory satisfy the goal? Did new events reveal stale context? Did a downstream response create a new obligation? Did a partial failure require correction? Reconciliation moves governance from pre-execution control to continuous control.
9. Compensate or open a corrective trajectory
When deviation occurs, the framework does not rely on manual rollback as the default operating model. It opens a governed corrective trajectory, issues compensating commands where necessary, records the resulting compensating events, and preserves the audit chain. The agent may assist, but recovery remains governed by the same framework.
Nine steps, three feedback paths: reconciliation feeds back into context, compensation reopens a governed trajectory through intake, and escalation can branch from multiple decision points to human oversight. The loop is what distinguishes governance from inspection.
A composite case: onboarding a regulated customer
Consider a corporate customer onboarding process in a regulated environment.
The user intent sounds simple: onboard this customer and activate the required services if compliance checks are complete.
An agent could interpret this objective, inspect documents, call KYC services, create the customer record, activate accounts, notify internal teams, and send confirmation to the customer. Each action may map to a valid API.
Without the framework. The agent activates a service because the standard KYC endpoint returned a positive status, while missing that the customer belongs to a segment requiring enhanced due diligence before activation. The service activation is technically valid. The business trajectory is invalid. The error surfaces weeks later as a regulatory finding, and root cause analysis identifies no single failure because every step was technically valid when it ran.
With the framework. The intent is captured and classified as regulated onboarding. The context envelope pulls the customer segment, jurisdiction, document status, risk score, sanctions screening result, beneficial ownership status, and pending compliance markers. Capabilities are scoped: create draft customer record is allowed, service activation is blocked until enhanced due diligence is complete, notification is limited to internal teams, and external confirmation requires a human checkpoint.
The candidate trajectory is validated against invariants: no activation before compliance clearance, no external confirmation before legal entity verification, no payment service enablement when beneficial ownership is incomplete, no bypass of enhanced due diligence for high-risk jurisdictions. The agent remains useful: it can prepare the case, collect missing elements, propose the next best action, draft notifications, and coordinate the process. But it cannot silently turn interpretation into execution.
Same intent, same tools, two governance regimes, two outcomes. Without the framework, technical validity hides a regulatory breach. With the framework, enhanced due diligence and beneficial ownership status enter the context envelope before any capability is unlocked, and the trajectory cannot reach activation without a clean clearance.
The framework does not slow the enterprise down. It prevents speed from becoming uncontrolled authority.
7. The framework artefacts
A framework must produce artefacts. Otherwise it remains a philosophy.
The Intent-to-Contract Framework introduces a small set of artefacts that enterprise architects, platform teams, security teams, and AI teams can share. Each artefact corresponds to one or more lifecycle steps and binds back to a responsibility of the mediation plane.
Intent Schema defines how intents are represented: objective, actor, domain, business object, expected outcome, urgency, constraints, confidence, source, and interpretation metadata. The schema makes intent inspectable before it becomes action.
Context Map defines which facts must be resolved before a class of intent can be evaluated. For example: customer status, contract state, dispute flag, consent record, account restrictions, open incidents, risk tier, and regulatory markers. The context map prevents agents from operating on incomplete business reality.
Capability Matrix maps capabilities to roles, contexts, risk levels, thresholds, preconditions, required approvals, and forbidden combinations. The matrix is not a static RBAC table. It is a contextual permission model for trajectories.
Same user, same tool, two permission models. RBAC is necessary but insufficient for agentic trajectories: it answers whether a role may call an endpoint. The capability matrix answers whether the capability should be authorised here, now, under this state of play, and re-asks the question continuously as the trajectory progresses.
Invariant Catalogue captures business rules that apply across steps and systems. This is one of the most important artefacts because these invariants are often implicit, tribal, or scattered. The catalogue makes them declarative, testable, and reviewable.
Trajectory Specification defines approved, conditional, forbidden, and escalated trajectory shapes. It may describe allowed sequences, dependency graphs, checkpoints, compensation anchors, and expected events. The point is not to eliminate agentic flexibility. The point is to keep flexibility inside governed boundaries.
Decision Trace Schema defines what must be captured for auditability: intent, context, policies applied, candidate paths, rejected alternatives, selected path, approvals, executed contracts, emitted events, deviations, and compensation actions. Without this schema, every team logs differently and governance becomes forensic archaeology.
Recovery Playbook defines how deviations are handled: compensation events, partial replay, human escalation, isolation of corrupted state, notification obligations, and reconciliation rules. Recovery cannot be designed after the incident.
Maturity Matrix assesses whether the mediation responsibility is absent, implicit, fragmented, explicit, or industrialised. This matters because many organisations will believe they have governance because they have gateways, prompts, policies, and logs. The maturity matrix tests whether those controls actually govern trajectories.
Eight artefacts crossed with the six responsibilities of the mediation plane. P marks a primary responsibility; C marks a contributing one. The matrix is the contract between governance design and runtime behaviour.
A worked specification
The framework becomes real only when these artefacts can be written down.
The artefacts above are families. What does an instance look like? The following minimal specification names a single intent type and writes its governance down explicitly. It is the kind of artefact a domain team would author once and review under the same discipline as any other architecture object.
Intent type regulated_customer_onboarding
Owner domain_architecture + compliance
Policy version onboarding_policy_2026_04
Required context jurisdiction, risk_score, enhanced_due_diligence_status,
beneficial_ownership_status, sanctions_screening_result
Capability activate_services
Preconditions enhanced_due_diligence_status = complete
sanctions_screening_result = clear
beneficial_ownership_status = verified
Invariant service_activation requires compliance_clearance = true
external_confirmation requires internal_verification = complete
Escalation required if risk_score > policy_threshold
required if jurisdiction in enhanced_review_list
required if any precondition is missing
Expected event ServicesActivated
with reason_code = compliance_clearance_complete
Forbidden trajectory standard KYC positive -> activate services without enhanced
due diligence clearance
external confirmation before internal verification
payment service enablement without beneficial ownership
Decision trace intent_id, context_snapshot, policy_version,
evaluated_alternatives, selected_trajectory,
approval_decision, emitted_eventsA specification at this grain is not an implementation. It is a contract between the architect, the business, the compliance function, and the runtime. The same specification can be implemented by a workflow engine, a policy engine, a capability filter, or a combination of them. What the framework requires is that the specification exists, that it is reviewed, and that it is testable.
8. A maturity model for intent-to-contract governance
Most organisations will not move directly from direct tool access to a fully governed mediation framework. They will pass through maturity stages. The model below is descriptive, not aspirational: every organisation already sits somewhere on it, whether by deliberate design or by accumulated drift.
Level 0 — Direct tool access. The agent sees tools and calls them. Governance lives mostly in the prompt, the model provider, and the downstream API contracts. This is fast to build and fragile in production. The main symptom: tool visibility becomes permission.
Level 1 — Prompt-shaped governance. The agent receives instructions about what it should and should not do. This improves behaviour but does not create architectural guarantees. The system depends on the model following instructions consistently. The main symptom: governance disappears when the model drifts or the context becomes ambiguous.
Level 2 — Static control wrappers. The organisation adds gateway rules, static policy checks, tool allowlists, logging, and basic guardrails. This is better than nothing, but controls remain local. They govern individual calls, not trajectories. The main symptom: each step is valid, but the sequence can still be wrong.
Level 3 — Explicit mediation plane. The organisation introduces a control plane that enriches, constrains, validates, secures, traces, and recovers agentic execution. The main improvement is that trajectory governance becomes explicit. The main risk: each domain implements its own version with incompatible semantics.
Level 4 — Shared framework across domains. The organisation standardises intent schemas, capability models, invariant catalogues, trace formats, and recovery semantics. Teams can implement differently while speaking the same governance language. The main benefit: architecture becomes reusable instead of reinvented.
Level 5 — Operational sovereignty. The organisation can prove not only what agents did, but why actions were allowed, how alternatives were rejected, how policies shaped trajectories, how deviations were reconciled, and how human oversight was applied. At this level, agentic flexibility no longer means loss of control. The enterprise owns the behaviour of its system again.
Six levels with the dominant symptom of each. The ladder is read by symptoms, not by ambition: an organisation sits where its symptoms place it, not where its slide deck claims it.
Reading the maturity model
The model is an instrument, not a scorecard.
Three rules make it usable. First, an organisation sits at the lowest level for which the dominant symptom is observable in production, not at the highest level for which a control exists somewhere. A policy engine deployed in one domain does not lift the whole organisation above level 2. Second, regression is the normal mode of drift: organisations that reach level 3 in one domain often relapse to level 1 when a new agentic use case is launched under time pressure. Third, the gap between level 3 and level 4 is the hardest crossing, because it is no longer a technical investment; it is an organisational one. Sharing schemas, catalogues, and semantics across domains requires governance authority, not engineering throughput.
The maturity model exists to make these realities discussable. It is not a maturity certificate.
9. What changes for enterprise architecture
The Intent-to-Contract Framework expands the mandate of enterprise architecture.
Architects can no longer govern only APIs, events, domains, platforms, and integration flows. They must also govern the translation surface where interpreted goals become executable trajectories. That introduces new architecture questions.
What is the canonical representation of an intent? Which facts must be resolved before an agent can propose action? Which capabilities exist at the business level, beyond the technical APIs that implement them? Which invariants belong to a trajectory rather than to a service? What does a decision trace need to contain to satisfy audit, compliance, and operational review? How is recovery designed when the agent’s interpretation was plausible but wrong? Who owns the capability matrix? Who owns the invariant catalogue? Who validates that a trajectory is safe before execution? Who can approve exceptions?
These are not AI questions. They are architecture questions.
The organisations that treat them as prompt engineering questions will build brittle systems. The organisations that treat them as platform engineering questions only will build strong runtimes with weak governance. The organisations that treat them as enterprise architecture questions will have a chance to make agentic systems governable at scale.
10. The framework is not a product category
There will be products around this space.
Gateways will add agent controls. Observability platforms will add decision traces. Policy engines will add richer contextual evaluation. Workflow engines will add dynamic orchestration. Agent platforms will add governance modules. MCP servers will become
more policy-aware. All of that is useful.
But the framework is not a product category.
It is an architectural model for assigning responsibilities and making them coherent. A product may implement parts of it. A platform may host parts of it. A domain team may own parts of it. Security may enforce parts of it. Compliance may review parts of it. The framework exists to prevent those parts from becoming another fragmented control stack.
The framework at the centre, six product categories as adjacencies. Each category can implement a fragment of the framework. None of them, by default, is the framework. Tools can host responsibilities; they do not, by their existence alone, create the architectural responsibility that holds them together.
The question is not which tool implements the framework. The question is which responsibilities must exist, which artefacts must be governed, and how the organisation proves that intent was translated into execution safely. A stack made of a gateway, a policy engine, a workflow engine, an observability platform, and an MCP server can implement the framework. It does so only when the responsibility for the whole has an owner, when the artefacts are written down, and when the lifecycle is enforced across the stack rather than negotiated between its parts.
11. The hard part: making invariants explicit
The most difficult part of the framework is not technical. It is making business invariants explicit.
Enterprises run on rules that are often encoded nowhere cleanly. Some live in services. Some live in procedures. Some live in compliance documents. Some live in senior operators’ heads. Some live in exceptions that everyone knows but no system can name.
Agentic execution exposes this weakness brutally.
A deterministic workflow can hide implicit rules because the path is predefined. An agentic trajectory cannot. Once the path is generated at runtime, the system must know which paths are coherent and which are not.
This is why the framework cannot be owned by AI teams alone. The invariant catalogue requires enterprise architecture, business ownership, risk, compliance, security, and platform engineering to work together.
The agentic era will reward organisations that can turn implicit business knowledge into explicit, testable governance artefacts. That may sound bureaucratic. It is not. It is the price of allowing interpretation near execution.
12. The next move: from framework to patterns
The framework defines the grammar. But architects still need patterns.
How should a capability filter be designed when contexts change during a trajectory? How should an invariant validator sit in relation to an API gateway and a workflow engine? How should MCP servers be governed by the capability matrix without becoming a bottleneck? How should decision traces be structured so they remain useful at audit time without flooding observability budgets? How should human checkpoints be inserted into agentic trajectories without destroying flow? How should compensation be implemented in event-driven systems where order is not always preserved? How should agentic execution be separated across domains that already disagree on what a customer is?
Those are design questions. They require patterns, not principles. That is the subject of the next article.
The Intent-to-Contract Framework names the objects, the lifecycle, the artefacts, and the maturity path. The next step is to translate that model into concrete architecture patterns for governable agentic systems: capability filter patterns, invariant validator patterns, decision trace patterns, compensation patterns, and the integration patterns that bind them to existing platforms.
Because the enterprise does not need agents that can merely access tools. It needs agents whose behaviour remains within the boundaries of the system the enterprise is willing to own.
That is the real promise of intent-to-contract :
Not frictionless automation.
Governed execution.
Execution without loss of sovereignty.
