The Intent Contract: A Beginner’s Guide to Turning Vague Requests Into Safe AI Work

People rarely describe work as a complete specification. They say, “Handle the renewal,” “Clean up this forecast,” or “Get the customer an answer.” A capable colleague reconstructs the missing detail from the situation: what outcome matters, which constraints apply, and where authority ends.

An AI agent needs the same operational clarity, but it should not depend on a long prompt. The useful mechanism is an intent contract: a compact, testable representation of what the user wants the system to accomplish and under what conditions. It is not a legal document or another intake form. It is the working agreement an agent creates before consequential action.

What an intent contract contains

A task statement names an activity. An intent contract defines acceptable completion. “Review these invoices” is a task statement. “Identify duplicate or policy-inconsistent invoices, explain each flag, and leave payment status unchanged” is an intent contract.

A practical contract contains six fields:

These fields separate interpretation from execution. That matters because an agent can execute a task flawlessly while pursuing the wrong outcome.

The mental model: compile intent before acting

Think of ordinary language as source material, not executable instruction. The agent “compiles” conversation and business context into an intent contract. It then validates that contract before selecting tools or changing systems.

The process has four stages:

1. Extract: Identify explicit outcomes, objects, limits, and deadlines.
2. Infer: Fill low-risk gaps from reliable context, such as the current record, role permissions, or established workflow.
3. Test: Look for ambiguity that could materially change the result.
4. Bind: Attach the validated contract to the plan, actions, and final verification.

This is different from asking the user to approve a paraphrase after every request. Validation should match risk. A contract for drafting an internal summary may remain implicit. A contract for changing customer terms should be surfaced and confirmed.

Ambiguity is not one problem

Beginners often treat uncertainty as a single confidence score. Operationally, the location of uncertainty matters more than its average level.

• Outcome ambiguity: “Improve the pipeline” could mean better data quality, higher conversion, or more coverage.
• Scope ambiguity: “Update the accounts” does not identify which accounts, fields, or time period.
• Constraint ambiguity: The requested result is clear, but applicable policy or contractual limits are not.
• Authority ambiguity: The agent knows what should happen but not whether it may perform the action.
• Completion ambiguity: “Resolve the issue” may mean sending a reply, restoring service, issuing credit, or obtaining customer acceptance.

Each type requires a different response. Missing authority should trigger a permission check, not a broad request for more context. Missing scope may be resolved by the active record. Missing completion criteria may require one focused question: “Should I stop after preparing the adjustment, or submit it for approval?”

A worked example: “Take care of the late order”

Suppose an account manager writes, “Take care of the late order for Northwind.” The customer record shows one delayed order, a promised delivery date, an unresolved carrier exception, and no approved credit.

A weak agent might send an apology, cancel and replace the shipment, or issue a discount. Each action is plausible. None is safely implied.

A stronger agent constructs this provisional contract:

• Outcome: Give the customer an accurate recovery path.
• Scope: The single open order currently past its promised date.
• Constraints: Do not promise a date unsupported by the carrier; follow service-recovery policy.
• Authority: Investigate and draft communication; no credit or replacement authorization is evident.
• Evidence: Order status, carrier event, inventory availability, and customer terms.
• Completion test: A verified recovery option is ready and the customer receives an approved update.

The agent can investigate immediately because that work is reversible and within scope. If inventory permits replacement but approval is required, it asks one decisive question: “The original shipment has no confirmed recovery date; should I submit a replacement for approval or send the customer the current carrier update?” The question exposes the decision rather than transferring the entire analysis back to the user.

How to implement the first version

Start with one workflow where requests are conversational but outcomes are observable: preparing refunds, triaging support cases, reviewing contracts, or updating forecasts. Avoid beginning with an open-ended executive assistant spanning every system.

Define a compact schema

Use the six fields above. Keep each field short enough to inspect. Add workflow-specific fields only when they alter execution. A refund workflow may need payment method and policy window; a research workflow may need source cutoff and audience.

Specify inference rules

Document what the agent may infer without asking. It might use the active customer record to resolve identity, but not infer authorization from seniority. It might apply the published current policy, but not assume an undocumented exception still holds.

Map uncertainty to behavior

For each field, decide whether uncertainty permits work, permits only reversible preparation, or blocks action. Missing formatting preferences should not halt analysis. Missing payment authority should block disbursement.

Verify against the contract

Before marking work complete, compare the result with every field. Did the agent cover all in-scope records? Preserve prohibited fields? Cite the required evidence? Stop at the authorized boundary? This final check turns the contract into an operational control rather than prompt decoration.

Design trade-offs to expect

More explicit contracts improve auditability but can make simple interactions feel bureaucratic. More inference reduces friction but increases the chance of silently choosing the wrong interpretation. The right design varies by consequence.

Use a lightweight, mostly implicit contract when actions are reversible, visible, and cheap to correct. Surface key fields when an action affects customers, money, access, commitments, or regulated records. Require confirmation when competing interpretations would produce materially different actions.

Do not force every field to be user-provided. The agent should assemble what it can from the request and trusted context. The user’s role is to resolve consequential ambiguity, not complete a machine-generated questionnaire.

What to ignore for now

Do not begin by perfecting a universal ontology of human intent. It will delay useful deployment and still fail to capture local operating rules. Build contracts around specific workflows and actual decisions.

Ignore elaborate emotional interpretation unless the workflow genuinely depends on it. Customer sentiment may affect response tone, but it should not independently authorize compensation. Also avoid optimizing a single confidence percentage. A high overall score can conceal uncertainty about the one field that controls whether an action is permitted.

Finally, do not equate longer prompts with clearer intent. Length often mixes goals, background, examples, and speculation. The agent’s job is to reduce that material into a small agreement that can govern execution.

The operating standard

An effective intent contract should be inspectable, actionable, and falsifiable. A reviewer should be able to see why the agent acted, which boundaries it observed, and what counted as done. If the outcome changes midstream, the contract should change before the action plan does.

The beginner’s test is straightforward: take a common vague request and ask whether two competent operators could interpret it differently. If they could, identify which contract field contains the disagreement. Resolve only the uncertainty that changes the decision, then let the agent proceed within the resulting boundary.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.