Klarna deployed an AI customer service agent that resolved tickets faster than any human.1 By every prompt-level metric, it was succeeding. It was efficient. It was responsive. It was destroying customer relationships.
The agent was optimizing for resolution speed — the metric it was given. But Klarna's actual organizational intent was customer retention. Speed and retention are correlated up to a point, then they diverge. The agent crossed that point and kept going. It succeeded at exactly what it was told to succeed at. And it failed at what the organization actually needed.
Stuart Russell named this the King Midas problem: AI optimizes exactly what you specify, not what you mean. I kept missing it in my own builds before I had a name for it. The gap between specification and meaning is where intent engineering lives — and it is the bottleneck most teams hit right after they ship their first agent.
The Three Disciplines of AI
The history of how organizations interact with AI runs through three disciplines.
Prompt engineering asked: "How do I talk to AI?" It was the era of jailbreaks and magic phrases — discovering that certain phrasings produced better outputs, that certain system prompts unlocked capabilities, that the model responded to the literal words in ways that could be tuned. It was session-based, synchronous, and human-present. Every response was a human in the loop.
Context engineering asked: "What does AI need to know?" It was the era of RAG pipelines and retrieval architectures — discovering that the model's output quality depended heavily on what information was in its context window, that well-organized knowledge beat raw model capability for domain-specific tasks. It was about building the information infrastructure that made model capability useful.
Intent engineering asks: "What does the organization need AI to want?" Nate Jones is the person who sharpened this framing for me, and credit where it's due — the two-layer structure in this chapter is built on his work. It's the emerging discipline: even capable models with good context will optimize for the wrong thing if the organization's actual goals, trade-offs, and decision boundaries aren't explicitly encoded. Not a prompt problem. Not a knowledge problem. A question of whether the model's objective function matches the organization's actual objectives.
A company with a mediocre model and extraordinary intent infrastructure will outperform a company with a frontier model and fragmented, unaligned knowledge. The intelligence race between AI models is being replaced by an intent race. The most important investment is not the model subscription — it's the organizational intent architecture.
Starting From Nothing: Your First Intent Contract
I'll admit the first few agents I shipped didn't have an intent contract either. Most teams don't. They have vague goal statements ("improve customer experience"), implicit trade-offs (speed matters more than thoroughness because that's how the team has always been measured), and tribal knowledge about what's prohibited (don't promise things we can't deliver). None of it is encoded. All of it shapes agent behavior indirectly through training data and prompt choices.
The first intent contract doesn't have to be comprehensive — it has to be honest.
The practical starting point is the three critical questions, applied to the one agent instruction that matters most. Not the most complex instruction — the most consequential one. For a customer service agent, that's probably the instruction governing what to do when a customer asks for something that's outside policy. For a knowledge management agent, it's probably the instruction governing what to do when the relevant SOP doesn't exist or is outdated.
Answer the three questions for that one instruction:
- What should it not do, even if doing it would solve the customer's problem?
- When should it stop and ask rather than proceeding?
- If the customer's need and the company's policy conflict, which wins?
Write the answers down. Write them precisely enough that someone reading them six months from now would make the same decisions you would make today. That is your first intent contract.
From there, expand incrementally. Add the cascade of specificity for the primary goal. Add the value hierarchy. Add the capability map for the domain. Each addition improves the precision of the agent's decision-making and reduces the probability of Klarna-style drift.
The discipline builds with practice. The first cascade feels laborious — five questions per goal is a lot of work. The second cascade is faster. By the fifth, the questions have become a habit of thought: what's the signal, where's the data, what actions are authorized, what trade-offs are acceptable, what lines can never be crossed? Teams that internalize these questions write better requirements, have cleaner product reviews, and make better build decisions — because the questions discipline organizational thinking, not just agent behavior.
Two Layers of Intent
Intent operates at two layers — Nate Jones's framing, which I've borrowed and built on. Both are necessary. The first without the second is philosophy. The second without the first is arbitrary.
Layer 1: Organizational Intent. What does the company need AI to want? This isn't a mission statement — it's machine-actionable infrastructure. Goals with explicit trade-offs. Capabilities mapped to constraints. Decision boundaries that don't require interpretation.
OKRs work for humans because humans absorb organizational context through osmosis — meetings, hallway conversations, cultural norms, the way the CEO reacts to certain proposals. Agents don't absorb culture. They need it made explicit. A goal that a human employee would interpret correctly from context — "improve customer satisfaction" — will be implemented differently by an agent depending on how its training data weighted different dimensions of satisfaction. Without explicit organizational intent, the agent's interpretation is the internet's average opinion, not your organization's specific judgment.
Layer 2: Agent Instruction Intent. For each agent instruction, what should the agent prioritize, what is it prohibited from doing, and when should it stop and ask? This layer closes the gap between what you say and what you mean — between the literal instruction and the professional judgment a human employee would apply when following that instruction.
An agent told to "deploy this code to production" might, if deployment fails, attempt workarounds you didn't authorize. An agent told to "deploy this code to production — this is important but not urgent enough to justify skipping tests; if deployment fails, roll back and notify the team rather than attempting workarounds" has the Layer 2 intent it needs to handle the failure case correctly.
Both layers are required. Organizational intent without agent instruction intent means the agent knows what to optimize for but takes dangerous shortcuts to get there. Agent instruction intent without organizational intent means the agent behaves safely but optimizes for the wrong thing — the Klarna trap.
How Specs and Intent Contracts Work Together
A fair question I get every time I walk a team through this: if the spec describes what the system should do, why does an intent contract need to describe why? Aren't they redundant?
Not redundant — complementary. They cover different types of gaps.
The spec covers the anticipated situations — the behaviors the team knew needed specifying. It answers: given input X, what should the system do? Given condition Y, what's the right response? Given conflict Z, which behavior takes priority?
The intent contract covers the unanticipated situations — the gaps between specified behaviors. An agent operating outside the spec's explicit coverage makes decisions. Those decisions will be based on something: the model's training data, the statistical patterns in the system prompt, the context it's been given. Without an intent contract, those decisions default to whatever the model's priors suggest is most helpful. With an intent contract, those decisions are guided by the organization's actual goals and constraints.
The Klarna agent had a spec. It specified resolution workflows, escalation paths, refund procedures. The spec was not wrong. What was missing was the intent contract: "When following this spec produces an outcome that a thoughtful Klarna employee would be uncomfortable with, stop and escalate." That instruction doesn't specify a behavior — it specifies a judgment criterion. It tells the agent how to reason about gaps in its explicit instructions.
The spec and intent contract are both necessary. A system with a complete spec but no intent contract will handle specified situations well and unspecified situations arbitrarily. A system with a detailed intent contract but an incomplete spec will have good judgment and incomplete coverage. The combination — precise specification of anticipated behaviors plus explicit intent for the gaps — is what produces reliable behavior across the full distribution of real-world inputs.
Building Organizational Intent: The Cascade of Specificity
The Cascade of Specificity (another Nate Jones construct) is the method for converting organizational goals from aspirational language to machine-actionable parameters. Every goal gets five increasingly precise questions.
Aspiration: "Improve customer satisfaction."
This is the goal as organizations typically state it. It is useless for an agent. "Satisfaction" is not actionable. "Improve" is not measurable. An agent given this goal will choose its own definition of satisfaction and its own measure of improvement, based on whatever its training data emphasized.
Signal: What metric, specifically? "Net Promoter Score > 45 in post-interaction survey."
Now the goal has a measurement. The agent knows what it's optimizing for — a specific survey score, not an abstract concept. It knows what data to look at and what direction constitutes success.
Data source: Where does the measurement live? "Zendesk CSAT scores, captured in the follow-up survey sent 24 hours after ticket close."
The agent now knows the data infrastructure. It can reason about whether its actions will affect this specific measure. It can't hallucinate alternative metrics or alternative sources.
Authorized actions: What is the agent explicitly permitted to do? "Offer refunds up to $50 autonomously. Escalate above $50 to human review. Apply discount codes from the approved list. Process returns per the policy in the knowledge base."
This is the capability map for this specific goal. The agent knows what it can do without asking. Everything not on this list requires escalation or is prohibited.
Trade-offs and hard boundaries: "Spend up to 10 minutes per ticket — quality over speed. Never promise delivery dates that can't be verified in the inventory system. Never offer a refund on an item older than 90 days without manager approval."
The trade-offs resolve conflicts the agent will encounter: what to do when serving the customer quickly conflicts with serving them correctly. The hard boundaries establish what the agent can never do regardless of any other instruction.
The full cascade for Klarna's customer service agent would have looked something like: Signal: customer retention rate, not ticket resolution rate. Data source: 90-day repurchase rate and NPS. Authorized actions: offer retention discount up to $20 for customers flagged as high-value. Trade-off: spend up to 15 minutes per ticket if the customer account shows high lifetime value. Hard boundary: never close a ticket the customer hasn't confirmed as resolved.
The cascade would have caught the failure before deployment. The tension between resolution speed and retention was visible the moment the cascade asked "what trade-offs are acceptable?" Speed-for-its-own-sake, applied to a high-LTV customer base, is a trade-off that any business leader would have rejected. The cascade makes the trade-off explicit, which makes the rejection possible.
The Three Critical Questions for Agent Instructions
Every complex agent instruction must answer three questions before it is complete.
Question 1: What should the agent NOT do, even if doing it would accomplish the goal?
This is the prohibited shortcuts question. Agents pursuing a goal will find the shortest path to accomplishing it. The shortest path often includes actions that are technically legal, are within the agent's capability, and would achieve the stated goal — but that no reasonable person intended to authorize.
An agent told to "schedule a customer follow-up" might, if the customer's email is unavailable, search the web for their contact information. Technically achieves the goal. Not what was intended. The prohibited shortcuts for this instruction: "Only use contact information available in the CRM. Do not search for external contact information. If contact information is unavailable, escalate rather than sourcing alternatives."
For a code deployment agent: "Do not acquire credentials beyond what is available to you. Do not modify production infrastructure configuration. Do not skip any test suite, even if you believe the change is trivial." Each prohibition closes a shortcut the agent might take in pursuit of "deploy this code to production."
Question 2: Under what circumstances should the agent stop and ask?
This is the escalation threshold. Agents by default will work through ambiguity — they'll make a decision and continue. The escalation threshold defines when ambiguity is serious enough that the decision shouldn't be made autonomously.
For a content publishing agent: "Stop and ask if the content references legal matters, regulatory requirements, or competitor products. Stop and ask if the content score for any quality dimension is below threshold. Stop and ask if the content was produced for a client in a restricted category." Each threshold defines a class of situations where autonomous action is not authorized.
The escalation question is also the failure gracefully question. An agent that knows when to stop produces a clean handoff to the human. An agent that doesn't know when to stop produces a decision that may have been wrong, followed by a trail of downstream actions that depend on that decision.
Question 3: If the goal and the constraints conflict, which one wins?
This is the value hierarchy. Without an explicit answer, the agent defaults to goal optimization — the constraint loses by default. This is the structural problem that produces Klarna-style failures: the agent optimizes for the primary goal, trading off constraints as they become inconvenient.
The value hierarchy makes the priority order explicit:
PRIORITY ORDER (highest → lowest):
1. Hard boundaries (NEVER cross these)
2. Safety constraints (escalate before violating)
3. Quality standards (meet these before optimizing speed)
4. Primary goal (accomplish within the above)
5. Efficiency (optimize only after 1-4 are satisfied)
An agent given this hierarchy knows what to do when "accomplish the goal quickly" conflicts with "don't skip the quality review." The quality review is Priority 3. Speed is Priority 5. Priority 3 wins. The agent doesn't need to decide. The hierarchy decides.
Without the hierarchy, the agent decides — and it will decide in ways that reveal the training data's preferences, not the organization's.
A Worked Example: Edifica
Edifica — the building management system for Colombian residential properties — has a governance intent contract that encodes a specific organizational trade-off.
The conflict: Resident privacy versus administrative transparency. A resident wants their personal information (contact details, payment history) kept private. The building administrator needs that information to comply with Ley 675 reporting requirements and to communicate about assemblies, budgets, and maintenance.
Without an intent contract: The agent decides. Maybe it favors privacy (because privacy is generally considered important). Maybe it favors transparency (because the administrator is the primary user). The decision is inconsistent, unpredictable, and based on whatever the model's training data suggests is the "right" answer. Different sessions produce different outcomes for the same conflict. Residents and administrators receive contradictory behavior from the same system.
With an intent contract: "When resident privacy conflicts with administrative transparency, transparency wins — the building's legal obligations under Ley 675 take precedence over individual preferences. The system provides transparency by default, with resident opt-out available only for information not required by law. Information required for assembly notifications, financial reporting, and maintenance coordination is always provided to the authorized administrator."
Every ambiguous governance decision in Edifica resolves the same way. Not because the model figured it out — because the intent contract told it how. The contract encodes organizational and legal judgment that the model doesn't have and shouldn't be asked to simulate.
The Edifica intent contract also includes the Cascade of Specificity for each core module:
For the assembly notification module: Signal: timely and legally valid notification of all eligible owners. Data source: resident registry with coeficiente calculations. Authorized actions: send notifications, generate convocatoria documents, calculate quorum thresholds. Trade-off: legal validity over communication speed — a delayed but valid notification beats a timely but invalid one. Hard boundary: never send a convocatoria that doesn't meet the minimum advance notice requirement under Ley 675.
These aren't prompts. They're engineering artifacts — designed, reviewed, and version-controlled alongside the spec. When Colombian law changes, the intent contract is updated before the code is updated. The intent drives the implementation, not the reverse.
Why Intent Engineering Is Needed Now
I realized this watching my own workflow shift. Early AI interactions were session-based. A human was standing right there, providing intent through the conversation itself. "No, I meant the other thing." "Focus on cost, not speed." "That's too aggressive — tone it down." The intent was implicit in the back-and-forth.
Long-running agents don't have that. They run autonomously for hours, days, or weeks. They make decisions without a human in the loop. They encounter ambiguities the spec doesn't cover. Without encoded intent, they resolve those ambiguities based on their training data — which encodes the internet's average opinion, not your organization's specific judgment.
The autonomous agent is the forcing function. When the human is always present, implicit intent is sufficient. When the agent operates independently, implicit intent is a liability. The decisions the human would have made in real time — "in this case, prioritize speed" or "here, quality matters more than efficiency" — must be made in advance and encoded explicitly.
Intent drift is the ongoing failure mode. An intent contract written at project start may no longer reflect organizational reality six months later. The company's priorities shift. The customer base changes. A regulatory update changes what's legally required. An incident reveals a trade-off that the original contract got wrong. Intent contracts must be living documents — versioned, reviewed, and updated when the organizational context they encode changes.
The practical infrastructure for intent maintenance: quarterly reviews of each intent contract, triggered automatically by the maintenance flywheel. The review asks: has anything in the organizational context changed that would affect the trade-offs encoded here? Has the system produced any decisions that surprised stakeholders — suggesting the encoded intent doesn't match the actual intent? The review is brief if nothing has changed. It's substantive when something has.
What Intent Contracts Look Like in Practice
An intent contract is not a long document. It's a precise one.
A useful intent contract for a single agent in a single domain is typically two to four pages. It contains: the organizational context (one paragraph — why this agent exists and what organizational goal it serves), the capability map (which workflows are agent-ready, agent-augmented, or human-only for this domain), the cascade of specificity for each major goal, the value hierarchy, and the three critical questions answered for each class of agent instruction.
What it doesn't contain: implementation details, technical specifications, or anything that would need to change when the code changes. Intent contracts should be stable over longer timeframes than specs. The spec changes when the behavior changes. The intent contract changes when the organization's goals or constraints change.
A minimal intent contract for the VZYN Labs pre-audit skill:
## VZYN Labs Pre-Audit — Intent Contract
**Organizational context**: The pre-audit playbook is a lead generation tool.
Its purpose is to demonstrate value to prospective agency clients by producing
a market intelligence report that reveals the gap between their current position
and their competitive opportunity. It is not the product — it is the demonstration
that a more thorough product exists.
**Capability map**:
- Agent-ready: market research, competitor data collection, keyword extraction,
technical audit, performance benchmarking
- Agent-augmented: competitive analysis narrative (agent drafts, human reviews),
recommendations (agent proposes, human approves before client delivery)
- Human-only: client relationship decisions, pricing conversations, scope changes
**Goal**: Produce a report that accurately represents the agency's competitive
position and reveals a genuine opportunity the agency can act on.
**Cascade**:
- Signal: client requests a follow-up meeting after receiving the pre-audit
- Trade-off: accuracy over flattery — the report must reflect real gaps, not
manufactured ones. A report that flatters the prospect to get a follow-up
meeting damages trust when the client does due diligence.
- Hard boundary: never inflate scores to make the gap appear larger than it is.
Never cite sources that weren't accessed. Never recommend products or services
that don't address the actual gaps found.
**Value hierarchy**:
1. Accuracy (the report must be factually correct)
2. Relevance (the findings must matter to this client's situation)
3. Clarity (the report must be understandable to a non-technical client)
4. Completeness (all sections are present and substantive)
5. Speed (the report is delivered on schedule)
**Escalation**: Stop and ask if the client's website is unavailable for audit,
if the market data returns no meaningful competitors, or if any section of the
report would require fabricating data to complete.
This contract is specific enough to guide agent behavior without requiring interpretation. The value hierarchy resolves conflicts: if completing the report on schedule (Priority 5) would require fabricating data (prohibited), the agent stops. The cascade specifies that a "successful" pre-audit is one that produces a follow-up meeting — not just a completed report.
The contract is also specific to this skill and this context. A different skill in the same project has a different contract. The organizational context section explains why the skill exists; the rest explains how it should behave while serving that purpose.
The Two Cultures Gap
Intent engineering requires bridging a cultural gap that most organizations don't acknowledge exists.
On one side are the technologists — engineers, architects, data scientists. They speak the language of context, infrastructure, and capability. They understand what AI can do. They build the systems that give agents access to organizational knowledge.
On the other side are the executives and domain experts. They speak the language of goals, trade-offs, and organizational judgment. They understand what the organization needs. They carry the institutional knowledge that should govern what the agents do with their capability.
Intent engineering requires both. Context without intent is capability without direction. Intent without context is direction without capability. The organizations that get this right create a role — sometimes called an AI Workflow Architect — that bridges the two cultures. The bridge-builder understands enough technology to know what's possible, and enough organizational strategy to know what should be done with it.
The bridge-builder's job is to translate in both directions: organizational goals into machine-actionable parameters (the cascade of specificity), and agent capabilities into organizational language (the capability map). Without this translation, the technologists build systems that are technically excellent and organizationally irrelevant, and the executives make decisions about AI strategy that are strategically sound and technically impossible.
Intent engineering is not a technical discipline. It's an organizational discipline with technical implications. The people who write intent contracts don't need to understand transformer architectures. They need to understand the organization well enough to make its trade-offs explicit, and understand AI systems well enough to make those trade-offs machine-readable.
Exploration Before Specification
There's a design principle that acts as a counterweight to intent engineering's precision: not every problem should compress into a prompt.
The instinct, once you learn to write specifications and intent contracts, is to specify everything. Define every behavior. Encode every trade-off. Resolve every ambiguity upfront. This works for known problems with known solutions. It fails for problems you don't yet understand.
Exploration discovers intent. Before you can encode what the organization wants, you need to understand what it needs — and sometimes the organization doesn't know yet. A call center that says "we want faster resolution" might actually need "we want fewer escalations." A building administrator who says "we need better communication" might actually need "we need legal compliance automation."
The diagnostic for premature specification is simple: if you find yourself writing an intent contract that contradicts itself, or that produces outcomes the stakeholders react to with "that's not what I meant," the specification came before sufficient exploration. The intent contract wasn't wrong — the understanding was incomplete.
Exploration takes different forms. Observation: watching how people actually use the existing system, not how they describe using it. Interview: asking "what do you do when that happens?" rather than "what should happen?" Prototype: building a rough version and watching what surprises people. Each method discovers intent that can't be specified in advance because the people closest to the work don't know how to articulate it until they see it violated.
The spec architect's job includes knowing when to explore before specifying — when to ask more questions, observe more workflows, and sit with ambiguity before encoding it. Premature specification is as dangerous as absent specification. Both produce systems that optimize for the wrong thing. The difference is that premature specification has the appearance of rigor, which makes it harder to diagnose when it's wrong.
Intent Drift and How to Catch It
Intent contracts become stale. Organizational priorities shift. Customer bases change. Regulations update. Incidents reveal trade-offs the original contract got wrong. A contract that accurately encoded organizational intent at launch may be substantially wrong eighteen months later — and if nobody catches the drift, the agents operating on the stale contract will optimize for what the organization used to want, not what it wants now.
Intent drift is harder to detect than spec drift. Spec drift has a visible symptom: the system does something that doesn't match the spec. Intent drift has an invisible symptom: the system does exactly what the spec says, but the spec no longer reflects what the organization needs.
The VZYN Labs case study illustrates this without involving explicit intent contracts — which makes it even more instructive. The original architecture reflected an organizational intent: deliver maximum specialization per marketing domain. Thirteen agents, each expert in one function. By the time the intent was re-examined (after the architect review that revealed the system was unmaintainable), the organizational need had changed: deliver reliable marketing automation at scale. The specialization-first intent was stale. The rebuild reflected the updated intent. But nobody had captured the original intent formally, so the drift was invisible until the consequences became obvious.
Formal intent contracts make drift visible because they make intent explicit. You can compare the current organizational priorities to the contract and ask: is this still right?
The maintenance flywheel includes an intent review trigger: any time three or more consecutive human reviews identify a pattern where "the output did what the spec said but not what we actually wanted," an intent review is triggered. The pattern is the signal that the system is operating on stale organizational intent. The review updates the cascade of specificity, the value hierarchy, and the escalation thresholds before the drift compounds.
Scheduled intent reviews run quarterly for Tier 3 and Tier 4 systems, semi-annually for Tier 2. The review asks a simple question to the people who own the organizational goal: "Is this still what you're optimizing for?" If the answer is yes, the contract is confirmed current. If the answer is "actually, we've been thinking that..." the cascade needs to be updated.
The Intent Race
The intelligence of AI models is converging. The same capability that one major lab has today, another will have in months. Differentiation through model capability is a temporary advantage, quickly eroded.
The differentiation that compounds is organizational intent infrastructure. A company that has spent two years encoding its institutional knowledge — the trade-offs, the decision boundaries, the value hierarchies — into intent contracts isn't easily replicated. That stack encodes judgment that took decades to accumulate. Not instructions — a moat built out of crystallized expertise.
This is the intent race: not the competition to deploy AI first, but the competition to encode organizational wisdom most completely. The company whose agents are most precisely aligned with its actual goals — not just its stated goals — gains compound advantage as the agents become more capable. A highly capable agent operating on precise organizational intent is qualitatively different from a highly capable agent operating on vague prompts.
The practical implication: treat intent contracts as organizational assets, not as developer notes. Version-control them. Review them quarterly. Invest in the Cascade of Specificity for every goal that matters. Build the intent infrastructure before the model subscription matters — because the model subscription depreciates and the intent infrastructure appreciates.
Next chapter: why Rob Pike's rules for programming apply with double force to agent systems — and why simplicity is the layer most teams skip on their way to shipping.
Footnotes
-
Klarna, "Klarna AI assistant handles two-thirds of customer service chats in its first month" (press release, February 27, 2024). Available at klarna.com/us/press/. The customer satisfaction and retention concerns emerged in subsequent analysis and press coverage. [VERIFY — confirm the specific retention/relationship-damage details against published sources] ↩