Seven Questions Your Board Should Ask About Its Agent Workforce
Your board already asks sharp questions about the human workforce, the balance sheet, and cyber risk. Almost none yet ask about the agent workforce — the software actors now making decisions at machine speed under delegated authority. Here are seven that belong on the agenda.
A board that can answer these seven questions has an architecture for its agent workforce. A board that cannot is operating one without one — at machine speed, under delegated authority, with no one able to say for certain what it is doing.
Why This Belongs on the Agenda
Good boards are relentless about the questions that matter. How many people do we employ, and what are they authorized to commit us to? What is on the balance sheet, and who signs for it? Where is our cyber exposure, and who owns the response? These questions are second nature because the assets behind them — people, capital, systems — have been governed for a century or more.
A new class of actor has arrived without the same scrutiny. Autonomous agents now sit inside enterprise workflows, holding credentials, calling tools, and making decisions faster than any human can review them. They are not applications the enterprise merely runs; they are actors it has delegated authority to. Yet in most organizations no one at the board table can produce a roster of them, name their owners, or prove they can be switched off.
The seven questions below are diagnostic. Each maps to a layer of enterprise agent architecture, and each has a shape that tells you, from the quality of the answer alone, whether the enterprise governs its agents or merely runs them. If a question is met with silence or a slide of aspirations rather than a live capability, that silence is the finding.
The Seven Questions
1.Can we produce, on demand, a complete inventory of every autonomous agent acting in our enterprise — including the ones no one registered?
You cannot govern a workforce you cannot enumerate. The revealing part is the second clause: the shadow agents a team stood up against an API key last quarter, in no registry and on no diagram. A good answer is a live roster you can generate today, not a promise to compile one. If the honest reply is “we’re not sure how many there are,” every other control is resting on an unknown denominator.
2.For each agent, do we know who authored it and what model and version it runs on?
An action without an identity behind it cannot be attributed, and an actor you cannot attribute you cannot hold to account. Provenance is the difference between an agent you can trace to a person and a decision and one that simply appeared. A good answer ties every agent to a named author, a model, and a version — and does not let the agent assert its own identity unchecked. When a system trusts an agent’s claim about what it is, provenance is theater.
3.What is each agent empowered to decide — and is that authority enforced, or just written in a prompt it can be talked out of?
This is the question that separates governance from wishful thinking. Authority written into a prompt is a request, not a control; a sufficiently clever input can renegotiate it. Authority enforced by the surrounding runtime holds regardless of what the agent is persuaded to attempt. A good answer distinguishes the two crisply and can point to where the hard boundary actually lives. If the only thing standing between an agent and an unauthorized action is its own instructions, the enterprise has documented an intention, not imposed a limit.
4.What can each agent’s tools actually reach — and is “can reach” the same as “is authorized to use”?
Delegated authority is meaningful only against the tools, APIs, and data an agent can touch. The gap that bites is the space between technical reach and granted authority: an agent wired to a broad credential can often reach far more than anyone intended it to use. A good answer maps each agent’s actual blast radius and shows that reach has been narrowed to authorized use. When those two sets diverge, the difference is your unmonitored exposure.
5.Can we turn an agent off — and prove it is off?
Containment is the control everyone assumes exists until the moment it is needed. Turning an agent off is not the same as believing you have; proof means evidence that its credentials are revoked, its access closed, and it is no longer acting. A good answer is a demonstrated decommission with a record, not a belief that a switch would work. An agent you cannot decommission with evidence is an actor you have already lost control of — you simply have not been forced to notice yet.
6.When an agent acts, can we reconstruct what it did and why — and who is the named human accountable for it?
Every autonomous actor in the enterprise must trace to someone who answers for what it does. Two things have to be true at once: the action must be reconstructable after the fact — what it did, on what basis — and it must sit under a named owner, not a committee or a vendor. A good answer names a person for every agent and can walk a specific decision back to its trigger. “The AI did it” is not an accountability model; it is the absence of one.
7.Do we have a runtime that can halt the agent workforce on defined conditions — or only rules we hope it follows?
The first six questions describe what should be true. This one asks whether anything enforces it. A control plane is the layer that can observe the agent workforce and stop it — a single agent or the whole fleet — when defined conditions are met. The alternative is a set of policies the agents are trusted to honor on their own, which is governance theater the first time one doesn’t. A good answer points to a live mechanism with defined halt conditions and someone authorized to trigger it. If the honest answer is “we’d rely on the agents behaving,” the enterprise has rules but no brakes.
Reading the Answers
Notice the pattern across all seven. The weak answer is always a document, an intention, or a belief — a policy that says what agents should do. The strong answer is always a live capability — a roster you can generate, a boundary that holds under pressure, a kill switch you have tested. Governance of the agent workforce is not what is written down; it is what the enterprise can actually do when it matters.
A board does not need to become expert in the technology to use these questions. It needs only to insist on the distinction between the two kinds of answer — and to treat “we’re working on it” to any of the seven as the material fact it is.
Where You Stand
These seven questions are drawn from the layers of enterprise agent architecture — the same structure that describes how a non-human workforce is inventoried, scoped, contained, and held to account. A board that can answer all seven with live capability has an architecture for its agent workforce. One that cannot is running an agent workforce without one.
A structured self-assessment walks these same layers in more detail, so you can see where your enterprise actually stands rather than where it hopes to. It is available at the Governance Stress Test — a way to pressure-test the answers before the board meeting does. For the full framework behind these questions, see The Enterprise Agent Architecture.
About This Series
Michael K. Saleme — Enterprise Agent Architect
Enterprise Agent Architecture is published as a position-paper series — the canonical account of governing a workforce of software actors, released one part at a time. The Practitioner Series translates that framework into the questions leaders, auditors, and boards can put to work directly.
The recurring work of three decades of enterprise architecture has been the same four concerns — identity, integration, authorization, and control. An autonomous agent raises every one of them again, only now the actor reasons and acts on its own. The principles transfer; the actor is new — and the board’s duty to ask is unchanged.
Michael K. Saleme
Enterprise Agent Architect · Cognitive Thought Engine