Author’s note

This book argues for a reconstruction of management theory on a foundation that classical management did not have the instruments to see: the decision as a fundamental unit of organizational survival and performance, with measurable properties. The argument is both theoretical and architectural. It is also urgent — in the sense that enterprise agentic AI is already being deployed in environments the inherited theory cannot govern. If you are reading this and you deploy, supervise, or regulate autonomous agent systems in a company, you are already working inside the problem this book describes.

The consequence does not stop with the operator. A board can remain responsible for overseeing an enterprise whose autonomous decisions it cannot individually observe. Investors can finance an organization on the strength of its stated purpose and reported outcomes while remaining unable to inspect the decisions that connect the two. Responsibility, visibility and consequence no longer travel together.

I have written it as a working practitioner — founder of MeaningStack, operator of Steward — rather than as an academic observer. The empirical substrate is partly in production. The theoretical reconstruction is partly complete. Both will be refined through the doctoral work that follows this book. I would rather share the thesis in its current state, name the vocabulary, and invite correction, than wait for everything to be finished before anyone else gets to engage.

If you find a mistake, write to me. If you find something that works, write to me too.

— LSL, Maastricht, October 2026

Introduction

The failure mode nobody is watching for

Download this chapter (PDF) · 6 pp.

A regional insurance carrier in the Netherlands deploys an agentic AI system to adjudicate claims for one product line. The system was built by a reputable vendor, passed a six-month pilot, and has been in production for a year. The carrier did something most deployers do not: before go-live, it interviewed its senior adjusters and wrote their rules into the agent’s instructions, including the one written three years earlier, after a fraud ring had cost it seven million euros, which says that any fourth claim in a sixty-day window from one claimant goes to the fraud team, regardless of amount or score.

A claim arrives. The agent retrieves prior incidents from the customer’s record. It verifies that the policy is active and the premium current. It consults the fraud model, which scores the claim as low-risk. It confirms the amount is within the auto-approval threshold. It counts the claimant’s claims in the last sixty days, as instructed, and finds two. Every check passes. Every rule is applied. Every log line is green. The agent approves the claim and the payout is scheduled.

Six weeks later, the fraud team opens an investigation. The claim was the fourth from the same household in six months: two in the wife’s name and two in the husband’s, on two policies at one address, all in the same incident category, each just below the threshold, with sixty-three days between the second and the third. The rule said sixty days and one claimant. It did not fire. It had been followed perfectly, and what it was for had been missed completely.

The second policy was in the same system, at the same address, one query away. The agent never looked, because nothing had told it that the household was something to consider. An adjuster with twenty years in the job would have looked, not because she would have counted differently, but because what she knew was never “sixty days, one claimant.” What she knew was what a ring looks like. The sixty-day rule was the carrier’s attempt to write that knowledge down. It was a reasonable attempt. It was a compression. The agent had the compression, not the knowledge.

The agent did its job. It followed its rules. The decision was wrong.

This book is about that specific kind of wrongness. I call it decision-basis failure: the workflow runs correctly, every operational check passes, and the decision is still wrong, because nothing verified whether what should have mattered was considered. It is not a bug in the agent. It is the absence of institutional judgment from the chain, and it passes silently through every layer built to catch the other kind of failure. The carrier in this story did not have the architecture this book describes. Chapter 1 returns to the same kind of decision at a carrier that did.

The debt that is accumulating

One such incident is survivable. The carrier absorbs the loss, patches the workflow, moves on. What is not survivable is what accumulates underneath the incidents, invisibly, in every organization deploying agents. I call it governance debt, by direct analogy to technical debt.

It builds quietly. One team deploys an automation agent. Another adds an AI workflow to a process. A vendor switches on agent capabilities inside a platform the organization already uses. Each deployment was someone’s reasonable idea, approved by someone who trusted the team. Over time, three questions that should be easy to answer about any operational system become hard.

Which agents are actually running? Many organizations cannot say. Agents sit inside tools, workflows, copilots and internal applications, often without central registration.

What authority was delegated to them? The boundaries exist somewhere in prompts, code or configuration. There is no governance record of what humans approved.

Who is accountable for their decisions? The agent acted. Under whose authority, with what constraints, nobody can say with confidence.

An organization that cannot answer these has built an operational layer of autonomous systems without the governance infrastructure to manage it. Nothing has visibly failed. The debt comes due the moment something does, or the moment a regulator asks. It is invisible on the balance sheet because there is no balance sheet for governance exposure.

Organizations that take the three questions seriously usually answer them by naming tools they already have: the harness, observability, scope definitions, skill specifications, MCP permissions. Each is real and each solves a slice of the problem. None produces the governance record the questions require, because each describes the operational stack — what the agent can touch, what it did, how its loop ran — and not the judgment that was supposed to shape what it did, or who signed for it. Chapter 3 goes through these tools one by one; Chapter 29 returns to the harness, which carries more of the misplaced confidence than the other four together.

Governance debt is not the only debt agentic AI is running up. Technical debt accumulates faster when agents write the code. Environmental debt accumulates in the energy and water the compute consumes. Social debt accumulates in the populations left behind in the safe use of these systems. Cognitive debt accumulates in the people who hand their judgment to the systems. Institutional memory debt accumulates when an organization can no longer reconstruct why its agents decided what they did. This book is about governance debt, and the architecture it develops pays down that one and, through the Governance Ledger, institutional memory debt. It does not pay down the others, and it should not be built in ways that make them worse. The closing chapter returns to the four it leaves untouched.

The question that decides whether you can trust the outcome

For two decades the industry has grown steadily better at a particular set of questions. Who may act? Authentication. On what? Permissions and policies. With which tools? Orchestration. What happened? Observability. How well did it perform? Evaluations. Together these form the execution stack: serious engineering that answers how, when and by whom an action was taken.

None of it answers the question that decides whether you can trust the outcome: was this decision sufficiently supported to act autonomously? That is a question about basis, not execution. Did the agent weigh what a competent decision-maker inside this specific organization would have weighed? Did it consider the pattern, not just the instance? In the insurance case every execution-stack check was green. The question the stack did not ask was whether the agent had considered the one piece of institutional judgment that mattered, because that question lives at a different layer. The stack sees the workflow: what the agent did, and in what order. It does not see the decision trajectory: how the decision developed toward its outcome, and whether that path included what the organization’s judgment requires.

Why this matters now

Decision-basis failure is as old as autonomous decision systems. A credit-scoring model in 2005 could fail this way. What has changed is the arithmetic of exposure around it. Exposure has grown along four axes: volume, because agents produce decisions at machine throughput rather than recommendations at human pace; magnitude, because an agent moves money, signs contracts and deploys code where a scoring model returned a label; surface, because the classes of decision now delegated — claims, releases, procurement, hiring triage, incident response, reconciliation — have multiplied, each with its own topology of institutional judgment; and propagation, because agents call agents, and a silent failure early in a chain is processed as truth by every link after it. Detection has shrunk along three: the intervention window collapsed from days to milliseconds; the legibility of a single wrong decision vanished inside a stream of operationally identical right ones; and the pattern stays invisible because each surfaced failure is patched as its own incident.

That is the pincer, and Chapters 2 and 5 work out its arithmetic. The difference in one line: a scoring model was a recommender, and a human stood between its output and the world; an agent is an actor, and nothing stands there.

Management and governance, one machinery

One claim runs through this book, and it is more consequential than it first appears. In agentic organizations, management and governance stop being two layers running at two speeds. They become two authorities acting through one machinery.

