Intent Engineering and the Klarna Lesson

Everything this series has built so far — the context pillars, the smart-zone budget, the short map and enforced gates of part 10 — makes an agent better at executing. None of it says a word about whether the execution is aimed at the right thing. That gap is a discipline of its own, and it is the one I see skipped most often, because it does not look like engineering. Context engineering tells agents what to know. Harness engineering tells them how to work here. Intent engineering tells them what to want — and an agent with perfect knowledge, a flawless harness and the wrong wants will hurt you at exactly the speed the rest of the stack made possible.

The discipline that does not look like engineering

Intent engineering is the practice of encoding organisational purpose into the systems an agent operates under: the goals, the values behind the goals, and — most practically — the trade-off hierarchies. Every organisation carries hundreds of implicit rankings that humans absorb by osmosis. Speed versus thoroughness. Cost versus experience. Consistency versus judgement in the awkward customer situation. A human employee learns where their employer actually stands on each of these within a few months, mostly by watching what gets praised and what gets quietly redone. An agent learns none of it unless someone writes it down.

The working artefact I build for this is a delegation framework: organisational decision boundaries translated into parameters an agent can actually follow. When speed conflicts with quality, here is the threshold at which quality wins. When a customer interaction goes outside these bounds, hand off to a human rather than resolving it. When two valid implementations differ in cost, prefer the cheaper one unless it touches this list of experience-critical paths. These are not rules in the harness sense — they are encoded judgement, the answers to “what would the organisation want here?” written down before the agent has to guess.

The instinct to skip this step usually rests on an unspoken assumption: that the metrics we gave the system already express what we want. The most instructive public counterexample is Klarna, and it deserves to be told with its numbers exactly right — because the story is routinely told wrong, and the wrong version teaches the wrong lesson.

What Klarna actually claimed

In February 2024, Klarna announced that its OpenAI-powered assistant had, in its first month, handled 2.3 million conversations — two-thirds of the company's customer-service chats. Resolution time fell from eleven minutes to under two. The company said the assistant was doing the equivalent work of 700 full-time agents — a work-equivalence figure, note, not a count of people dismissed — and estimated a 40 million US dollar profit improvement for 2024. And, crucially for this story, the same release claimed customer-satisfaction scores on par with human agents.

Read as an engineering result, it is genuinely impressive, and nothing that happened later erases that. The system worked. It did what it was measured on, at scale, immediately. On every number in the announcement — volume, speed, cost — the deployment was a success.

Keep that last sentence in mind, because the popular retelling of what came next usually inserts a fact that does not exist. You will hear that customer satisfaction collapsed. There is no published figure showing that; Klarna's own release had claimed satisfaction parity. The documented evidence of what went wrong is both quieter and, for this discipline, far more interesting: it is what the company itself said fifteen months later.

Fifteen months later

In May 2025, Klarna reversed course. CEO Sebastian Siemiatkowski told Bloomberg — reported by Forbes among others — that the cost-cutting push had “gone too far” and had produced “lower quality”. Klarna began recruiting human customer-service agents again, with the stated goal that a customer should always be able to reach a person.

Sit with what that reversal implies. The AI had not stopped working. The metrics had not turned red — by the measures the system optimised, it was presumably still resolving conversations in under two minutes at a fraction of the old cost. What changed is that the company looked at the outcome those metrics had purchased and concluded it was not what the business actually valued. “Always able to reach a person” is a statement about relationship quality, and relationship quality had never been in the objective. The system optimised exactly what it was given, and what it was given was not what the organisation meant.

That is the precise shape of an intent failure, and it is worth distinguishing from its neighbours. It was not a model failure — the model performed. It was not a context failure — the assistant clearly had the information to resolve chats. It was not a harness failure — the infrastructure ran 2.3 million conversations in a month. The failure sat in the layer nobody had engineered: the translation from “what Klarna exists to do for its customers” into “what this system is optimising for”. Speed and cost went in; the value that made customers stay was assumed rather than encoded.

Intent drift

There is a second, subtler lesson inside the first, and it is the one that applies even to teams who get the initial encoding right. Suppose Klarna's 2024 objectives were a fair snapshot of the company's priorities at launch — a cost-focused fintech in a cost-focused year. The 2025 reversal then reads as something else: the organisation's priorities moved, and the system's did not. I call this intent drift. An agent aligned with organisational intent at deployment time becomes misaligned as strategy, market position or values shift underneath it — it keeps faithfully optimising last quarter's objectives while the business has moved on.

Intent drift is nastier than a bad initial encoding because nothing fails. Dashboards stay green; the drift shows up as a growing, unmeasured gap between what the system delivers and what the organisation now needs — and the better your harness, the longer the system can run unattended, the wider that gap grows before anyone looks.

Three countermeasures

Three mechanisms, built into how I run agent systems, keep intent from drifting silently.

Periodic intent review. Quarterly, reread the goals, trade-off hierarchies and decision boundaries encoded in the agent infrastructure and ask one question of each: does this still reflect what we would decide today? This is deliberately not a technology review — no benchmarks, no model versions. It is an intent review, and the people in the room should be the ones who own the business outcome, not the ones who own the pipeline.

Competency recalibration. When strategic emphasis shifts, the skills you invest in must shift with it. A team whose agents move from internal tooling into customer-facing territory needs to get deliberately better at exactly this discipline — encoding values and escalation boundaries — even if their context and harness practice is already excellent. Capability allocated against last year's strategy is its own form of drift.

Outcome-to-specification feedback loops. Connect the business outcomes an agent system produces — satisfaction, revenue, defect rates, complaints — back to the specifications and intent frameworks that produced them. When outcomes diverge from expectations, trace the divergence to its layer: was the specification wrong, the context incomplete, the intent misencoded? The lazy default is to blame the model, and the model is the one component you cannot fix. Klarna's reversal is this loop executed manually, at company scale, fifteen months late — the entire discipline is about running it continuously instead.

The three share a premise: intent is not a launch artefact, it is a living document with an owner and a review cadence. Write it down once and it will be wrong within a year, through no fault of the writing.

Encoding what the organisation wants is still not the whole story, though. An agent that wants the right things also needs to know, concretely and verifiably, what done looks like for the piece of work in front of it — and that is a written artefact with a discipline of its own. Next, the highest-leverage layer of the stack: specification engineering and the 80% problem.