Feasibility-Negotiated Intent Contract

also known as Intent Negotiation Handler, Three-Valued Goal Contract, Counter-Offer Intent Gate

Let a caller state a goal with measurable expectations, audit it against hard system constraints before actuation, and reply with acceptance, a counter-offer naming the relaxed expectation, or a refusal naming the binding constraint.

This pattern helps complete certain larger patterns —

specialisesStochastic-Deterministic Boundary (SDB)★— Formalize the seam between an LLM proposal and a system action as a four-part contract — proposer, verifier, commit step, reject signal — so the contract itself, not the agent's good intent, gates side-effects.

Context

An agent sits in front of a system whose capacity is finite and physically bounded: a radio access network, an optical transport layer, a power schedule, a fleet. Callers do not want to name the configuration steps; they want to name an outcome, such as a latency ceiling for one traffic class during a given window. Standardised management interfaces have moved in the same direction, expressing a request as a set of declarative expectations with numeric targets rather than as a command sequence, and requiring the handler to report against those targets rather than only acknowledging receipt.

Problem

An ordinary tool call has two outcomes, success or error, and the caller learns which one applies only by making the call. Applied to a declarative goal against a constrained plant, that shape is unsafe. A goal that the plant cannot honour is discovered during actuation, after configuration has already been written and other traffic has already been disturbed, and the error that comes back says an action failed without saying which expectation was unreachable or by how much. The caller cannot replan from that, because a bare failure carries no information about what would have been achievable. Translating stated goals straight into configuration through heuristics produces exactly this: unpredictable behaviour on a live plant with no stable notion of what counts as a safe request.

Forces

A declarative goal is easier for a caller to state than a procedure, but the plant enforces its limits on procedures, so someone has to decide whether the goal is reachable before anything is written.
Discovering infeasibility by attempting actuation is the cheapest thing to build and the most damaging thing to run; on an O-RAN testbed, a direct-actuation baseline that translated operator intent straight into configuration produced harmful executions that a pre-actuation constraint audit eliminated.
Goal extraction from natural language is inherently probabilistic, while the decision to actuate must be deterministic, so the two cannot live in the same component.
A caller who is refused without a named cause will simply resubmit a near-identical goal, whereas a caller told which expectation was the binding one can relax it and converge.
The best achievable result is not a property of the goal alone; it depends on the resource situation at the moment of asking and changes over time, so feasibility has to be re-audited rather than cached as a static rule.

When to use

The caller states an outcome with measurable targets rather than a sequence of steps, and the handler controls a system with hard capacity or physical limits.
Actuating an unreachable goal is expensive or damaging, so infeasibility must be found before configuration is written rather than during it.
A partly satisfied goal is genuinely useful to the caller, so a named relaxation is worth more than a failure.
Goals from several callers compete for the same finite resources and have to be reconciled against commitments already accepted.
A natural-language front end proposes goals, and actuation must stay deterministic regardless of how confident that front end is.

When not to use

The action is cheap and trivially reversible, so attempting it and reading the error is a faster answer than auditing it.
No usable model of the system's constraints and current resource state exists, which leaves the audit guessing and its verdicts worse than the plant's own errors.
The goal admits no partial satisfaction, so there is no meaningful relaxation to counter-offer and a two-valued gate is the honest interface.
The question is permission rather than achievability, where an admit-or-deny policy gate is the simpler fit.
The caller's request is ambiguous rather than ambitious, in which case clarifying what was meant comes before auditing what can be delivered.

Example

An operator tells the network agent to hold video latency under 15 milliseconds for the stadium cell for the next three hours. The agent does not start changing the slice configuration. It checks the request against the cell's current load and its radio limits, finds that 15 milliseconds is not reachable while the emergency-services slice keeps its guaranteed share, and answers that it can hold 22 milliseconds instead, naming the guarantee that blocked the tighter target. The operator accepts the 22 milliseconds, and only then is anything reconfigured.

Diagram

sequenceDiagram participant C as Caller participant H as Intent handler participant M as Constraint model participant P as Plant C->>H: Goal as expectations with objects and targets H->>M: Audit whole set against live resource state alt All expectations satisfiable M-->>H: feasible H-->>C: Accept - expectations become the contract H->>P: Actuate accepted contract P-->>H: Fulfilment measured against targets else Satisfiable only after relaxation M-->>H: infeasible - smallest relaxation found H-->>C: Counter-offer - names relaxed expectation and shortfall C-->>H: Accept degraded contract or restate goal else No relaxation within stated bounds M-->>H: infeasible - binding constraint identified H-->>C: Refuse - names the binding constraint end

