Six articles in, the model has a name. This is it.
The series so far has worked by elimination.
The first article named the shift. From managing work to governing intent. The second retired the methodology that grew up around the old constraint. The third retired the century-old paradigm beneath it. The fourth and fifth dismantled work as the unit of professional value and replaced it with three practitioner capabilities: define, translate, judge. The sixth named the executive accountability the work demands.
What none of them have done yet is put the model on paper.
The Human Intent Stack is what the previous six articles have been circling. It is not a methodology, not a maturity model, not a transformation framework. It is a way of seeing how intent moves through an organisation between human purpose and machine action, and a vocabulary for what has to be true at each layer for that movement to remain faithful.
It is also the artefact other people will need to point at when they explain this work. So here it is.
What the Stack is for
Most organisational models answer the question how do we get the work done?
The Stack answers a different question, which has only recently become the harder one: how do we make sure the work being done still reflects what we meant?
For most of the last century that question barely existed, because execution was so slow and so expensive that the meaning had time to catch up. Strategy could be vague. Specifications could be partial. The translation from purpose to action happened inside human heads, refined through hundreds of micro-decisions by people who shared context the documents never carried. Drift happened, but at human speed. There was time to correct.
Agentic execution collapses that timeline. When the work happens in minutes rather than weeks, the meaning has to arrive complete. Whatever ambiguity was in the intent at the start is now in the output at the end, only multiplied across every system that acted on it. The same property that makes the new execution layer valuable, speed, autonomy, scale, makes intent quality the only thing standing between the organisation and confidently shipping the wrong thing.
The Stack exists because intent degrades as it moves, and the new execution speed gives that degradation nowhere to hide.
The layers
Six layers, top to bottom. Each is a translation of the one above it.
Human Purpose. What the organisation exists for. The values, the ethical commitments, the kind of future it is trying to create, the things it would refuse to do even if profitable. This is the layer that does not change when strategy changes, and the layer that AI cannot generate. Good looks like a small number of commitments the organisation can be held to and would defend under pressure. Failure looks like purpose written for the website rather than for use, sentences nobody quotes when a hard decision lands on the table.
Strategic Intent. The outcomes the organisation is currently pursuing in service of that purpose. Priorities. Constraints. The trade-offs it is willing to make and the ones it is not. This is the layer where boards and executive teams operate. Good looks like strategy that names what the organisation will not do as clearly as what it will. Failure looks like strategy that reads as ambition without trade-off; every option still open, every priority still equal, every team free to choose its own interpretation.
Domain Intent. The rules, language, standards, patterns, and expectations that apply within a specific business or technical area. The accumulated judgement of a function; clinical safety in healthcare, suitability in financial advice, accessibility across digital services. This is the layer that allows projects not to rediscover what the organisation already knows. Good looks like domain intent that delivery teams can inherit without negotiation, standards written to be used, not to be cited. Failure looks like policy libraries nobody reads and standards that exist only to be pointed at after something has gone wrong.
Project or Product Intent. The specific goal being pursued. The user need, the problem, the outcome, the change. The local trade-offs and the definition of success for this particular piece of work. This is the layer most delivery organisations recognise, because it is the only layer they have historically governed well. Good looks like intent that names the user, the problem, the outcome, and the trade-offs the team has been authorised to make. Failure looks like a backlog full of inherited assumptions and a definition of success that nobody can recall the reasoning behind.
Execution Intent. The structured artefacts that humans and systems act on. Specifications. Acceptance criteria. Architecture decisions. Prompts. Policies as code. Tests. This is the layer where intent finally becomes precise enough to be executed, and the layer where most intent leaks happen because the discipline of writing it well has not yet caught up with the speed of the execution beneath it. Good looks like artefacts written with the knowledge that an agent will read them literally and a human will be held responsible for the result. Failure looks like prompts written in a hurry, specifications that assume context the executor does not have, and acceptance criteria that test the easy parts of intent and ignore the hard ones.
Machine Execution. The actual work performed. Code written. Models invoked. Agents acting. Workflows running. Humans completing the bits that remain human. This is the layer the previous century was built to optimise. Good looks like execution that is observable, attributable, and faithful to the intent that authorised it. Failure looks like activity without traceability; work produced at speed with no clear answer to why was this done, on whose authority, against what intent?
The order is not a hierarchy of importance. It is a hierarchy of translation. Each layer takes something broad and makes it more actionable, and each translation step is a place where meaning can be lost.
Purpose becomes strategy without values. Strategy becomes targets without context. Domain intent becomes standards theatre. Project intent becomes tickets. Execution intent becomes prompts written in a hurry. Machine execution becomes activity with no traceable connection to the purpose that started the chain.
That is the failure mode the Stack is designed to make visible.
Where the Intent Hierarchy lives
Readers of the Intent-Driven Development series will recognise the middle of the Stack. Organisation, domain, project, the three-level Intent Hierarchy, sits inside the Stack as its operational core. The IDD work was the proving ground. We learned there that intent could be defined once, inherited downward, and promoted upward as patterns matured. That structure survives untouched. The Stack simply extends it in both directions: upward to the purpose that strategic intent serves, downward to the execution intent and machine execution that project intent eventually becomes.
The Hierarchy is where most organisational intent work actually happens. The layers above and below are where the Stack connects to the rest of the enterprise – to purpose at the top, to systems at the bottom. Without the Hierarchy in the middle, the Stack would be an abstraction. Without the Stack around it, the Hierarchy would have no obvious connection to either the boardroom or the runtime.
The two models are not competing. The Hierarchy is the operational engine. The Stack is the full anatomy.
World context: the external test
There is a question every layer of the Stack has to answer that the layers themselves cannot tell you.
Is the world ready for the intent this layer is about to act on?
The Stack as drawn so far is internally complete. It describes how intent moves from purpose to execution inside an organisation. What it does not describe is the external environment that intent lands in, and intent that ignores its receiving environment becomes waste, regardless of how faithfully it has been governed through the layers.
This is the oldest question in good systems engineering. Practitioners trained in the discipline learned to ask it first: is the world ready for the proposed solution? It came before the design, before the requirements, before the architecture. A technically excellent system landing in an unready world is just an expensive failure. The question survives because the failure mode does.
World context runs as an orthogonal to the Stack. It is not a seventh layer above purpose, because the relationship between purpose and world is reciprocal rather than hierarchical, purpose is shaped by world, but also takes a stance toward it. World context is a column running down the side of the diagram, testing each layer against the readiness of the external environment for that layer’s intent to act.
The questions are different at each layer.
World context for Human Purpose. Is the purpose this organisation has committed to still coherent given the world it now operates in? Has the world moved in ways that make the purpose more urgent, less plausible, or quietly obsolete?
World context for Strategic Intent. Is the strategy testable against current conditions; the competitive landscape, the regulatory direction, the capital environment, the political mood? Or has the strategy been written for a world that no longer exists?
World context for Domain Intent. Is the domain ready for what the organisation intends to do within it? Workforce skills available, supplier ecosystem mature, established practice able to absorb the change, regulatory frame stable enough to operate against?
World context for Project Intent. Is the user ready, is the organisation ready to receive the change, are the prerequisites in place? Many of the most expensive project failures are technically sound projects launched into project-unready environments.
World context for Execution Intent. Is the runtime environment ready? Are the tools mature? Are the controls in place? Is the platform that will execute this intent actually able to do so reliably?
World context for Machine Execution. Is the operational environment ready? Observability in place, support capability adequate, escalation paths defined, rollback possible?
Good looks like an organisation that runs this test routinely, at every layer, and is willing to delay or abandon intent that has been governed beautifully but lands in an unready world. Failure looks like technically excellent intent that ships into an environment that cannot absorb it, followed by surprise that the result fell short.
The current AI moment makes this question newly visible. Many AI deployments now in production are technically capable, internally governed, and landing in worlds – regulatory, cultural, organisational, user – that are not yet ready for what they do. The disappointment that follows is often blamed on the technology. More often it is the symptom of intent that passed every internal test and failed the external one because nobody asked.
Inheritance and promotion
The Stack only works if intent moves in both directions.
Downward movement is inheritance. Organisational intent flows into domain intent. Domain intent flows into project intent. Project intent flows into execution intent. Each layer adds specificity without contradicting the layer above. A project does not re-argue the organisation’s position on privacy. A specification does not re-derive the domain’s clinical safety standards. The context is available because it has been made available, deliberately and structurally, by the layer that owns it.
Most organisations do this badly. Strategy lives in slide decks no delivery team reads. Domain standards live in policy libraries no engineer can operationalise. Each project starts cold, rediscovers the context it should have inherited, and either reinvents it inconsistently or skips it entirely. The cost of that pattern was tolerable when execution was slow. It is not tolerable when execution is fast enough to ship the wrong thing before anyone notices the missing context.
The mechanism that fixes it is not another portal. It is making upstream intent structurally impossible to bypass. Architecture decisions exist as records the next team has to read before they extend the system. Domain standards exist as policy expressed in code, applied at the point of execution rather than cited in retrospect. Acceptance criteria reference the project intent statement they descend from, so the line back to purpose is traceable rather than implied. None of this is exotic. It is the discipline of treating intent as a first-class artefact rather than a meeting output.
Upward movement is promotion. A team discovers a better way to handle deletion requests. A project develops a safer pattern for agentic review of generated content. A service team learns what users actually need from a particular journey. In most organisations these discoveries die where they happened: in a retrospective note, a Confluence page, a Slack thread, the heads of the team that learned them. The Stack treats those discoveries as candidate intent. Local patterns that prove themselves are assessed, refined, and promoted into domain or organisational intent, where they become available to everyone downstream.
The mechanism that makes promotion work is cadence and authority. Cadence: a regular review at the domain layer where local patterns are surfaced for assessment, not as an extra meeting but as part of how the domain maintains itself. Authority: someone at the domain layer is empowered to promote, modify, or reject a candidate pattern with reasoning that becomes part of the record. Without cadence, promotion is sporadic and political. Without authority, it is theatre. With both, the organisation builds a slow but compounding stock of judgement it does not have to keep rediscovering.
This is what makes the Stack a living architecture rather than a static governance model. Static governance controls. Living intent learns. In an era where execution is accelerating, the organisation that does not have a mechanism for promoting hard-won judgement back upstream is the organisation that keeps rediscovering the same lessons at increasing cost.
Intent fidelity as the control metric
Once you govern intent and delegate execution, you need a way to know whether the delegation is working.
The conventional answer is delivery measurement. Did the system produce what was specified? Were the acceptance criteria met? Is the dashboard green? Those questions are still worth asking. They are also no longer sufficient, because the failure mode of an AI-accelerated system is rarely obvious incompetence. It is plausible misalignment. The output looks coherent. The task appears complete. The metrics agree. And something important has been lost between the purpose that triggered the work and the artefact that emerged at the other end.
Intent fidelity is the measurement of that loss.
It asks four questions, at any layer of the Stack:
Completeness. Did the execution address the full intent, or only the parts that were easiest to specify?
Correctness. Is the output factually, technically, and operationally right?
Alignment. Does it reflect the values, constraints, and trade-offs that mattered at the layer above?
Consistency. Does it fit with the wider intent it was supposed to inherit from?
These are not abstract questions. They are operable. Completeness can be checked by comparing the original intent statement against the output and identifying what was dropped. Alignment can be checked by surfacing the constraints from the layer above and testing the output against them. Consistency can be checked at the inheritance points where most leaks happen.
What this looks like in practice: a team ships a customer communication that satisfies its acceptance criteria precisely while completely missing the tone the brand requires. The dashboard is green. The output is technically correct. The completeness check would pass. The alignment check – does this reflect the values and constraints from the layer above? – fails. Most organisations do not run the second check, because they do not have a vocabulary for what the second check is. The Stack gives them one. Fidelity is what gets measured at every transition, not only at the end.
The Chief Intent Officer role described in the previous article is, structurally, the role accountable for organisational intent fidelity. The Stack is what they govern. Intent fidelity is the metric they govern it by. The relationship between the two pieces is not coincidental, the executive accountability and the measurement substrate were always going to need each other, and naming the Stack is what makes that relationship operational rather than rhetorical.
The Token spin-off, Everybody’s Token ‘Bout It, sits here. Token consumption is one of the first measurable signatures of poor intent fidelity. Vague intent costs money, in cycles, in waste, in iteration. The cost is just newly visible because it now shows up on an invoice.
Risk dials, not binary switches
The Stack does not treat autonomy as a single setting.
A common framing of AI governance is binary: either the system acts, or a human acts. Either the agent has the keys, or it does not. That framing collapses too quickly under contact with real organisations, where the appropriate level of machine autonomy varies wildly by context: by the reversibility of the action, the consequence of getting it wrong, the confidence of the system, the risk appetite of the domain, the regulatory exposure of the decision.
The Stack treats autonomy as adjustable.
- Low-risk, reversible work – formatting a document, drafting an internal summary, classifying a low-stakes record – sits comfortably with high agent autonomy and light oversight.
- Medium-risk work – proposing a customer communication, recommending a clinical action, drafting a contract clause – calls for the agent to propose and a human to approve.
- High-risk work – committing funds, changing production infrastructure, taking an action that affects a patient or a citizen – calls for the agent to support human judgement rather than substitute for it.
- Critical work – the layer at which an action is irreversible or carries a consequence the organisation cannot recover from – calls for human judgement, period, with the agent in an advisory role at most.
These are not separate governance regimes. They are positions on a dial, set at the appropriate layer of the Stack, and reviewed as the system’s track record and the organisation’s confidence in it evolve. The discipline is not in choosing manual or automated. It is in being explicit about which position the dial is set to, who is allowed to move it, and what evidence justifies the move.
This is the operational form of Govern Intent. Delegate Execution. The intent is governed. The execution is delegated. The amount of delegation is tuned, deliberately, layer by layer.
Human gates
Closely related, and worth naming separately.
A human gate is a point in the flow where judgement is required before autonomy increases or consequence is created. Before an agent commits a transaction. Before a generated communication reaches a customer. Before a model-derived recommendation affects a patient. Before a local pattern is promoted into organisational intent.
The instinct to remove gates as friction is understandable and, in many places, correct. The instinct to remove them all is dangerous. Gates are not a sign that the system has failed. They are a design choice about where human judgement creates the most value. A well-designed Stack has fewer gates than its predecessor, and the ones it keeps are placed where they actually matter, at the points where the cost of being wrong exceeds the cost of being slow.
The discipline of gate design is its own work, and a likely subject for a later article. For the purposes of the Stack, what matters is that gates are explicit, proportionate, and architectural. Not bolted on. Not negotiated case by case. Designed in.
The Stack as a control system
One useful way to read the Stack is through the lens of control theory.
A control system has a desired state, a mechanism for action, feedback from the environment, and a method for correcting deviation. Organisations have always had versions of this. Strategy describes the desired state. Delivery performs the action. Reporting provides the feedback. Management corrects the deviation. The whole apparatus of modern enterprise can be read as a slow, human-paced control loop.
Agentic AI compresses every term in the loop. Action becomes faster. Feedback becomes richer. Adaptation becomes continuous. The distance between intent and execution shrinks toward zero.
That compression is the source of both the value and the risk. A well-governed Stack is a well-tuned control system: clear desired state at the top, faithful translation through the middle, instrumented execution at the bottom, and feedback that travels back up faster than drift can accumulate. A badly governed Stack is the same loop with vague desired state, lossy translation, opaque execution, and feedback that never arrives – which is to say, a system that optimises confidently toward something nobody chose.
Control theory has been quietly waiting for organisations to catch up to it for decades. The Stack is, in part, what catching up looks like.
The practical test
For leaders trying to assess where their organisation actually sits, the Stack creates a diagnostic that is uncomfortable in proportion to how seriously it is taken. Six questions are usually enough.
- Where is your organisational intent defined, and in what form? Not where is your strategy deck – where is the artefact that humans and systems can actually inherit from?
- Where is your domain intent maintained, and by whom? When did it last change in response to something execution revealed?
- How do you measure intent fidelity? Do you measure it at all, or only delivery completeness?
- Where are your human gates, and how were they chosen? Are they designed in, or have they accumulated by accident?
- At every layer of the Stack, are you testing your intent against the readiness of the world to receive it? Or only against your internal ambition?
- Who owns the health of the whole?
Most organisations cannot answer most of these questions cleanly. That is not a failure of the organisation. It is a sign that the discipline these questions describe has not been named, structured, or made anyone’s job. The Stack is the start of naming it.
Why this matters now
The series began with the observation that execution had stopped being the constraint. That single shift is the load-bearing premise of everything that has followed. If execution were still scarce, the methodologies of the last fifty years would still be roughly correct. They are not.
Six articles in, the harder claim is the one this piece exists to make. The new constraint is not just intent. It is governed intent; intent that has been defined clearly, translated faithfully, inherited structurally, executed against, measured, and promoted back upstream as the organisation learns. That is the Stack.
Organisations that build it will compound. Organisations that do not will ship confidently toward outcomes that nobody, on reflection, would have chosen, and they will do it faster every year. The cloud parallel running alongside this series is the evidence that this pattern is not speculative. The disciplines that emerged late for cloud computing – FinOps, platform engineering, cloud security posture management – are still expensive lessons being paid for by organisations that retrofitted what they could have designed in. The disciplines that will emerge for intent governance are at exactly that stage now. The coming period will decide which organisations design them in and which pay later.
This is not anti-human. It is the opposite. The Stack moves human contribution to where it actually creates value; defining purpose, translating it faithfully, judging the result. It moves machines to where they actually create value; execution at the speed and scale humans could never reach. The boundary between the two is not a wall. It is the architecture this series has been describing all along.
Govern intent.
Delegate execution.
Measure fidelity.
Test against the world.
Promote what the organisation learns.
Keep humans responsible for meaning.
That is the Stack.
This is the seventh article in the Human Intent series. The first six traced the shift from managing work to governing intent, the obsolescence of the methodologies and paradigms built around the old constraint, the dissolution of work as the organising unit, the practitioner-level capabilities that replace execution competence, and the executive accountability the discipline requires. This piece names the model the series has been describing. The running parallel commentary – The Cloud Said It First at the boardroom level, Everybody’s Token ‘Bout It at the keyboard – sits alongside as evidence that this pattern of governance lagging technology is not new, and not optional.
Frequently asked questions
What is the Human Intent Stack?
The Human Intent Stack is a six-layer model describing how intent moves through an organisation from human purpose to machine execution. The layers are Human Purpose, Strategic Intent, Domain Intent, Project and Product Intent, Execution Intent, and Machine Execution. Each layer is a translation of the one above it, and each transition is a place where meaning can be lost unless intent is governed deliberately.
How is the Human Intent Stack different from existing organisational models?
Most organisational models answer the question of how to coordinate human work. The Stack answers a different question: how to make sure the work being done still reflects what humans meant. It is not a methodology, a maturity model, or a transformation framework. It is a way of seeing how intent flows between human purpose and machine action, and a vocabulary for what has to be true at each layer for that movement to remain faithful.
What is world context in the Human Intent Stack?
World context is an orthogonal that runs alongside every layer of the Stack, asking whether the external environment is ready to receive the intent each layer is about to act on. It is not a seventh layer above purpose, because the relationship between purpose and world is reciprocal rather than hierarchical. The question is the oldest in good systems engineering: is the world ready for the proposed solution? A technically excellent system landing in an unready world is just an expensive failure.
What is intent fidelity?
Intent fidelity is the measurement of how faithfully execution reflects the intent it was acting on. It asks four questions at any layer of the Stack: completeness (did the execution address the full intent), correctness (is the output factually and operationally right), alignment (does it reflect the values and constraints that mattered at the layer above), and consistency (does it fit with the wider intent it inherited from). Intent fidelity is the metric the Chief Intent Officer governs by, and the Stack is what they govern.
How does the Human Intent Stack relate to Intent-Driven Development?
Intent-Driven Development was the proving ground for the Stack. The three-level Intent Hierarchy from IDD (organisation, domain, project) sits inside the Stack as its operational core. The Stack extends the Hierarchy in both directions: upward to the human purpose that strategic intent serves, and downward to the execution intent and machine execution that project intent eventually becomes. The two models are complementary rather than competing. The Hierarchy is the operational engine. The Stack is the full anatomy.
What does it mean to govern intent and delegate execution?
It means moving the object of organisational governance upstream. Where the previous century governed work (plans, milestones, outputs), the AI era requires organisations to govern the intent that execution is acting on. Execution is increasingly delegated to systems, agents, and hybrid human and machine teams. Governance therefore has to sit above execution rather than alongside it. The principle is operational rather than rhetorical: intent is defined clearly, translated faithfully, inherited structurally, executed against, measured for fidelity, tested against the world, and promoted back upstream as the organisation learns.
Who is the Chief Intent Officer?
The Chief Intent Officer is the executive role accountable for the health of the organisation’s intent system. The role is described in the sixth article of the Human Intent series. Structurally, the Chief Intent Officer is the role accountable for organisational intent fidelity. The Stack is what they govern. Intent fidelity is the metric they govern it by. Whether the title survives is uncertain. The need does not.
Human Intent – Chief Intent Officer (CIO)
The 1980s Chief Information Officer was the right answer to the 1980s question. The 2026 question is different. Same three letters, new word in the middle: Chief Intent Officer. Why the existing C-suite cannot quite reach the gap, and what changes when intent moves into the boardroom.
The Interface Was the Revolution
For seventy years we spoke the machine’s language. Now it speaks ours, and that shift, not raw capability, is the real revolution. This piece explores natural language as the interface that finally lets us govern intent and hand the execution to machines.







0 Comments