Intent Engineering for Regulated AI: What Klarna's Sixty Million Dollars Tells Mid-Market Healthcare Buyers

The Klarna lesson, read for healthcare Klarna's customer-service agent is the most-cited AI deployment in enterprise circles right now. The numbers are real. Two and a third million conversations in the first month. Twenty-three markets, thirty-five languages. Resolution times collapsed from eleven minutes to two. Sixty million dollars of cost taken out, by the CEO's own count, in less than two years. The agent does the work of, depending on which projection you read, 700 to 853 full-time employees. The agent is also the cleanest example we have of how to break a company with a working AI deployment. The customers complained, generic answers, robotic tone, no judgment. Mid-2025 the CEO told Bloomberg that cost had been "a too predominant evaluation factor" and that the result was "lower quality." Klarna started recruiting human agents back in. The agent still handles two thirds of inquiries; satisfaction on simple queries is comparable. But the blended outcome, the relationships that drive lifetime value, was meaningfully damaged in the period when the agent was the dominant interface. The veteran agents who had absorbed the unwritten rules, when to escalate, when to deviate from the script, when to absorb a small loss to preserve a larger relationship, had no successor in the system. The agent had a prompt and a context. It did not have intent. For a regulated mid-market healthcare buyer the temptation is to read this as a customer-experience story and move on. That is the wrong read. The same structural failure mode, a clear objective optimized to its measurable interpretation, while the unmeasured constraints that actually mattered were destroyed in the process, is sitting in every healthcare AI deployment that defines its objective as "answer the patient's question fast" or "draft the documentation in under thirty seconds" or "close the open billing query." Those objectives are not wrong. They are incomplete. The audit-relevant constraints, minimum-necessary access, clinical safety, escalation discipline, scope boundaries, the line where the agent stops, are the ones the prompt did not name. The agent will optimize for what was named. This is the regulated-buyer translation of what Nate has called intent engineering. It is the discipline that makes the implicit constraints explicit, machine-readable, and enforceable in a sustained agent loop. It is also, for a regulated buyer, the discipline HIPAA has been quietly asking for since the Security Rule was written. The three engineering eras, in order The history is short and worth naming. Prompt engineering, what to tell the AI to do in a single session, was the dominant skill from 2022 through 2024. Context engineering, what the AI needs to know, with what scope, with what provenance, with what freshness, became the named discipline through 2025; Anthropic's foundational piece on the topic landed in September 2025, and by the end of the year the term was the consensus name for what the field was building. Intent engineering is the third. Where context says what the agent knows, intent says what the organization needs it to want, what to escalate, what to refuse, what to value when goals collide. Almost nobody is building for it yet. The MIT-cited statistic that ninety-five percent of generative AI pilots fail to deliver measurable impact, the S&P Global number that forty-two percent of companies abandoned most AI initiatives in 2025, the Gartner projection that forty percent of agentic AI projects will be cancelled by 2027, these are not, primarily, technology failures. They are intent failures. Context without intent is a loaded weapon with no target. For a regulated buyer the eras compress differently. The compliance posture that holds in 2027 cannot rest on prompt-level instructions, because instructions do not hold under autonomy (a point the Trust Architecture Field Guide covers in detail). It cannot rest on context-level scoping alone, because the agent will still optimize for what is named in the goal. It rests on the third layer, explicit, machine-readable organizational intent that the orchestration layer can enforce. What intent engineering actually is, in three artifacts We work with regulated mid-market clients to produce three artifacts during the Adopt-AI-Safely Diagnostic that, together, are the buyer's intent-engineering posture. Each artifact is short. Each is enforceable at the orchestration layer rather than in a system prompt. One: the constraint set. The list of things the agent is not allowed to do, even if doing them would accomplish the assigned goal. For a regulated healthcare deployment the constraint set typically names: do not retrieve PHI beyond the minimum necessary for the workflow; do not act on inferred clinical context that was not explicitly authorized; do not generate output that could be construed as clinical advice without an escalation; do not write to the EHR without a structured approval; do not call any tool that is not in the workflow's scoped tool surface. Each constraint is enforced at the orchestration layer, by the tool registry, the permission gate, the access-control surface, rather than by the model's good behavior. Two: the escalation policy. The list of conditions under which the agent stops and escalates rather than proceeding. For regulated workloads the policy names: any request that requires data outside the agent's scoped access; any clinical decision that the agent cannot ground in the authorized retrieval set; any goal-vs-constraint conflict where the constraint set wins; any tool-call failure on a destructive tool; any signal of an off-manifold edge case (an unusual patient population, an unfamiliar clinical pattern, a billing scenario the agent has not seen before). Escalation produces a structured log entry, the policy is the audit-relevant artifact when something goes right under pressure. Three: the value hierarchy. The list of which constraint wins when the goal and a constraint conflict, ordered. For a regulated buyer the hierarchy is opinionated and short. Patient safety wins. Minimum-necessary wins. Audit-trail integrity wins. Workflow throughput is below all three. The CIO who states the hierarchy in advance, and ties it to specific orchestration-layer enforcement, has done the most consequential intent-engineering work of the deployment. The three artifacts are short. Together they are typically two pages. They are also the artifacts a regulator's first questions in 2027 will surface. What did you tell the agent it could not do? What did you tell it to escalate? Which value won when they conflicted, and how was it enforced? The buyer's answers, names, lists, enforcement points, audit-log surfaces, are the answers that hold. How HIPAA already encodes a version of this The discipline is new in name. The principle has been in the Security Rule for nearly thirty years. Minimum-necessary (§164.502(b)) is a constraint in exactly the form intent engineering names: a structural rule that limits what the workforce can access, regardless of what would be efficient or what the user wants. Workforce sanctions (§164.308(a)(1)(ii)(C)) presume some workforce members will exceed scope and require structural enforcement. Access-establishment, modification, and termination (§164.308(a)(4)) are the workforce-level analog of the agent identity and permission scope. Even the Privacy Rule's notion of authorization-versus-consent encodes a value hierarchy: when the patient's authorization and the requester's request conflict, authorization wins. What changes for AI is that the actor is faster than human-speed audit, has no reputational consequence to consider, and will optimize for the named goal. The structural answer is to make the constraints, the escalations, and the hierarchy explicit and orchestration-enforced. The audit will accept a short, written, enforced posture. It will not accept "we trained the team well." What we recommend A regulated mid-market healthcare buyer about to ship an AI agent into a PHI workflow should produce the three intent-engineering artifacts before the agent reaches production. The buyers who do this report two effects. First, the architecture review converges faster, the implementation team has explicit constraints to design against, rather than a vague "use good judgment" hand-wave. Second, the audit posture becomes legible, the CIO can hand the regulator a two-page document that names what the agent can do, what it cannot, what it escalates, and which value wins on conflict. The Klarna lesson is that an agent will optimize for what is named. The regulated-buyer lesson is that the named objective in a HIPAA-defensible deployment has to include the unmeasured constraints, minimum-necessary, audit-trail integrity, escalation discipline, value hierarchy, that the workforce already knows in their bones. Make those constraints explicit and enforceable, or accept that the agent will optimize them away. If you find yourself writing "use good judgment" anywhere in a regulated agent's instruction set, that is the diagnosis. The audit will not accept "use good judgment" as evidence of a control. Replace it with the three artifacts.