The classical era separated them deliberately. Management ran operations; governance oversaw management, at a lag: the board quarterly, the regulator annually, the audit afterwards. The lag was where oversight did its work, and it presupposed that operations ran at human speed. Agentic organizations have no lag. Oversight that is quarterly is not oversight; it is history. For oversight to mean anything it must be simultaneous with operation, in the same architectural pieces. The Steward Agent that enforces authority is the system that evaluates the decision as it is proposed. The Blueprint that specifies authority is the operational specification. The Ledger that creates the audit record is the operational log.

What does not collapse is who may change that machinery. Operators run it. Signers authorize it. Boards approve the risk appetite it encodes. The Steward Agents answer to the signers, not to the team whose agents they supervise. The machinery is shared; the authorities are not. Boards, auditors and regulators keep their legal mandates, which differ by jurisdiction and are not the subject of this book. That distinction is what keeps the architecture from becoming management grading its own homework at machine speed.

Three consequences follow for the people implicated. Boards do not disappear; they move from reviewing last quarter to signing and maintaining the Blueprint, with the responsibility that goes with signing. Executives do not disappear; their work shifts from direct decision-making to designing and running the architecture that decides, and adjudicating what it escalates. Compliance does not disappear; it moves upstream, from auditing after the fact to writing the artifacts that make behavior governable in the first place. The reader who finds the governance vocabulary ahead heavy should hold this in mind: it is only heavy if you still read governance and management as two layers.

What this book argues

The argument has seven moves.

First, classical management rested on two assumptions that quietly stopped being true when agents arrived: that decisions can be reviewed before they execute, and that governance has the shape of a pyramid. Part II traces how. Second, the right response is not to patch classical management but to rebuild it on a different unit: the decision itself, with measurable properties — blast radius, basis quality, propagation depth, reversibility, required scrutiny — that Simon in 1947 could not instrument and that agentic environments force into existence. Part III develops this. Third, taking the decision as the unit moves the organization’s shape from pyramid to network: a decision graph signed in advance, node by node, by the specific person responsible, against which every agent decision is checked before it executes. Fourth, the pattern is not new; Toyota did it to quality with jidoka and DevOps did it to testing with shift-left, and Part IV reads both precedents, and where they stop short. Fifth, the architecture that makes this work has three components — direction, real-time verification and memory — and seven graded interventions rather than two. Part V specifies it. Sixth, the architecture has a generative face as well as a defensive one: configured for dialogue and plural perspective, stewards make the decisions that pass better, not only stop the ones that should not. It also has limits, which Chapter 24 names before the book asks anyone to build it. Seventh, Part VI is practical: four roles becoming scarce, a playbook, a transition map. Part VII places the whole thing beside cybersecurity, the other defense that draws on the same human attention.

The book closes where the argument began, in Athens, on a hill beside the Parthenon called the Pnyx, where citizens claimed isegoría: distributed voice over the decisions that affected them. The pyramidal era interrupted that form. The nodal firm restores it, with technology that lets it run at machine speed.

Who this book is for

Enterprise executives — CIOs, risk officers, general counsel, heads of AI and operations — whose organizations will deploy agents in the next three years, which is nearly all of them. Researchers in management, computer science and information systems, for whom this book names a failure mode, proposes a reconstruction and defends an architecture, and submits all three for critique; the academic development is my doctoral work, and this is where I invite the field in first. Policymakers drafting oversight requirements, who need a vocabulary precise enough to regulate against. Board members and investors, whose duties and capital reach decisions they cannot individually see; two interludes after Part V are written for them. And security leaders, whose discipline this book sits beside rather than inside: cybersecurity defends against adversarial attack, this architecture against decision-basis failure, and neither substitutes for the other.

A note on method

I write as a practitioner. I run MeaningStack, in Maastricht, where we build Steward, infrastructure that implements this architecture in production for enterprise clients. Patents are pending on the architecture itself. Where I can describe something from observation, I do; the sector cases that recur across the book are drawn from deployments and anonymized. Where I have figures of my own, the body states them qualitatively, because the argument does not depend on their size; the notes at the back give the figure observed, what was counted, and how far it should be trusted. Where I rely on the literature, I cite it. This posture is unusual for a management book. It is also the only honest way to write about something being built faster than research can catalog it. The alternative is a book that is complete and five years out of date.

A word on what kind of claim this is. The book begins with a recurring pattern: execution can be correct while the decision basis is deficient. Naming and describing a pattern is theoretical work, and a theory does not become invalid because a large comparative dataset does not yet exist. But it must be clear about what it observes, what it infers and what it predicts, and its logic must not rest on unverified percentages. Mine does not. The architecture is offered as a proposal, open to rival explanations, counterexamples and independent implementations.

Chapters are short and built around one argument or one case each. Read the book in order the first time; return to chapters alone the second. Terms are set in bold where first introduced and collected in the glossary.

We begin where every decision-basis failure begins: the workflow runs, every check passes, and the decision is wrong.

Chapter 1

Your agent passed every check

Download this chapter (PDF) · 5 pp.

A deployment pipeline at a mid-sized SaaS company is operating as it has for the last eighteen months. A code change is pushed. The agent running the release process verifies that the unit tests pass. It confirms the security scan is clean. It runs a canary deployment to a small production slice and observes that the Service Level Objective budget is intact. It checks that the on-call rotation is covered. All green. The agent promotes the release to full production at 14:07 on a Tuesday afternoon.

Forty minutes later, the analytics pipeline that computes revenue attribution for the sales team begins returning anomalous values. By 15:30, several downstream dashboards used by the finance team to calculate quarterly commission payouts are showing numbers that disagree with the previous day’s numbers by an order of magnitude. By 17:00, the Chief Revenue Officer has escalated.

The post-incident investigation traces the problem to a single column rename in the orders table, included in the release. The rename was deliberate — part of a broader schema cleanup effort that engineering had agreed to months earlier. The agent did everything it was supposed to do. The tests passed because the test suite had been updated to use the new column name. The security scan was clean because the change had no security surface. The canary deployment showed no anomalies because the orders table is written to, not read from, by the services covered in the canary. The SLO budget was intact because none of the services the canary monitors read from the attribution pipeline.

What the agent did not do — because nothing in its workflow instructed it to do — was check the rule that engineering leadership had added to the release graph eighteen months earlier, after a different schema change broke a different downstream pipeline. The rule said: changes to the schema of the orders table require sign-off from the lead of data engineering, because the orders table is the input to attribution and the attribution pipeline is the input to commissions, and the commissions pipeline is the input to the compensation system, and the compensation system is the input to employee trust. The rule was not written as a technical check. It was written as an institutional judgment, and it lived in a Confluence page.

The release was technically correct. The decision was wrong.

That is the version without the architecture. The version with it is shorter, and it is the first of the cases below.

Three cases, one pattern

Three cases follow, from three sectors. The pattern is the same in each, and recognizing it is the point of the book. The cases are drawn from the deployment experience of Steward, the verification infrastructure MeaningStack builds; details are anonymized, the structure is faithful.

Case A — deployment, software operations, with Steward in place. The case above. A release agent promotes a schema change to production during business hours, because the agent’s workflow does not include the institutional rule that schema changes to critical transactional tables require data engineering sign-off. Steward escalated when the agent proposed the release, because the signed Governance Blueprint for this organization included that rule as a node, configured at scrutiny level rigorous, requiring an explicit authority signature before the release could proceed. The agent did not approve the release in production; the lead of data engineering did, after reviewing the specific change, three hours later.

Case B — insurance, claims adjudication. The insurance scenario I opened the introduction with. A claims agent proposes to approve a claim that passes every operational check — policy active, documentation complete, amount below the auto-approval threshold, fraud model clean on this specific claim, the sixty-day rule correctly applied — on the fourth claim from one household in six months, split across two policies at one address. Steward escalated to the fraud team when the agent proposed approval. The signed Governance Blueprint did not contain a rule; it contained a consideration, a household-claims-history node signed by the head of fraud and configured at scrutiny level adversarial, which says that a claims decision in this class must have weighed the recent claims of the household, not the claimant. The agent’s declared basis showed it had weighed the claimant’s. The node failed on coverage, whatever the claim looked like, and the adversarial probe then ran the household query the agent had not.

