The Agent Census Protocol Names the Fleet Before It Governs It

The new agent governance problem is not theoretical anymore.

A week ago, Forbes framed the uncomfortable part plainly: “The agents are already running. The governance is not.” The line landed because it names what many operators can feel but have not yet turned into a system. The company did not hold a grand launch for its agent workforce. A support team tested one workflow. A developer added a coding agent. Marketing connected an automation. Finance tried a reconciliation assistant. Someone gave a tool access to customer records because the demo needed live context.

Then the pilots became useful enough to keep.

That is how agent fleets appear inside companies. Not as one clean platform decision, but as a string of practical local wins. Each win feels small. Together, they create a new operating surface: non-human workers touching data, creating artifacts, preparing decisions, updating systems, and handing work back to people. The common response is to ask for governance. That is directionally right, but too late and too vague if the business cannot answer the first question.

Which agents exist?

Until that question has a living answer, governance is mostly theater.

The first failure is inventory

A governance platform can enforce rules only against the things it can see. A security policy can define acceptable use only after someone knows which systems are in use. An audit trail can prove activity only if the worker has a name, an identity, and a bounded job. An approval workflow can catch risk only if the trigger is visible before the agent acts.

This is why the market language is shifting from AI enthusiasm to proof pressure. The sharper question in the Forbes piece was not “which governance platform should we evaluate.” It was “how many agents are already acting inside my company that I cannot currently prove anything about.” That is the operational center of the issue.

The problem is not that companies lack AI policies. Many already have them. The problem is that policy often describes desired behavior at a level too abstract to govern a real agent doing real work. “Do not expose customer data” is necessary. It does not tell you which agent can read invoices, which one can draft refunds, which one can update a CRM record, which one runs on a human’s credentials, which one has a retry loop, and which one stops when the evidence is incomplete.

Agents make the old software-inventory problem more urgent because they are not just installed tools. They act. They assemble context, select tools, call APIs, write drafts, open pull requests, route tickets, and sometimes make changes. The inventory is not simply “what app is connected?” It is “what worker is doing which job under whose authority?”

That is a census problem.

A fleet without names cannot be controlled

Human organizations learned this lesson a long time ago. A person cannot be managed well as “someone in operations.” The post has to be named. The product has to be defined. The routing line has to be known. The person needs a manager, permissions, tools, quality standards, and stop conditions. Without that, every failure becomes a conversation about attitude instead of architecture.

AI agents are exposing the same weakness in software form.

An agent without a named job is a source of ambiguity. An agent without an owner is a source of drift. An agent without an authority boundary is a security finding waiting for a calendar date. An agent without a trigger definition is a surprise. An agent without an evidence trail is an argument. An agent without a stop condition is not autonomous; it is unattended.

This is where a lot of production-agent disappointment comes from. In one indexed Reddit discussion, an operator said their internal agents were scaled back after a productivity analysis showed they were “not actually saving us time” because everything had to be extensively reviewed and often redone by a human. Another indexed discussion named the failure point differently: “the trigger layer is where most production agents fall apart.”

Those are not model complaints. They are operating-design complaints.

If the agent’s job is vague, the human review burden expands. If the trigger is weak, the agent starts work at the wrong time or with the wrong context. If authority is borrowed from a human login, the audit trail lies by omission. If the review path is informal, work piles up quietly. If nobody owns the agent, nobody notices when its usefulness decays.

The model may be impressive and the operation may still be ungovernable.

The census is not a spreadsheet of tools

Most companies already have some version of a software inventory. That is not enough for agents.

A normal software inventory tells you what application exists, who bought it, what it costs, and maybe what data category it touches. An agent census has to describe a worker inside a workflow. The unit of account is not the vendor. It is the agent-post.

An agent-post is the smallest governable unit of agentic work. It combines the worker, the job, the trigger, the authority, the evidence, and the owner into one visible object. If two agents use the same vendor platform but perform different jobs, they are two posts. If one workflow uses three sub-agents with different authority boundaries, the census should show three posts. If a single automation sometimes drafts and sometimes sends, those modes need to be separated because the risk is different.

The census should answer ten questions for each agent-post.

1. Name: What is this agent called in plain language?
2. Product: What valuable final product is it expected to produce?
3. Owner: Which human is accountable for its operation?
4. Trigger: What starts the agent, and what evidence is required before it starts?
5. Inputs: What data, systems, files, messages, or APIs can it read?
6. Authority: What may it draft, recommend, change, send, approve, delete, or spend?
7. Routing: Where does completed, partial, blocked, risky, or uncertain work go?
8. Evidence: What record shows what it saw, decided, attempted, changed, and handed off?
9. Review rule: What requires human review, and who receives it?
10. Stop condition: What makes the agent pause instead of improvising?

That is the minimum viable census. It is simple enough for a small firm to keep in a table and serious enough for a larger organization to turn into infrastructure.

