The Intent Contract: A Beginner’s Guide to Getting AI to Define “Done”

Many AI failures begin after the system has correctly understood the topic. A manager asks, “Prepare the renewal plan,” and the AI knows the customer, contract, and account history. It still may produce the wrong artifact: a generic summary instead of a negotiation strategy, an internal memo instead of customer-ready material, or a list of recommendations with no owner.

The missing element is often not context. It is a shared definition of completion. Before doing substantial work, an AI needs to establish what outcome counts as done, what conditions the result must satisfy, and how completion will be verified. That compact agreement is an intent contract.

What an Intent Contract Is

An intent contract is a structured interpretation of a request. It converts natural language into an operational agreement between the requester and the AI. The word contract does not imply legal force. It means the terms of success are explicit enough to guide execution and evaluation.

A useful intent contract contains five parts:

• Outcome: The business result the work should enable.
• Deliverable: The artifact or action the AI will produce.
• Acceptance criteria: Observable conditions the result must satisfy.
• Boundaries: Limits on scope, methods, sources, tone, authority, or risk.
• Proof of completion: Evidence that the work was performed and checked.

Consider the request, “Help me prepare for the Acme renewal.” A workable contract might be: produce an internal negotiation brief that protects margin while preserving the relationship; include the account history, likely objections, walk-away conditions, proposed concessions, and unanswered questions; use only CRM and contract records; label unsupported assumptions; do not contact the customer; provide source links and a final review checklist.

That formulation gives the AI more than instructions. It gives the work a finish line.

The Mental Model: A Request Is Not Yet a Specification

People communicate through compression. Colleagues rely on shared history, organizational norms, and role knowledge. “Prepare the renewal plan” may carry an unspoken template for an experienced account director. An AI cannot safely assume every part of that template.

Treat the original request as evidence of intent, not a complete specification. The AI’s job is to infer a candidate contract, expose consequential uncertainty, and confirm only what materially changes the work.

This hierarchy prevents a common mistake: optimizing the deliverable while missing the outcome. A polished slide deck is not successful if the decision maker needed a one-page recommendation before a meeting.

Acceptance Criteria Are the Core Mechanism

Acceptance criteria turn subjective expectations into testable conditions. They should describe observable properties of the result rather than vague aspirations.

“Make it executive-ready” is weak because different readers interpret it differently. Stronger criteria might require a recommendation in the opening paragraph, a concise explanation of trade-offs, explicit decision points, and detailed evidence separated from the main narrative.

Good criteria usually address four dimensions:

• Coverage: Which questions, cases, entities, or time periods must be included?
• Quality: What level of reasoning, accuracy, specificity, or tone is expected?
• Format: What structure, length, file type, or audience convention applies?
• Validation: Which checks, approvals, citations, or reconciliations are required?

Criteria can conflict. A request may demand both comprehensive analysis and a short memo. The AI should resolve that tension through structure: place the decision and rationale in the memo, then attach supporting detail. It should not silently choose one criterion and ignore the other.

How the AI Should Form the Contract

A capable system should not force users to complete a long intake form. It should construct the most likely contract from the request, available context, and established working patterns.

1. Identify the operative verb. “Review,” “recommend,” “draft,” “approve,” and “send” imply different outputs and authority.
2. Find the business object. Determine what the work concerns: a renewal, incident, candidate, forecast, policy, or customer response.
3. Infer the downstream decision. Ask what someone will decide or do with the result. This often reveals the real outcome.
4. Propose acceptance criteria. Derive them from the audience, artifact type, risk, and organizational norms.
5. Locate consequential ambiguity. Focus on uncertainties that could change the output, trigger an external action, or create material rework.
6. State the contract compactly. Confirm the interpretation in plain language before expensive or irreversible execution.

For a low-risk request, confirmation may be implicit: “I’ll draft a customer-ready reply that acknowledges the delay, gives the revised date, and avoids discussing compensation.” The user can correct it immediately. For a high-risk action, explicit approval should be required before execution.

A Worked Example: From Vague Request to Verifiable Work

Suppose an operations leader says, “Look into last month’s support problems and tell me what to fix.”

A weak response begins summarizing tickets. A stronger AI identifies that “support problems” could mean volume, response time, resolution quality, customer sentiment, or operational failures. It also recognizes that “what to fix” requires prioritization, not merely description.

The proposed intent contract could be:

Produce an internal diagnostic for the operations review. Identify the most consequential recurring support failure modes from last month, distinguish symptoms from causes, and recommend actions that the support team can control. Rank recommendations by customer impact, operational effort, and confidence in the evidence. Use ticket data and approved internal documentation. Exclude individual performance judgments unless the evidence is direct and relevant. Cite the ticket groups supporting each finding and list data gaps.

This contract changes the execution plan. The AI must group related cases, test possible causes, separate frequency from consequence, and preserve an evidence trail. It cannot satisfy the contract with a topic summary.

Verification is equally concrete. Each recommendation should connect to a diagnosed failure mode; each failure mode should connect to ticket evidence; uncertain causal claims should be labeled; proposed actions should have an owner or owning function. “Done” now means something inspectable.

Where Intent Contracts Commonly Break

Confusing Activity With Outcome

“Analyze the pipeline” describes activity. “Identify which deals require executive intervention before forecast review” describes an outcome. When possible, rewrite work around the decision it supports.

Using Hidden Quality Standards

If a team rejects work for violating conventions the AI could not access, the problem is not simply model quality. Templates, examples, review rules, and audience expectations must be available as context or encoded as criteria.

Allowing Scope to Expand Silently

While investigating one issue, the AI may discover adjacent problems. It should record them separately rather than absorbing them into the current assignment. Scope expansion increases latency, cost, and the chance of an unusable result.

Declaring Completion Without Evidence

Producing an artifact is not the same as satisfying the contract. Completion should be reported against criteria: what was delivered, what was checked, what remains uncertain, and what requires human approval.

Your First Implementation

Start with one recurring knowledge workflow where rework is common: executive briefs, account plans, incident reviews, hiring summaries, or policy drafts. Do not begin with autonomous external actions.

Create a short contract template with six fields:

• Business outcome
• Primary deliverable and audience
• Required contents
• Constraints and prohibited actions
• Evidence or source requirements
• Completion checks

Have the AI populate the template from each request rather than asking the user to fill it out. Require a question only when the answer would materially alter the deliverable, authority, or risk. After completion, compare reviewer feedback with the contract. Repeated feedback such as “too detailed,” “missing financial impact,” or “not ready to send” should become explicit criteria for future work.

Track failures by contract component. If outcomes are usually correct but formatting causes rework, improve artifact standards. If deliverables look polished but do not support decisions, improve outcome inference. If claims cannot be defended, strengthen proof-of-completion requirements.

What to Ignore for Now

Do not begin by designing a universal intent ontology, scoring every criterion, or building a complex contract language. Those may become useful at scale, but they can obscure the basic operating discipline.

Also ignore the goal of eliminating all ambiguity. Human work is rarely specified perfectly. The objective is to expose ambiguity that changes the decision, the artifact, or the risk profile. Minor presentational choices can remain with the AI.

Finally, do not treat the contract as a static prompt pasted before every task. It is a living agreement. New evidence may invalidate an assumption, reveal an unavailable source, or make a criterion impossible to satisfy. The AI should surface the conflict, propose a revision, and obtain approval when the change is consequential.

An AI that understands early is useful. An AI that can also define, test, and report what “done” means is operationally dependable. The intent contract is the bridge between those two capabilities.

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.