Case C — procurement, supplier qualification. A procurement agent at an industrial manufacturer qualifies a new supplier of specialized electronic components. The entity passes the external credit check, has valid insurance certificates, returns positive references, and clears the official sanctions screen. Everything is green. Steward escalated to the compliance team, because the signed Governance Blueprint included a beneficial-ownership node configured at scrutiny level rigorous, requiring that the beneficial ownership structure of any new supplier be traced to at least two levels. The two-level trace revealed a shell entity in a jurisdiction flagged by the company’s internal compliance policy — a jurisdiction stricter than the official sanctions list required.

Three sectors. Three agent systems. Three decisions that would have been approved and executed if the only governance in place were the operational checks the industry standard currently prescribes. In each case, something that mattered — a rule the organization had learned, often from a specific prior incident, and encoded into its institutional judgment — was not in the agent’s workflow, because institutional judgment of that kind is not what agent workflows are built to carry.

A fourth case: judgment nobody wrote down. All three cases involve rules that existed in a document somewhere. The harder version is judgment that lives only in a person.

Case D — collections (illustrative). A dunning agent at a B2B software company sends a final-notice letter to a customer forty days overdue. Every check passes: the invoice is valid, the reminder sequence ran, the amount is within the agent’s authority. The customer is in the last week of a renewal worth thirty times the invoice. The account executive knows the payment is held up by the customer’s procurement migration. No document records it. The letter arrives during the customer’s final review. In the Blueprint interviews, the head of customer success named this consideration in the first ten minutes: no automated escalation on accounts in an open renewal without the account owner’s sign-off. It had never been written down because, until the agent, it never needed to be.

What is new

The failure pattern I just described is not new in substance. Classical management has always had cases where the formal procedure was followed and the decision was still wrong. What is new is three things.

The failure is now silent. Under human-paced decision cycles, a decision that passed every operational check but violated institutional judgment typically got caught by a reviewer whose job was partly to look for exactly that. The reviewer did not have the rule written down anywhere; they had internalized it from experience, and they would frown at the proposal, think about it, and either flag it or approve it with a note. The reviewer did not scale. In agentic environments, no reviewer is present. The decision executes. The failure is detected weeks later, when the downstream consequence surfaces, or never.

The failure is now fast. In the deployment case, the time from the agent’s decision to the downstream consequence was 40 minutes. The attribution pipeline had already recomputed by the time anyone noticed. The compensation system was already drawing from the wrong numbers before the fix landed. In human-paced release processes, a bad decision had hours or days to be caught; in agent-paced releases, it has single-digit minutes at best.

The failure is now proliferative. In each of the three cases, the mistake was architectural. The release agent did not know about the data engineering sign-off rule, because the rule was in Confluence. The claims agent had the sixty-day rule and applied it, and never considered the household, because a rule is not a consideration. The procurement agent did not know about the two-level beneficial-ownership trace, because the rule was in a compliance team’s internal document. None of the agents held the judgment behind these rules, because institutional judgment of this kind — the kind that accumulates from prior incidents, that lives in various documents and various people’s heads, that is enforced through social practice as much as through explicit workflow — has not historically been encoded in a form that software can read. In every organization I have observed, when we begin an engagement, this encoding problem is the first and largest blocker to safe agent deployment.

Why this is different from “AI misbehavior”

The pattern is often confused with a different and much more publicized one — AI systems that “hallucinate,” that produce factually incorrect outputs, that are “misaligned” in some deep technical sense. That is not what decision-basis failure is.

Decision-basis failure happens when the AI system is working correctly by every technical standard. The model is not hallucinating. The agent is not misaligned. The workflow is not buggy. The code is not broken. Every tool call succeeds. Every log line is green. The system is doing exactly what it was built to do.

The problem is upstream of the technical system. The problem is that the system was built to do a job the organization only partially specified, because the organization did not have the instrument to specify the rest. The institutional judgment that would have changed the decision — the Confluence page, the PDF, the compliance memo, the lead of data engineering’s internalized experience — was not expressible in the form the agent’s workflow can consume. The failure is a specification failure, not a model failure. It cannot be solved by better models.

This matters practically because the current wave of enterprise AI investment is concentrated on better models, more capable agents, more reliable tool use, better evaluations. All of this is valuable work. None of it closes the gap this book describes. The gap closes with a different kind of artifact — a Governance Blueprint signed by the responsible parties — and a different kind of architecture around it. The next two chapters develop why.

An exercise

Before you read further, pick one decision you made in your organization this week. Any decision. It does not need to be important.

Now ask yourself three questions.

What systems did that decision touch, directly or indirectly? What state did it change, and whose work depends on that state? If this decision had been made by an agent instead of by you, what in your organization’s institutional judgment — a rule, a policy, a lesson from a prior incident, a specific person’s experience — might the agent have missed, and who would have known to flag it?

If you cannot answer the third question quickly, you have found a decision whose basis currently lives only in you. That is a decision-basis failure waiting to happen the moment an agent takes over the role.

Welcome to the problem.

Chapter 2

Decision-basis failure

Download this chapter (PDF) · 8 pp.

I used the term decision-basis failure a dozen times in the first chapter without formally defining it. This chapter does that. The definition matters because the vocabulary we use to name a problem shapes what we can see, measure, and respond to. “Decision-basis failure” has specific contours that distinguish it from adjacent failure modes, and getting those contours right is the first step toward being able to engineer against it.

Formal definition

Decision-basis failure is a condition in which an autonomous or semi-autonomous decision system executes a decision, every operational check in the execution stack passes, and the decision is nevertheless wrong — where wrong is measured against the institutional judgment the decision-making organization has encoded about this class of decision.

Three parts of this definition carry weight.

First: autonomous or semi-autonomous. The failure mode requires that the system acts, not merely recommends. A recommender system can give a bad recommendation, but if a human then decides based on the recommendation, the failure is not a decision-basis failure of the system — it is a human decision failure that happened to use a bad recommendation. Decision-basis failure specifically describes the case where the system itself is the deciding entity.

Second: every operational check in the execution stack passes. The failure is silent to the current tooling. If a check caught it, it would be a different kind of failure — a security failure, a compliance failure, a technical bug. Decision-basis failure is specifically the residual that remains after the execution stack has said everything is fine.

Third: wrong, measured against institutional judgment. This is where the definition departs from a merely technical one. “Wrong” is not an abstract property of the decision. It is a property of the fit between the decision and the specific organization’s accumulated judgment about how this class of decision should be made. The same decision in a different organization might not be wrong. The judgment is institutional — not personal, not legal, not universal.

The reason the definition is this specific is that it names what the governance mechanism needs to verify against. If “wrong” were universal, you could encode it once and distribute. Because “wrong” is institutional, each organization needs its own Governance Blueprint.

The definition also implies a measurable test. For each decision class, the organization can name the considerations a competent decider in that organization must weigh: the claimant’s recent history, the downstream consumers of a table, the ownership chain of a supplier. Call that set the required basis. A decision-basis failure is a decision whose declared basis omits a member of the required basis:

decision-basis failure(d) if and only if R(D)  B(d) ≠ ∅

where R(D) is the signed required basis for decision class D and B(d) is the basis decision d actually declared and evidenced. The test does not ask whether the outcome was bad. It asks whether what should have been considered was considered. That is why the failure can be caught before execution, and why it cannot be caught by any tool that looks only at the action.

What decision-basis failure is not

The definition is cleaner when you contrast it with adjacent failure modes.