The important part is that the census is operational, not decorative. It should be used when someone proposes a new agent, changes a workflow, grants data access, investigates an incident, or asks whether an agent is still worth running. If the roster is not used in decisions, it will become documentation compost.

Data access makes the census urgent

Security teams are already saying the quiet part out loud. Strata’s agentic AI risk guidance describes a governance gap that widens with every new deployment and says security teams struggle to answer basic questions such as which agents have access to customer PII and what permissions an agent actually uses versus what it has been granted. K2view frames the compliance shift similarly: traditional compliance asks whether a system, dataset, or user is governed, while agentic AI compliance asks whether a specific AI interaction is governed.

That distinction matters.

Agents do not merely sit near sensitive data. They request context dynamically. A billing-dispute agent may need the customer’s plan, latest invoice, payment status, refund policy, support notes, and action limits. A legal-intake assistant may need facts, deadlines, jurisdiction, documents, and eligibility rules. A coding agent may need repository access, issue context, test logs, and deployment permissions. The safe boundary is not a static label on one application. It is the interaction between job, trigger, data, authority, and evidence.

That is why a census beats a generic “AI acceptable use” policy as the first move. The policy can say what the organization believes. The census says what is actually operating.

Once the census exists, governance becomes easier because the business can inspect concrete objects. This agent reads customer invoices but cannot issue refunds. This one drafts customer replies but cannot send them. This one opens pull requests but cannot merge. This one can classify legal intake but routes anything involving deadlines to a human. This one may summarize a medical transcript but cannot create treatment advice. This one is paused because its review queue aged past the limit.

The work becomes governable because the worker has been named.

The protocol is small enough to start now

The agent census protocol has three passes.

The first pass is discovery. List every agent, automation, assistant, script, workflow builder, coding agent, chatbot, and tool-connected model currently doing or preparing work. Do not argue about definitions yet. If it can take context and produce or route work with partial autonomy, put it on the list. The point is not philosophical purity. The point is visibility.

The second pass is classification. Convert each item into an agent-post. Name the product, owner, trigger, inputs, authority, routing, evidence, review rule, and stop condition. This is where vague agents either become useful or reveal themselves as unsafe. If nobody can name the product, the agent is probably a demo. If nobody owns it, pause expansion. If the trigger is unclear, it will fire at the wrong moment. If the stop condition is missing, the agent is being trusted to improvise where the business has not made a decision.

The third pass is control. Decide which posts are approved, which need constraint, which should be retired, and which can expand. Tie new agent creation to the census. No new agent gets data access without a post. No new action permission without an authority boundary. No production workflow without evidence. No unattended loop without a stop condition. No hidden worker without an owner.

This is not heavy governance. It is basic management.

A small company can do this in a morning. A larger company can start with one department or one risky workflow. The first version can live in Airtable, Notion, a spreadsheet, a ticketing system, or a simple internal page. The tool does not matter at the beginning. The act of naming matters.

The bottom line

The next phase of AI agents will not be won by the company with the most impressive demo fleet. It will be won by the company that can see, route, review, and stop its agents without panic.

That starts with a census.

Name the worker. Name the product. Name the owner. Name the trigger. Name the authority. Name the evidence. Name the stop condition.

Then govern what is real.

Sources

• Sandy Carter, “Do Your AI Agents Have Governance? Most Don’t, And They’re Live,” Forbes, May 21, 2026, https://www.forbes.com/sites/sandycarter/2026/05/21/do-your-ai-agents-have-governance-most-dont-and-theyre-live/
• Rhys Campbell, “Agentic AI Risks: A Guide to Proper AI Governance,” Strata, updated April 30, 2026, https://www.strata.io/blog/agentic-identity/agentic-ai-governance-how-to-approach-it/
• K2view, “AI data compliance: Why design-time data governance isn’t enough,” accessed May 28, 2026, https://www.k2view.com/blog/ai-data-compliance/
• GlobeNewswire, “Aurora Mobile's GPTBots.ai Upgrades AI Agents from Chat to Execution,” May 27, 2026, https://www.globenewswire.com/news-release/2026/05/27/3301765/0/en/aurora-mobile-s-gptbots-ai-upgrades-ai-agents-from-chat-to-execution.html
• Indexed Reddit discussion, r/AI_Agents, “anyone actually running AI agents in production for client work? or still demo-ware?,” surfaced May 28, 2026, https://www.reddit.com/r/AI_Agents/comments/1tc7pxq/anyone_actually_running_ai_agents_in_production/
• Indexed Reddit discussion, r/AI_Agents, “How are you guys getting AI agents to actually work automatically?,” surfaced May 28, 2026, https://www.reddit.com/r/AI_Agents/comments/1tblazd/how_are_you_guys_getting_ai_agents_to_actually/

Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.