8
AI Stack & Context Friction
Your Company May Already Have More AI Agents Than It Can Govern
More agents can increase capability while quietly multiplying borrowed authority, unclear boundaries, and accountability nobody designed.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
The agent problem starts before the agent acts
Technical stewardship is not the same as intelligence stewardship
Capability does not create authority
An autonomous loop still needs somewhere to stop
Every agent does not need the whole company
The trainer cannot carry the whole system either
Your company may not have an agent problem yet
Map the authority before you add the next agent
INTRODUCTION
There is a particular stage of AI adoption where the conversation changes. At first, the questions are about access: Which model should we use? What can we automate? Can we build a custom assistant for this team? Then the experiments start working. Someone connects a model to a database. Someone else gives an assistant access to a workflow. A vendor proposes three agents where there used to be one. A department builds its own. Another team quietly adds AI to a process nobody has formally mapped. Suddenly the problem is no longer whether the company can make AI do useful things. The problem is that useful things are beginning to act inside the company faster than anyone can explain who gave them permission to do so.
This is where “too many AI agents” becomes a misleading diagnosis. The number may be uncomfortable, but quantity is not the first thing I would inspect. I would want to know whether anybody can explain what each agent is allowed to know, decide, change, approve, communicate or trigger, which sources it is expected to trust, who can correct it, who can stop it, and who remains accountable after it acts. A company can govern twenty narrow agents well and govern two broad ones badly. The risk begins when capability grows faster than the authority structure around it.
The agent problem starts before the agent acts
When businesses talk about AI agents, the category can get loose very quickly. One person means a custom GPT with a role and some files. Another means an automation that calls a model in the middle of a workflow. Another means a system that can retrieve information, choose tools, update records and initiate actions. Someone else is imagining a digital employee that will generate ideas, make decisions and somehow run a meaningful part of the business while the humans get on with something more pleasant.
I am less interested in policing the word than I am in noticing what changes when the system crosses from generating to acting. The moment an AI can affect another system, communicate externally, alter a record, trigger a process, spend money, route work, escalate an issue or commit the company to a course of action, governance stops being a policy document sitting beside the technology. Governance becomes part of the technology’s operating conditions.
That sounds obvious until you look at how these systems are actually assembled. The technical vendor may build the agent. An internal business lead supplies a compressed version of what the company needs. IT manages access, security, APIs and infrastructure. Someone else is asked to “train the trainer.” That trainer then teaches the team. The team starts using the system in situations the original builder may never see. Eventually the agent acts on behalf of the organization, and everyone involved can point to a part of the chain they handled correctly.
The uncomfortable question is whether anyone held the whole chain.
Who supplied the business judgment the agent is now carrying? Who translated that judgment into rules, examples, sources and boundaries? Who decided what the system is allowed to infer rather than merely retrieve? Who determined which corrections should become part of the shared operating logic? Who taught the humans what the agent is for, not just how to operate it? Who has the authority to say that the representation of the business inside the agent is stale and needs to be changed?
This is how agent governance can fail even when every individual participant is competent. The failure is not necessarily a bad engineer, a careless business lead or an untrained employee. The failure can be the absence of a role responsible for preserving intelligence and authority across the handoffs between them.
Technical stewardship is not the same as intelligence stewardship
One reason this gets confused is that companies already have people who own technology. That matters. A strong IT or security team may understand permissions, identity access management, APIs, infrastructure, vendor risk, data handling and technical integration far better than the rest of the organization. Those are real governance functions, and an AI system that ignores them is not sophisticated. It is reckless.
But technical stewardship does not automatically include the living intelligence of the business. It may not include why a customer promise matters, which exception overrides the written rule, how the company actually makes a difficult decision, what quality feels like before anybody has turned it into a metric, which language carries legal or reputational weight, which internal source is authoritative when two documents disagree, or which part of a process exists because a human learned something the hard way five years ago and nobody ever wrote it down.
The reverse is also true. The person who understands the business intimately may have no idea how API permissions work, how access scopes should be bounded, what a token budget can become at scale, or how one seemingly harmless integration can expose more of the system than the business intended. Neither side should be asked to pretend it contains the other.
This is the coordination problem beneath a lot of “AI training.” Training can be included in a vendor package and still leave the deeper intelligence problem untouched. Teaching a team how to invoke an agent is not the same as establishing what the agent represents, whose decisions it may carry forward, which boundaries it must respect, how the humans should recognize drift, and what they are expected to do when the agent produces something technically valid but organizationally wrong.
A Human-AI System includes the humans who define, operate, correct and live with the consequences of the machine. If the technical layer and the business-intelligence layer never meet, the agent becomes a very efficient place for their misunderstanding to become executable.
Capability does not create authority
This is the distinction I would put on the wall before a company adds another agent: delegated execution is not delegated authority.
A system can be capable of sending an email without having the authority to make the promise inside it. It can be capable of changing a customer record without having the authority to decide that the new interpretation is correct. It can be capable of approving a next step without having the authority to bind the company to the reasoning that produced it. It can be capable of generating a discount, routing a complaint, rejecting an application, escalating an employee issue or publishing a statement. Capability tells you what the system can technically do. Authority tells you what the organization has decided it may do, under which conditions, on whose behalf, with which limits and with what path for correction.
Those are different properties, and AI makes the difference easier to miss because the execution can arrive wrapped in fluent language. A confident recommendation can look like judgment. A completed action can look like permission. A smooth workflow can make it feel as though the organization settled the underlying decision when what actually happened is that the system found no technical barrier preventing it from proceeding.
That is why every meaningful agent creates an authority chain whether the company designs one or not. Someone supplied the source material. Someone chose the instructions. Someone granted access. Someone defined or failed to define the decision boundary. Someone decided what happens when the system is uncertain. Someone decided, explicitly or by omission, whether the human is consulted before or after the action. If those choices remain invisible, the agent is still exercising an authority structure. It is simply an unexamined one.
The most important question is not “What can this agent do?” It is: when this agent acts inside your company, whose judgment is it carrying, whose authority is it borrowing, and who remains responsible when those two things are not the same?
An autonomous loop still needs somewhere to stop
A related problem becomes visible in a field note we developed inside Human-AI Systems called Spend Nothing Twice. That note began with a very practical signal: the token and API bill. It looked at the moments where an automated system tried something, failed silently, tried again, re-derived context it had already been given, executed against a stale specification, or continued generating because nothing in the architecture had the authority to say the task was complete.
The important part for agent governance is not the invoice. It is the reason the invoice becomes visible. The field note makes a simple structural observation: an agent chain can have a task, a budget and a loop without having a native concept of enough. If the architecture does not provide a gate, the system can continue doing exactly what it was built to do while moving farther away from what the business actually intended.
That is why “human in the loop” is too vague to be useful by itself. Which human? At what point? With what authority? Are they there to click approve after the system has already made the important decision, or do they own the decision boundary itself? Can they correct the source once so the agent stops relearning the same lesson? Can they stop execution when the version is stale? Can they declare the task finished even when the system could generate five more plausible iterations?
In Spend Nothing Twice, four governance laws hold the architecture together: reference settled material rather than re-deriving it, preserve corrections rather than repeatedly relearning them, check the current version before execution, and keep a human final authority somewhere in the loop. Those laws were developed around trust and continuity, but they reveal something important about agents: autonomy becomes more useful, not less, when the system knows where its authority ends.
A boundary is not evidence that you distrust the agent. It is evidence that somebody designed the conditions under which the agent can be trusted.
Every agent does not need the whole company
Governance also does not mean giving every agent a complete representation of the business. In fact, that can be a terrible design. A narrow system may be safer and more useful because it knows less. A compliance-sensitive workflow may need strict isolation. A client-facing agent should not inherit private strategy simply because the architecture makes it technically possible. An independent auditor is less independent if you fill it with the same assumptions as the system it is meant to examine. A task-specific agent may need one authoritative source, one role and one constrained action boundary, not the company’s entire memory.
The deeper Human-AI Systems work around hybrid cognition repeatedly returns to sovereignty and boundary integrity for this reason. More intelligence is not automatically better architecture. The system needs enough context to act coherently and enough boundary to know what is not its business.
This is also where the company has to distinguish between access and authority. Access can often be expressed technically: this agent may read this folder, call this API, write to this table. Authority is richer. It includes whether the agent may interpret ambiguous information, whether it may create a new rule from a pattern, whether it may represent the company externally, whether it can transform a recommendation into an action, and when uncertainty requires escalation rather than improvisation.
The best agent design is therefore not the one with the most impressive list of tools. It is the one whose role can be explained without hand-waving. What is it here to do? What is it explicitly not here to do? What does it know? Where does that knowledge come from? Which source wins? What can it change? What must a human decide? Who maintains it? Who can revoke its authority? What happens when the business changes faster than the agent’s instructions do?
If nobody can answer those questions, adding another agent does not add intelligence cleanly. It adds another place where the company’s unstated assumptions can become executable.
The trainer cannot carry the whole system either
There is a human version of the same problem. Companies often identify one enthusiastic person who has experimented more than everyone else, attended the conferences, tried the tools and volunteered to bring the rest of the team along. Sometimes that person becomes the internal AI lead almost by gravitational accident. They may be smart, motivated and genuinely useful. They may also be standing in the middle of a role the organization has not actually defined.
They are expected to translate vendor language into business practice, technical constraints into team behavior, leadership ambition into prompts, employee anxiety into adoption, and whatever they learned at a conference into a working system. Then they are asked to train everybody else. If the organization has not established the underlying authority, source logic and business context, the trainer becomes another hidden integration layer, carrying a system in their head that the company mistakes for a shared architecture.
This is why one energetic person can produce a burst of AI activity without producing durable AI governance. The activity may be good. The experiments may create real value. But if the knowledge stays attached to one operator, the company has not yet turned that learning into an organizational capability. It has found a talented interpreter.
The answer is not to remove that person or bury experimentation under committees. It is to give the learning somewhere to go. Which practices become shared? Which corrections become policy? Which agent roles are official? Which remain experimental? Who owns the portable business context? Who decides what is safe to scale? Who is responsible for the technical boundary, and who is responsible for the intelligence boundary? Where do those people meet before the agent is deployed rather than after something goes wrong?
This is governance as operating design, not governance as paperwork.
Your company may not have an agent problem yet
There is a boundary condition here too. Not every company experimenting with several agents needs a governance transformation. A small team may have two narrow assistants with limited access, clear owners and trivial consequences if they fail. A prototype may be intentionally disposable. A system that only drafts internal text for human review may not deserve the same control architecture as one that changes customer data or initiates financial action.
The point is not to make every AI experiment heavy. The point is to match governance to agency. The more the system can see, decide, change and execute, the more clearly the organization should be able to explain the authority under which it operates. A drafting assistant and an autonomous workflow should not inherit the same control model just because both are marketed with the word agent.
That is also why counting agents is such a weak diagnostic. Five narrowly governed systems may be simpler than one “do everything” agent with broad permissions, contradictory source material, no clear owner and a prompt that effectively says use your best judgment. The number tells you almost nothing until you know the scope of action and the quality of the authority chain behind it.
So before I would tell a company to consolidate agents, build more of them or buy an agent platform, I would want to see the map.
Map the authority before you add the next agent
If a company came into a Human-AI Orientation saying, “We have agents everywhere and we cannot keep track of what they are doing,” I would not begin by recommending a governance platform. I would map the systems that already exist and trace the authority chain around each one. Who created it? What business problem was it meant to solve? Which sources does it use? What permissions does it have? What decisions has it been allowed to make? Which actions can it take? Where does a human enter? Who can change its instructions? Who can shut it down? Who is responsible for its output when the original builder is no longer in the room?
Then I would look at the gaps between those answers. Perhaps the technical controls are excellent and the business logic is poorly defined. Perhaps the company has strong subject-matter expertise but no disciplined way to translate it into agent instructions and source precedence. Perhaps the same agent has quietly acquired three different jobs. Perhaps a vendor owns too much of the operating knowledge. Perhaps the internal AI lead has become the only person who understands how the pieces connect. Perhaps the system is spending money redoing work because corrections never become durable. Perhaps the organization needs fewer agents. Perhaps it needs more, but each with a narrower role. Perhaps the next move is training, architecture, policy, access control, memory design, or simply naming an owner before building anything else.
The diagnosis comes first because an agent is not just a piece of software that performs a task. The moment it can act, it occupies a place in the organization’s authority structure.
The real question is not how many agents your company has.
It is whether your company can still explain who is allowed to do what, using whose judgment, on whose authority, after the machine joins the chain.
HUMAN-AI ORIENTATION
Who actually has authority when the agent acts?
Bring the agents, copilots, automations, and approval paths already in play. We map capability, judgment, authority, boundaries, and accountability so you can see where action has outrun governance and where the human stop condition belongs.
€950 · 2.5 hours · nothing is sold in the room
FIELD CONNECTION • hUMAN-ai sYSTEMS
Go deeper only when the thought needs another room.
Authentic AI Marketing opens the commercial door. Human-AI Systems holds the deeper architecture, artifacts, and system thinking behind the work.
DEEPER SYSTEMS. RICHER CONTEXT.
Watch / Listen
Read / LLM Ingestion