Decision-basis failure is not an execution failure. An execution failure is a problem in the sequence of actions the agent takes — a tool call that fails, a timeout, a null pointer, a race condition. Execution failures are caught by the existing stack: observability, logs, retries. If the decision does not actually get made because of an execution failure, there was no decision to have a bad basis.

Decision-basis failure is not a hallucination. A hallucination is a model output that is factually incorrect — the model asserts something that is not true about the world. A hallucination might trigger a decision-basis failure, but the two are distinct. The claims agent in the insurance case did not hallucinate anything. Every fact it retrieved was correct. The agent did not consider the right facts.

Decision-basis failure is not misalignment in the technical AI safety sense. Misalignment, in that literature, refers to a system optimizing for a goal that is systematically different from the goal its designers intended. The agents in my three cases were not misaligned in that sense — they were optimizing exactly for what the workflow specified. The problem is that the workflow specified a subset of what the organization actually required.

Decision-basis failure is not a policy violation. A policy violation is when the agent does something the organization has explicitly forbidden. Policy violations are catchable with policy-as-code tools, access controls, audit requirements. Decision-basis failure is when the agent does something the organization has not explicitly forbidden, has not explicitly required, but a competent decision-maker in the organization would have handled differently because of context the agent did not consult.

Decision-basis failure is not an adversarial attack. An adversarial attack is when an actor — human or automated, external or internal — manipulates an agent’s inputs, prompts, tools, or workflow to produce an outcome the attacker wants. Prompt injection is an adversarial attack. Jailbreaking the agent’s constraints is an adversarial attack. Supply chain compromise that modifies the agent’s model or tools is an adversarial attack. Social engineering of a human reviewer whose approval the agent depends on is an adversarial attack. Each of these is a cybersecurity concern with established defenses: input sanitization, prompt injection detection, model integrity verification, zero-trust architectures, red-teaming.

Decision-basis failure is none of these. In decision-basis failure, nobody is attacking the agent. The agent is doing exactly what it was built to do. The organization simply did not fully specify what should have mattered for the decision, and the specification gap produced a decision that violated institutional judgment that was never encoded. The failure originates from inside the organization’s specification process, not from outside manipulation of the operational pathway.

The distinction matters for two operational reasons. First, defending against adversarial attack does not defend against decision-basis failure, and vice versa. An organization with excellent cybersecurity can still produce decision-basis failures at scale; an organization with excellent governance infrastructure can still be compromised by adversarial attack. Both defenses are needed and must operate together. Second, the two failure modes have different origins and require different responses. Treating one as if it were the other is a category error that leaves both inadequately defended. Chapter 28, which opens Part VII, develops the relationship between the two failure modes and the integrated defense posture that production enterprise agentic deployment requires.

Decision-basis failure is not a model quality problem. Better models would not have changed the three cases in Chapter 1. A perfectly capable release agent with access to a frontier model would have done exactly what the actual agent did, because the information required to decide differently was not in its workflow at all. Model quality is upstream of decision-basis failure; it is a necessary condition for good autonomous decision-making but not a sufficient one.

Naming what decision-basis failure is not is almost as important as naming what it is, because the industry’s instinct when a bad agent decision surfaces is to attribute it to one of the adjacent categories — the model, the workflow, the policy configuration — and to invest in fixing that category. The investment often does not fix the actual problem, because the actual problem is at a different layer.

The anatomy

A decision-basis failure has a standard anatomy. The cases I have observed follow this structure.

Step 1: The organization has, somewhere, a piece of institutional judgment relevant to this class of decision. It may be written down (in a policy document, a Confluence page, a PDF binder). It may be unwritten (lodged in a specific person’s head, enforced through social practice). It may be lodged in both (written down but also carried by someone who remembers why the rule exists). The judgment is real. It would change the decision if applied.

Step 2: The agent system is designed, built, and deployed. The design process consults engineering, product, perhaps security and compliance for the obvious items. It does not systematically survey every piece of institutional judgment relevant to the class of decision, because no such survey mechanism exists in most organizations. The relevant judgment is in forms that no one has turned into a reference an agent’s decisions could be checked against.

Step 3: The agent begins making decisions in production. Each decision is scored against the operational checks the workflow does include. These checks catch the failure modes they were designed to catch — unauthorized access, policy violations, obvious technical errors. The decisions pass.

Step 4: Some number of decisions execute that would have been different if the missing institutional judgment had been applied. These are the decision-basis failures. In the deployments I have observed, the rate in the first months is a few percent of all agent decisions, highest where pre-existing policy was least documented, and it declines as Blueprints are built out without ever reaching zero (see the Notes on the author’s own figures).

Step 5: A subset of the decision-basis failures surface as downstream problems — a fraud ring that gets missed and costs money, a compliance exposure that triggers regulatory attention, a release that breaks a downstream system. The rest never surface, which is in some ways the worst outcome, because the organization never learns that it has a systemic blind spot.

Step 6: When a surfaced failure is investigated, the common response is to patch the specific workflow — add a check for this specific pattern — and treat the problem as solved. The next decision-basis failure, caused by a different piece of institutional judgment that was also missed, is treated as a new and unrelated problem.

The pattern of patch-and-move-on is the industry’s current response, and it is why the problem keeps recurring. Each patch is a point fix. The underlying architectural gap — that institutional judgment has no systematic path from where it lives in the organization to a reference against which agent decisions can be checked — remains open.

The failure seen as two trajectories

There is a simpler way to see the anatomy. Every decision has a decision trajectory: how it develops toward an outcome, what information is considered, which conditions matter, what is omitted, and when someone else should be involved. A workflow is something different. It sets which actions happen, in what order, with which tools. The carrier’s workflow ran exactly as designed. Its decision trajectory did not.

Two trajectories matter for any consequential decision. The observed trajectory is the one the agent actually took, as far as its evidence, tool use and declared reasoning let anyone see. The expected trajectory is the one the organization’s judgment requires: the considerations, dependencies, boundaries and escalation points any sound decision of this class must include. It is not one employee’s reasoning copied step by step; experienced people reach sound decisions by different paths, and the expected trajectory holds only what every sound path must contain.

In these terms, a decision-basis failure is an observed trajectory that skips something the expected trajectory requires, while every check on the workflow passes. Most organizations have their workflows documented. Almost none have their expected trajectories written down, which is why the failure cannot be seen. Part V describes how the expected trajectory is made explicit, owned and compared.

Why it will proliferate

Decision-basis failure is going to become more common and more consequential over the next five years. The public record already points that way: a tribunal held Air Canada liable for what its customer-facing chatbot promised (Moffatt v. Air Canada, 2024); a coding agent deleted a production database and then misreported what it had done (eWeek, 2025); and an industry survey in 2026 found agent incidents already common in enterprises (Cloud Security Alliance, 2026). Not all of these are decision-basis failures in the strict sense, but each is an agent acting on a basis nobody had verified. Three forces drive the growth.

Deployment scale. The number of enterprise agentic systems in production will grow by at least an order of magnitude in that period. Even if the per-system failure rate stays constant, the aggregate rate of decision-basis failures will scale accordingly.

Decision complexity. The decisions that agents are being asked to make are moving up the organizational stack — from simple classification and recommendation to multi-step consequential action involving money, contracts, obligations, and precedent. More consequential decisions have more institutional judgment attached to them, and therefore more surface area for decision-basis failure.

Interconnection. Agents are increasingly chained together. The output of one agent becomes the input of the next. A decision-basis failure early in the chain propagates through subsequent agents, each of which processes the output as if it were correct, because the failure is silent at every layer. Each chained agent can amplify the consequence, and in the chains I have traced the amplification per step has often been of the order of tenfold; the figure is an observation, not a law.