Solution

Therefore:

Split the exchange into a proposal and a contract. The caller submits a goal as a set of expectations, each with a target, an object it applies to, and the context in which it holds; nothing about how to reach it. The handler does not actuate on receipt. It first runs a deterministic audit of the whole expectation set against a model of the controlled system — live resource state, physical limits, standing commitments already accepted for other callers — and decides whether every expectation can hold at once. That audit has three outcomes, not two. If the set is satisfiable, the handler accepts and the expectations become the contract it is now measured against. If the set is unsatisfiable but a nearby set is not, the handler returns a counter-offer: the same goal with one expectation relaxed, naming which one and quoting the shortfall as a number, so the caller can accept the degraded contract or restate the goal. If no relaxation inside the caller's stated bounds is reachable, the handler refuses and names the binding constraint rather than returning a generic failure. Only an accepted contract reaches the actuator. After actuation the handler keeps measuring delivered values against the accepted targets and reopens the negotiation when the contract degrades, which keeps the audit honest as the resource situation moves. The model may propose any goal at all, because the component that decides achievability is not the component that wrote the goal.

What it gives you

An unreachable goal is rejected before any configuration is written, so infeasibility costs a reply rather than a disturbance to a live plant.
A counter-offer gives the caller a usable second option instead of a failure, so a slightly-too-ambitious goal converges in one round rather than being abandoned or blindly resubmitted.
Naming the binding constraint turns a refusal into replanning information, and naming the relaxed expectation makes an accepted degradation explicit rather than silent.
Probabilistic goal extraction is decoupled from governed execution, so a mis-parsed or over-ambitious goal cannot reach the actuator on the strength of the parser's confidence.
The accepted expectations double as the monitoring contract, so drift after actuation is measurable against the same numbers the caller agreed to.

What it costs you

The audit is only as good as the constraint model behind it; a model that omits a real limit accepts goals the plant cannot honour, and one that is too conservative refuses goals it could have served.
Maintaining a live model of resource state, physical limits and already-accepted contracts is ongoing work that grows with the plant, and stale state produces confident wrong verdicts.
Searching for the smallest useful relaxation is a separate optimisation problem, and a handler that returns an arbitrary relaxation instead of the least damaging one trains callers to ignore counter-offers.
The audit adds latency in front of every change, which is a poor trade for goals whose worst case is trivially reversible.
A three-valued reply is a larger interface commitment than success-or-error, and every caller has to be written to handle the middle case.

What this pattern forbids. The handler must not actuate any expectation before the feasibility audit has run against current resource state, and it may not answer with a bare success or error: a relaxed acceptance must name the expectation it relaxed and the quantified shortfall, and a rejection must name the binding constraint. Only an accepted contract reaches the actuator.

And the patterns that stand alongside it, or against it —

alternative-toSolver-Ready Formulation Handoff★— Have the agent emit a declarative optimisation model — decision variables, objective, hard constraints — in a solver-agnostic representation, and let an exact solver produce the decision with its feasibility or optimality certificate.
complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
complementsAffordance Grounding Before Action·— Have a vision-language model ground each candidate action against the current scene and predict its affordance, so that actions the environment cannot physically support are discarded before any reach the controller.
complementsSimulate Before Actuate★— Before issuing an irreversible action, run a deterministic simulation that computes pre-conditions, invariants, and expected deltas; require a verifier — automated or human — to green-light the simulated outcome before the real command is sent.
complementsTyped Refusal Codes★— Define a single source of truth for machine-readable refusal codes across all guard surfaces, so refusals can be triaged mechanically rather than by string-grepping ad-hoc human-readable messages.
complementsGraceful Degradation★★— When a dependency fails, downgrade the user-facing experience to a working subset rather than failing entirely.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance

Source: patterns/feasibility-negotiated-intent-contract.md on GitHub · commit c389d0e · view history
Added to catalog: 2026-09-10
Last updated: 2026-09-10
Contribute: open an issue or PR at github.com/agentpatternscatalog/patterns.