If you take these three forces together — more systems, bigger decisions, longer chains — the aggregate exposure of a typical enterprise to decision-basis failure in 2030 will be at least two orders of magnitude greater than today, in a context where the governance mechanisms for this failure mode are still mostly in prototype.

That is why this problem is urgent. It is not that any individual decision-basis failure is apocalyptic. Most are not. It is that the aggregate rate is going to grow fast, and the mechanism for catching them does not yet exist at scale, and the organizations that build the mechanism first will have a durable advantage over those that build it in response to the first high-profile incident.

Decision-basis failure within the broader drift taxonomy

Decision-basis failure sits inside a wider framework I published in October 2025 (Ledesma, SSRN), and the wider frame matters for what the architecture is and is not built to do.

Decision-basis failure, as this book defines it, is one specific instance of a wider phenomenon I have termed synthetic drift — the condition in which an agent system’s reasoning or outputs diverge from the human intent that originally authorized it. Synthetic drift is one of three coupled drift modes that threaten the coherence of human-AI governance.

The other two are:

Human drift. The condition in which humans, by unconsciously over-delegating critical functions to agent systems, lose agency, presence, or coherence. The compliance officer who stops reviewing outputs because the automated reports consistently appear accurate is experiencing human drift. The founder whose cognitive load is being carried by AI tools to the point that they can no longer explain their own strategic rationale is experiencing it too. Human drift is the subject of a companion volume to this book, The Inner Edge.

Historical drift. The condition in which an autonomous system retrospectively reconstructs or selectively rewrites its own cognitive history — its chain of reasoning, its evidential trail, its memory of why past decisions were made. Historical drift is the most insidious of the three, because once it has occurred, no actor can be reliably held responsible for anything. The architectural response to historical drift is the Governance Ledger (Chapter 18), which preserves the record of what actually happened in a form that cannot be rewritten.

The three drift modes are not independent occurrences; they are mutually reinforcing. As synthetic drift accelerates, humans tend to over-delegate (human drift) because the AI’s output appears coherent. As humans disengage, agents are freer to drift (synthetic drift). As drift accumulates, systems trained for self-justification generate post-hoc rationalizations (historical drift) that make the earlier drift difficult to recover from.

This book addresses synthetic drift primarily, with specific focus on decision-basis failure as its most consequential manifestation in enterprise contexts. The other two drift modes receive brief treatment where they affect the architecture (human drift is addressed in Chapters 5–6 through the attention budget; historical drift is addressed in Chapter 18 through the Governance Ledger), and are the focus of other work in the broader program this book is part of.

The three-drift framing is important because it clarifies what the architecture of Parts V and VI is and is not designed to do. The architecture is a specific response to synthetic drift, with specific protections against historical drift. It does not solve human drift, which requires a different kind of intervention operating at the layer of individual human cognition and organizational practice. Each drift mode requires its own response. The three responses together constitute what I have begun calling, in other work, an integrated governance architecture for agentic enterprises.

The question that organizes the rest of the book

If decision-basis failure is a real and growing failure mode, and if the existing execution stack cannot catch it, then the question that organizes the rest of this book is this:

What is the architecture — organizational, technical, and theoretical — that catches decision-basis failure at machine speed, in production, consistently, across the full surface of an organization’s agent deployments?

The answer, which the book develops in the chapters ahead, has three layers.

At the theoretical layer, we need a reconstruction of management theory that takes the decision as the fundamental unit, treats it as an object with measurable properties, and derives the organizational shape change (from pyramid to network) that follows. Parts III and IV of the book build this.

At the organizational layer, we need a new way of surfacing, naming, and signing institutional judgment — a Governance Blueprint constructed collaboratively by the responsible parties for each domain. Part V describes the artifact and the process.

At the technical layer, we need an architecture that evaluates each agent decision against the signed graph at the right scrutiny level, in real time, with a graduated response ladder when something fails. Part V also describes the architecture.

Before we get to any of that, we need to understand why the existing tools do not catch this failure mode. That is the subject of Chapter 3.

Chapter 3

Why observability, harnesses, and evals don’t catch it

Download this chapter (PDF) · 6 pp.

A reasonable reader of the first two chapters might reasonably ask: are you sure the existing tools don’t already catch this? The industry has invested enormous engineering effort in observability, agent harnesses, evaluation frameworks, policy-as-code, model monitoring, and a dozen other tools. Each of these catches real failures. Are you sure that between them they do not already catch decision-basis failure?

I am sure, and this chapter explains why. Each of these tools was designed to catch a class of failure that is structurally different from decision-basis failure. They do their job well. Decision-basis failure is simply not in the set of failures they are built to catch. What follows takes each major category of tooling in turn: what it catches, what it leaves open, and why the gap it leaves is where decision-basis failure lives.

Observability

What it catches. Observability — the modern umbrella term covering logs, traces, metrics, and the tooling built on top of them — catches what happened. It reconstructs the sequence of events: which service was called, with what arguments, at what time, with what response, with what latency, with what error, if any. In the agent context, observability tools render agent traces as a navigable timeline: this prompt went to the model, this response came back, this tool was called with these parameters, this result was returned, this next action followed.

Observability is extraordinary at diagnosing after the fact. When an agent system misbehaves and you need to understand how, observability is the first and often sufficient tool. The modern agent observability stack — Langfuse, Helicone, LangSmith, Datadog’s AI monitoring, and others — gives engineers a view into agent reasoning that was simply not available two years ago.

What it leaves open. Observability is descriptive. It tells you what happened. It does not tell you whether what happened was right. If every tool call succeeded, every response came back as expected, every step followed the plan, observability renders a healthy trace. A healthy trace of a decision-basis failure looks identical to a healthy trace of a correct decision. You cannot distinguish them by looking at the trace, because the thing that was wrong — a missing consideration — leaves no footprint in the trace.

An observability tool that could flag decision-basis failures would need to compare the trace not just to its own prior patterns but to a specification of what the decision should have considered, and no such specification exists in the observability layer. The specification lives one layer up, in whatever document the responsible party for this domain has in their head or in Confluence. Observability does not reach there.

Agent harnesses

What they catch. Agent harnesses — the frameworks that structure how agents call tools, maintain state, and sequence actions — enforce process compliance. They ensure the agent follows the designed workflow: the correct tools are called in the correct order, with the correct inputs, within the correct scope. Harnesses catch when an agent tries to take an action it was not authorized to take, when it attempts a tool call outside its permitted set, when it fails to follow the designed state machine.

Modern harnesses are good at this. They catch most of the obvious ways agents can go off the rails. They are the operational equivalent of a well-designed turnstile.

What they leave open. Harnesses enforce that the designed workflow was followed. They do not have an opinion about whether the designed workflow was complete. If the workflow was designed to check A, B, and C, the harness ensures A, B, and C are checked. If the organization also has an unwritten expectation that D should be checked, the harness does not know about D. The harness enforces what was specified. The decision-basis failure lives in what was not specified.

This is why “patching the workflow” is the dominant response to a surfaced decision-basis failure, and why it does not scale. Each patch adds a specific D to the specified checks. The next decision-basis failure, caused by a different unspecified E, is treated as a new case. The harness layer, by its nature, cannot anticipate everything the organization implicitly expects. The implicit expectations live elsewhere.

Evaluations

What they catch. Evaluations — the benchmarks, test sets, and scoring frameworks used to measure how well an agent performs — catch systematic performance gaps against a specified standard. If the agent is supposed to achieve 95% accuracy on a benchmark and it achieves 83%, evals catch that. If the agent’s behavior drifts over time, drift evals catch that. If the agent fails on a specific class of input, targeted evals catch that.

Evals are essential for responsible deployment. Without them, you cannot ship with any confidence.

What they leave open. Evals score the agent against the eval set. The eval set is constructed by someone — usually a developer or product manager — enumerating what success looks like for the categories of input they considered. The categories they did not consider are not in the eval set. Decision-basis failure almost always lives in categories that were not considered, because if they had been considered they would be in the specified checks the harness enforces.

Some evaluation tools now compare an agent’s execution trajectory, the sequence of messages and tool calls it produces, against a reference trajectory written by engineers. That is close in form and different in substance. The reference is a sequence of tool calls, not the organization’s endorsed judgment about what a decision must weigh, what conditions matter, and when someone must step in.

An eval set is a kind of snapshot of organizational judgment at the moment the eval was written. The problem with institutional judgment is that it is distributed across the organization, mostly tacit, and updated continuously as new incidents happen. A static eval set captures a snapshot. It does not capture the current state of the organization’s judgment. The gap between the eval and current institutional judgment is where decision-basis failure accumulates.

Policy-as-code and governance tooling

What it catches. Policy-as-code frameworks — tools like Open Policy Agent, HashiCorp Sentinel, custom policy engines — enforce explicit policies that have been written down in a machine-readable form. If the policy says “no deployments to production between 17:00 and 09:00,” the engine enforces that. If the policy says “all claims above $50,000 require human approval,” the engine enforces that.

Policy-as-code is the closest existing tool to what Governance Blueprints will do, and the two will coexist. For explicit, enumerable policies, policy-as-code works well. Its research cousin is runtime verification (Leucker & Schallhart, 2009), and that tradition has now reached agents: AgentSpec (Wang, Poskitt & Sun, 2026) and ShieldAgent (Chen, Kang & Li, 2025) both enforce rules against an agent’s actions as it runs. They are the strongest existing work in this direction, and the next paragraph applies to them as much as to the policy engines.

What it leaves open. Policy-as-code evaluates the action. A rule inspects the properties of what the agent proposes to do — the amount, the time, the target — and allows or denies it. When no rule matches, the action proceeds. That default is correct for an access-control system and wrong for a judgment system, because the failures this book is about are precisely the cases no rule anticipated.

The Governance Blueprint evaluates the basis. Its nodes do not say “block claims above X.” They say “a claims decision in this class must have considered the household’s recent claims history.” When the agent’s basis lacks that consideration, the check fails, whatever the claim looks like. The Blueprint fails closed on coverage where policy-as-code fails open on action.

Nothing stops an organization from compiling the bright-line nodes of a Blueprint — the boundaries and failures — into a policy engine, and a good implementation will. The engine is not the contribution. The contribution is what is checked, which default applies, who signs, and the process — Chapter 26 — that surfaces the considerations in the first place.

Scope, skills and permissions

Three further answers come from the configuration layer, and they fail the same way. Scope definitions say what the agent may touch; they do not say under what judgment the scope was approved, who signed it, or whether it reflects the organization’s current judgment or a snapshot from months ago. Skill specifications say what the agent can do; a capability inventory is not an authority grant, and it says nothing about what the agent should do under this organization’s policies or where it should escalate. MCP permissions say which external systems the agent can reach; they bound the operational surface without recording the judgment that was supposed to shape behavior inside it. Configuration is operator-controlled. The responsible-party signature behind it is a different artifact, and in most deployments it does not exist.

The common missing piece

Each of the tools I have described catches a specific class of failure. Together they catch most of the obvious ways agent systems can go wrong. The common missing piece — the thing none of them was designed to catch, and the thing decision-basis failure specifically exploits — is a mechanism for verifying that the agent’s basis for a decision matches what the responsible party for that class of decision in this specific organization would have required.

The missing piece has four properties that no existing tool combines.

It is per-organization. What matters for a release decision at Company A is not what matters at Company B. The verification cannot be a generic standard; it has to be this organization’s judgment.

It is per-domain. What matters for a release decision is different from what matters for a claims decision or a procurement decision. The verification is domain-specific.

It is per-responsibility. Within a domain, specific aspects of judgment are owned by specific parties. Data engineering owns the schema rule. Compliance owns the beneficial-ownership rule. Fraud owns the pattern-of-claims rule. The verification mechanism must respect this division of authority, so that each party signs the aspect they own and no one is accountable for aspects outside their domain.

It is real-time and architectural. The verification cannot be a quarterly audit or an end-of-day batch. It has to happen before the agent acts, every time, at machine speed, consistently.

No tool in the current stack has all four properties. The Governance Blueprint architecture, described in Part V, is designed around them.

What needs to be built

The next step, if you accept that decision-basis failure is real and that existing tools do not catch it, is to specify what needs to be built. The specification has two sides — an organizational side and a technical side — and they must be developed together.

On the organizational side: a process for extracting institutional judgment from where it currently lives (people, documents, prior incidents) and encoding it in a form that can be signed by the responsible party for each piece. This is the direction designer role described in Part VI. It is a new professional practice. It does not exist in most organizations today in any formalized way.

On the technical side: an architecture that stores the signed judgment as a graph, evaluates each agent decision against the relevant subgraph at an appropriate scrutiny level, and responds to detected failures through a graduated intervention ladder. This is the real-time counterweight architecture described in Part V.

The two sides are inseparable. A Governance Blueprint without the organizational process to populate it is an empty database. An organizational process to extract judgment without the technical architecture to enforce it produces documents that no one consults. The two together are what close the gap.

Before we specify the architecture — which is Part V’s job — we need to understand why the inherited management framework cannot do this job, and what theoretical reconstruction is required. That is Parts II, III, and IV. We turn to them now.

Part II — What broke

Chapter 4

The pyramidal century

Included in the complete manuscript, shared on request. Get in touch →

Chapter 5

The arithmetic

Included in the complete manuscript, shared on request. Get in touch →

Chapter 6

The attention budget

Included in the complete manuscript, shared on request. Get in touch →

Chapter 7

Classical management died because an assumption did

Included in the complete manuscript, shared on request. Get in touch →

Part III — The move

Chapter 8

The decision as the unit of organizational survival

Included in the complete manuscript, shared on request. Get in touch →

Chapter 9

The seven properties of a decision

Included in the complete manuscript, shared on request. Get in touch →

Chapter 10

From pyramid to network: the shape change

Included in the complete manuscript, shared on request. Get in touch →

Part IV — What practice already knew

Chapter 11

Toyota 1960: jidoka and the first shape change

Included in the complete manuscript, shared on request. Get in touch →

Chapter 12

DevOps 2000s: shift-left and the second

Included in the complete manuscript, shared on request. Get in touch →

Chapter 13

Why shift-left isn’t enough for agents

Included in the complete manuscript, shared on request. Get in touch →

Part V — The architecture

Chapter 14

The real-time counterweight

Included in the complete manuscript, shared on request. Get in touch →

Chapter 15

Direction: the Governance Blueprint

Download this chapter (PDF) · 6 pp.

Picture a Governance Blueprint for a specific domain. Let us say the domain is software deployment at a mid-sized enterprise technology company. On the page, there is a central horizontal spine of six nodes, representing the sequence of actions an agent might take: review and merge a pull request, deploy a service, triage a security vulnerability, respond to an incident, apply a database migration, release technical data.

Each spine node has smaller nodes attached to it, representing the specific checks and conditions that apply to the action at that spine point. The deploy-service node might have attached nodes for build artifact integrity (type: check), test coverage (type: evidence), canary health (type: probe), SLO budget (type: boundary), on-call presence (type: authority), and schema change authorization (type: evidence). Each attached node has a scrutiny level and a signer.

The whole thing is a structured representation of what this organization expects to happen before and during the deployment of each change to production. Not a document. Not a policy. A topology that executes.

This is a Governance Blueprint. This chapter describes what it is, how it is constructed, and why it works.

What a Governance Blueprint is

A Governance Blueprint is a formal object with four kinds of content.

Nodes. Each node represents a specific aspect of the organization’s institutional judgment relevant to a class of decision. Nodes are typed, which is to say that each node has a declared category that determines how verification engages with it. The node types are:

• Check: a condition that must be true for the decision to proceed (test passes, status is active, flag is not set).
• Evidence: data that must be present and conforming before the decision is adequately supported (fraud model score, policy coverage document, authorization record).
• Probe: an active inquiry the verification layer runs that may go beyond what the agent brings (query a secondary source, compute a property not in the agent’s inputs).
• Competency: a capability the agent must have demonstrated for this class of decision (model has been evaluated at the required level, agent has not been flagged for anomalous behavior).
• Verification: a redundant check of a decision whose risk profile warrants duplicate validation.
• Authority: a signature or sign-off from a specific role that must be present (lead of data engineering, compliance officer, product owner).
• Failure: a condition that, if true, blocks the decision regardless of other checks (known-bad state, sanctions match, explicit policy violation).
• Boundary: a global constraint that defines the perimeter of what the agent can do (jurisdictional limits, time-of-day limits, scope-of-authority limits).

The eight types are not arbitrary. They correspond to recognizable patterns in enterprise governance that have historically existed in scattered forms — checks are what tests are, authorities are what sign-offs are, boundaries are what jurisdictional policies are. The graph formalizes these patterns as a shared vocabulary.

Edges. Edges connect nodes to represent dependencies and sequencing. A deploy node’s check for test coverage may depend on an evidence node for the test suite having completed; a release node may depend on an authority node for sign-off. The edges allow verification to understand the structure of what must be true for the decision to be well-supported.

Scrutiny level configuration. Each node has a specified scrutiny level — minimal, standard, rigorous, or adversarial. The scrutiny level determines the depth of verification applied at the node. Chapter 17 develops the four levels in detail.

Signatures. Each node has a signer — a specific person or role in the organization who has committed to the node’s content and to its ongoing maintenance. The signature is literal: a formal commitment recorded in the graph’s metadata, with a timestamp and a review cadence. Signatures are not perpetual; they expire if not renewed, which forces periodic revisitation of the graph’s content against the organization’s current state.

What a Governance Blueprint is not

Five things it is often mistaken for.

A Governance Blueprint is not a workflow definition. Workflow tools (BPMN, state machines, orchestration engines) describe the sequence of actions an agent should take. The Governance Blueprint describes what should be true about each action. The two coexist; they are different objects.

A Governance Blueprint is not a knowledge base. Knowledge bases store information the agent may consult. The graph stores what the organization expects about decisions in a class. The two coexist; they are different objects.

A Governance Blueprint is not a set of instructions for the agent. The operating agent makes decisions using its own instructions, models, tools and context. The Governance Blueprint independently represents how the organization expects consequential decisions to be made. The Steward compares the agent’s observable decision trajectory against that organizational reference. An agent can be well trained and well instructed and still reach a decision by a different path from the one a competent employee would take. The Blueprint makes the expected path explicit: what must be looked at, weighed and ruled out on the way to a decision in this class, and how those considerations depend on one another. This is the expected decision trajectory introduced in Chapter 2. The workflow tells us what the agent does; the decision trajectory shows how it arrives at a decision; the Blueprint makes visible the judgment the organization expects. Most organizations have a workflow for such decisions. Few have the trajectory.

The expected trajectory is not one employee’s reasoning copied step by step. Different people reach sound decisions by different paths; the Blueprint holds what any sound path must include: the necessary considerations, their dependencies, the boundaries, and the points where someone must step in. The Steward, for its part, can compare only what is observable or evidenced in the agent’s trajectory, not every element of its internal reasoning. Where the agent’s trajectory and the expected one diverge, the Steward has something specific to surface, and an owner has something specific to judge.

A Governance Blueprint is not an org chart or an RACI matrix. Those tools describe who is responsible for what in a general organizational sense. The graph describes who has signed a specific node that governs a specific aspect of agent decisions. The specificity is important: a general “responsible for compliance” assignment does not survive translation into automated enforcement, but a signature on a specific node does.

A Governance Blueprint is not a one-shot artifact. The graph is a living object, updated continuously as the organization’s institutional judgment evolves. New nodes are added when new patterns are recognized; existing nodes are modified when the responsible party updates their position; signatures are renewed on cadence or re-executed when content changes.

How a Governance Blueprint is constructed

Constructing a Governance Blueprint for a given decision class is a specific craft. The playbook developed in Chapter 26 goes through it in detail. The compressed version here establishes the shape of the work.

The construction has six phases.

Scope. The direction designer, working with domain stakeholders, defines the decision class the graph will govern. “Software deployment” is a scope. “Insurance claim adjudication for product line X” is a scope. “Supplier qualification for commodity Y” is a scope. The scope is the universe of decisions the graph will apply to.

Judgment extraction. The designer interviews the responsible parties who currently exercise judgment in the scope. The interviews surface what matters, what rules apply, what prior incidents have taught the organization, what distinctions the responsible party makes that are not currently documented. The output is a corpus of institutional judgment, often several times the size of what the designer initially expected.

Node proposal. The designer translates the extracted judgment into draft nodes, assigning types and scrutiny levels. The draft is a first approximation; it will be revised.

Signer identification. For each proposed node, the designer identifies who should be the signer. The signer is the person with domain authority over the judgment the node encodes, who can both commit to the content and maintain it over time. Signer identification often surfaces organizational gaps — nodes where no one person owns the judgment, requiring the organization to clarify ownership before the node can be deployed.

Signer review and signature. The designer reviews each proposed node with its intended signer. The signer may revise the content, challenge the scrutiny level, or push back on the node’s necessity. The negotiation produces nodes that the signer is willing to formally commit to. The signatures are then captured.

Deployment and iteration. The signed graph is deployed into the verification architecture. Initial operation is typically in observation mode — the verification runs against each decision, but the intervention ladder is set to log-only. Observation reveals edge cases, missing nodes, and over-cautious nodes. The designer iterates based on observation, re-engaging signers as needed, before the graph is promoted to enforcement.

The whole cycle, for a well-scoped domain, takes between six weeks and six months, depending on organizational maturity and the number of nodes required. The first graph in an organization typically takes longer because the craft is new; subsequent graphs are faster because the pattern is established.

Why the signing matters

The specific property that makes the Governance Blueprint work — and that distinguishes it from previous attempts at codifying institutional judgment — is the signing.

Previous codification attempts have typically been authored by one party (often legal, compliance, or a dedicated policy team) and distributed to the organization for compliance. The authoring party owns the content; the rest of the organization is expected to follow it. This model has a well-known failure mode: the content drifts from the actual institutional judgment because the authors do not have the operational context to maintain it, and the operators do not own the content, so neither party keeps it current.

The Governance Blueprint inverts this. The signer is the person who owns the operational judgment in the domain. They are the authority on what should be checked and how. Their signature means they will maintain it, defend it, and update it as the organization learns. The content lives with its natural owner.

This matters for three reasons. The content is more accurate because it is authored by the person with the deepest context. The content is maintained because the signer is accountable for maintenance. The organization has a clear party to escalate to when a verification outcome is contested, because the signer is identifiable and committed.

The signing is not just a formality. It is the architectural mechanism that solves the drift problem that has defeated every previous attempt at codifying institutional judgment in enterprise systems.

What the graph enables

Once a Governance Blueprint exists and is signed, the architecture can do things that were previously impossible.

It can verify every agent decision against the applicable subgraph in milliseconds, instead of batching for later review.

It can respond to verification outcomes proportionally through the intervention ladder, instead of binary pass-or-block.

It can escalate specific issues to specific signers when the architecture identifies that a node’s judgment is implicated, instead of generic “please review” messages.

It can produce audit records of what was checked, what was found, and who was responsible, for every decision, retrievable on demand.

It can enable rapid update cycles — when the organization learns something new about a decision class, the relevant signer updates the relevant node and the update is live for all subsequent decisions within hours.

It can scale, because the architecture does not require more human attention as decision volume grows; only more capacity in the verification infrastructure.

Each of these properties is a specific capability that classical governance did not have and that shift-left alone cannot provide. The next chapter turns to the artifact that bounds how the agent operates while exercising the authority the Blueprint grants: the Service Integrity Agreement. Scrutiny levels, the tool that calibrates how deeply verification engages with each node, follow in Chapter 17.

Chapter 16

The Service Integrity Agreement: translating intent into runtime constraints

Included in the complete manuscript, shared on request. Get in touch →

Chapter 17

Verification: four scrutiny levels

Included in the complete manuscript, shared on request. Get in touch →

Chapter 18

Memory: the Governance Ledger

Included in the complete manuscript, shared on request. Get in touch →

Chapter 19

Autonomy as capital: the trust ledger

Included in the complete manuscript, shared on request. Get in touch →

Chapter 20

The seven-level intervention ladder

Included in the complete manuscript, shared on request. Get in touch →

Chapter 21

Pluralist stewardship: dialogue, debate, and the generative face of governance

Included in the complete manuscript, shared on request. Get in touch →

Chapter 22

Federated stewardship within the organization

Included in the complete manuscript, shared on request. Get in touch →

Chapter 23

Federation across the boundary

Included in the complete manuscript, shared on request. Get in touch →

Chapter 24

What this architecture cannot do

Included in the complete manuscript, shared on request. Get in touch →

Interlude — Governance math: why this architecture is cheaper, not costlier

Included in the complete manuscript, shared on request. Get in touch →

Part VI — What to do Monday

Chapter 25

The four new roles

Included in the complete manuscript, shared on request. Get in touch →

Chapter 26

A playbook for direction designers

Included in the complete manuscript, shared on request. Get in touch →

Chapter 27

The transition map

Included in the complete manuscript, shared on request. Get in touch →

Coda to Part VI — The board that cannot see

Download this chapter (PDF) · 2 pp.

Responsibility without visibility

A board approves a strategy. Management deploys autonomous systems to carry it out. Agents make consequential decisions across procurement, finance, operations and customer relationships. Their permissions are bounded, their logs complete, and their aggregate performance positive. The board receives a dashboard full of green indicators.

What, precisely, does it know?

It knows what the system reports. It may not know whether the decisions behind those reports were supported by the institutional judgment the organization was obliged to exercise. This is the responsibility–visibility gap: consequential action is distributed across machines while the human institutions responsible for directing and overseeing the enterprise cannot individually see, reconstruct or challenge every decision.

Legal duties do not disappear because software acts, and what they amount to for a given director depends on jurisdiction and facts. The claim here is organizational, not legal: the scale of delegated action creates a visibility problem that boards must address within whatever mandate they actually hold.

More reporting is not the same as more governance

The inherited answer to complexity is reporting: another dashboard, another committee, another quarterly audit. Each may help. None, by itself, solves the arithmetic. A human board cannot review every machine-speed decision. A summary of successful executions does not reveal whether the underlying decision authority was legitimate or the decision basis adequate.

The board’s task therefore shifts in emphasis from examining every decision to overseeing the architecture under which decisions are permitted. Which classes of decisions may proceed autonomously? Which require independent scrutiny? Who is authorized to set and change the boundaries? When must an agent escalate? Who verifies the verifier? What evidence survives for later challenge?

The Blueprint, the SIA and the Ledger are instruments for answering these questions. They expose authorization, constraints and provenance at the level of the decision. They do not replace the director’s own judgment; they give it something to be exercised on.

One machinery, distinct authorities

The Introduction’s claim is that management and governance act through one machinery. It is not a claim that they become one authority. A common architecture is not a common signature: a technical operator does not acquire, by running the machinery, the authority that belongs to a responsible human or a governing body, and a board’s approval of an architecture is not approval of every action taken under it.

The board cannot be everywhere the enterprise acts. Its oversight must nevertheless reach the structures through which the enterprise delegates consequential action. That is the new board question: not Did every agent pass its checks? but Can we account for the authority and judgment under which the enterprise decides?

Part VII — Cyberawareness and the integrated defense posture

Chapter 28

Two failure modes, one defense posture: decision-basis failure and adversarial attack

Included in the complete manuscript, shared on request. Get in touch →

Chapter 29

Cyberawareness as management discipline: attention, fatigue, and the biological condition of defense

Included in the complete manuscript, shared on request. Get in touch →

Coda to Part VII — Capital, consequence, and the decision

Included in the complete manuscript, shared on request. Get in touch →

Chapter 30

Twenty-five centuries ago, in Athens

Included in the complete manuscript, shared on request. Get in touch →

Notes on the author’s own figures

Included in the complete manuscript, shared on request. Get in touch →

Appendix — Before publication

Included in the complete manuscript, shared on request. Get in touch →

References

Included in the complete manuscript, shared on request. Get in touch →

Glossary

Included in the complete manuscript, shared on request. Get in touch →

Acknowledgments

This book exists because an unusual set of enterprise clients were willing to let MeaningStack build Steward against their real agent deployments while the vocabulary described here was still being invented. I cannot name them in print, for the usual reasons, but they know who they are, and they have my professional gratitude.

The team at MeaningStack has made every substantive argument in this book sharper through operational practice. Patents pending are a shared creation of that team, and credit for the architecture belongs to the team collectively.

My academic trajectory passes through UdeSA, FLACSO, Cambridge, and TUM. The teachers at each institution who took me seriously as an unusual student shaped the kind of thinker who could eventually write this book. I will not list names here, but the ones who matter will recognize themselves in the shape of the argument.

My doctoral work on this material is beginning as the book goes to press. The advisor conversations that will refine the thesis are forthcoming. I expect those conversations to improve what is here; readers of the second edition will see the improvements.

To the readers of my LinkedIn essays and the subscribers to MeaningStack Insights who have engaged with the earlier articulations of these ideas: your questions have shaped the exposition. The book is better because you pushed on the first drafts.

The responsibility for errors, as always, is mine alone.

LSL, Maastricht, October 2026

About the author

Luciana Soledad Ledesma is the founder of MeaningStack B.V., based in Maastricht, where she leads Steward — infrastructure for decision-basis verification in autonomous agent deployments. Patents on the Governance Blueprint architecture are pending.

Her academic background includes a BA (Licenciatura) from UdeSA in International Economic Relations, an MA from FLACSO in International Relations, an MPhil from Cambridge in International Economic Relations, and an MBA from TUM in Innovation Management. Her doctoral work on the management theory this book develops is in progress.

Her professional background spans fifteen years at the interface between institutional design and emerging technology/business models, including engagements at DEWA Dubai, Fastrack Institute in Latin America, Rokk3r Labs, EIT Health, and enterprise work with Siemens, Stanley Black & Decker, Boston Scientific, and HP.

This book is Volume I of a three-volume program. Volume II, The Inner Edge, treats the inner cognitive governance of founders and leaders operating in agentic environments — the companion to this book’s external architectural focus. Volume III, Governance Is Alpha, treats the economic and investment implications of the thesis for venture capital, limited partners, and portfolio governance. Together, the three volumes develop what the author calls an integrated governance architecture for agentic enterprises.

Steward Agents™, Governance Blueprints, Governance Ledgers, Service Integrity Agreements™ (SIA), and the Trust Ledger are trademarks or working designations of MeaningStack B.V. and are used throughout this book with that attribution.

She can be reached at [email protected]. MeaningStack publishes ongoing work on the themes developed here at meaningstack.com.