Your Agents Are Code. Stop Governing Them Like Documents.

Somewhere in your company this quarter, an executive is going to ask for a list of every AI agent in production. The number that comes back is larger than anyone expected. Most of it was built by people who never filed a ticket, nobody has been maintaining the list, and the deadline is measured in weeks. Whoever owns the answer arrives where everyone arrives: a registry kept by hand cannot keep pace with the rate at which agents are created.

The panic is real. The playbook it triggers is aimed at the wrong unit. Getting to the right one starts with why the demand showed up everywhere at once.

Why the demand arrived all at once

A year ago this was a next-year problem. Then coding assistants put building into everyone’s hands, and an agent stopped being an engineering deliverable and became something a sales rep assembles on a Tuesday afternoon.

Enterprise governance was designed for software that arrives through procurement. Today the software arrives through enthusiasm.

The demand outran the answer. McKinsey’s 2025 State of AI survey, fielded across 1,993 respondents in 105 countries, put 62% of organizations at least experimenting with AI agents, 23% of them scaling in at least one function. Among organizations using AI, 51% had already seen at least one negative consequence in the previous year. What neither number captures is who was answerable for any one of those agents when it went wrong.

The current playbook governs the wrong unit

The reflexive answers arrive from two familiar directions. Procurement-led control towers tell you which AI products the company bought. Privacy and compliance platforms tell you which use cases passed an assessment.

Both are useful, and both miss in the same predictable place. A control tower sees the assistant the company holds a contract for, and not the agent someone assembled inside it last week. A compliance platform assesses a use case at the moment it is approved, and never sees the tool connection swapped into it three weeks later. Neither is a failure of rigour. One is an inventory of purchases, the other an inventory of approvals, and the thing actually running in production is neither.

They share the deeper assumption too: that the agent is the unit of governance, a thing you list, score, and approve, the way you once listed applications. That assumption is where the playbook breaks.

An agent is a composition, and the parts are what hold still

An agent looks like words. The canvas on the front end reads like prose: instructions, descriptions, personas. Behind the canvas, all of it is code, and each agent is a composition. Underneath every one sits a set of artifacts: skills, tools, MCP servers, credentials, knowledge folders, memory. The agent everyone is being asked to inventory is the sum of those parts.

That reframing is not new here. This article by Prukalpa Sankar on Context & Chaos has already argued that a skill is a primitive: a reusable, versionable, testable unit of how-to, managed the way software engineering manages code. The parts are also the only stable thing in the system. An agent is the least stable object there is: it gets renamed, forked, cloned by someone who did not know the first one existed, abandoned by an owner who changed teams. Underneath the churn, the same dozen skills and the same few tool connections keep reappearing. Skills are where this bites first. They are the most reused artifact in the set, which means the widest blast radius when one changes and the most people downstream of an edit nobody announced. Ownership assigned to an agent expires the moment the agent is renamed. Ownership assigned to a skill survives every agent that composes it. That is the whole case for moving governance down a level: attach it to the parts and it holds through the churn above, including the agents nobody registered, because an unregistered agent still has to be made of something.

Composition and ownership: the agent gets renamed, the skill keeps its owner

Composition and ownership: the agent gets renamed, the skill keeps its owner | Source: Author

There is a deeper version of this that looks organizational rather than technical. Joe Reis makes it directly: point agents at a siloed company and you get more silos, faster, and what they actually need is access, shared semantics, and a human who owns the result. But a human who owns the result has to own something durable, and the agent is not durable. Attach the person to the skill and the ownership holds. The artifact is where the org chart attaches too.

The discipline is familiar. Only the artifact list is new.

Data teams spent two decades learning this on tables, views, and columns: catalog them, trace their lineage, name an owner, and treat the description of the asset as an asset in its own right. That last habit is the one that transfers, and two writers in this publication have already located where it lands for AI. Juha Korpela argues that conceptual modeling, the discipline the industry quietly abandoned a decade ago, is exactly what agents need now, and that semantics should be separated from data and governed as its own layer. Jessica Talisman set out the vocabulary for that layer. The governed thing was the description of the data as much as the data itself. Agents need exactly that, one artifact list over.

What those artifacts do not have is the tooling. Skills that are code libraries in every meaningful sense get filed like documents, in office suites and shared drives and trackers built over a weekend, and then asked software questions they cannot answer.

Where source control falls short

Most technical readers raise the obvious objection here, and it is the best one. Agents are code, so put them in source control and inherit the software development lifecycle. It falls short on a specific boundary. Source control was built to hold versions of files, not to answer questions about how those files relate. It does not hold the dependency graph between skills. It does not know that one skill is used by five agents, or which agents broke when someone edited it this morning. It does not know who is using what, and it knows nothing about what any of it costs to run. The inverse holds too: skills do not need branching, which is pure overhead for an artifact whose consumers need audit history, versions, and a named owner.

The closer analogy sits one layer over from the repository: a package registry. The repository holds the code. The registry answers who depends on this, which version is safe, and what breaks if it changes. That second set of questions is exactly what governance leaders are being asked this quarter. The request arrives dressed as a version control problem, and underneath it is a registry problem.

Artifacts live at several altitudes

A registry answers who depends on what. It does not answer where an artifact belongs. That second question is altitude, the level an artifact sits at. Some belong to the whole company, the instructions and guardrails every employee’s agent should inherit. Some belong to a department, some to a single team, some to one person. Governance has to handle promotion upward and inheritance downward, and the failure modes are easy to trigger. On the estate I work on, a company-wide instruction file was pushed to every machine, and the push overwrote the local instructions individuals had written for themselves. The control landed exactly as designed. The outcome it existed to protect died on every machine it touched, and nobody was notified, because nothing in the system knew that two artifacts at different altitudes were fighting for the same slot. Layering, promotion, inheritance, and precedence are governance problems, and a spreadsheet has no column for any of them.

Context has altitude: company, department, team and person, and who gets to override whom

Context has altitude: who gets to override whom | Source: Author

What good looks like

Three moves, in order.

Derive the inventory instead of collecting it. A registry that depends on humans filling in forms will never keep pace with the rate at which agents are created. In the data world, inventory stopped being declared and started being scanned. Agents have no connectors, but they leave traces: every session already carries attribution for which agent ran, which skills it invoked, and which tools it touched. On our own estate, inventory derived from what actually runs is the only kind that has stayed accurate, because nobody has to remember to declare anything, and it survives a rename.
Lifecycle over a list. A list tells you what exists. Lifecycle tells you what happens when something changes: versions, audit history, named owners, promotion across altitudes, and the ability to pull one artifact and know exactly which agents just lost a dependency. That last capability is the kill switch most inventory projects quietly lack, and it is the one an incident asks for first.
Attach cost to the artifact. License costs are fixed and negotiated once; token costs follow usage and compound. Until spend traces back to specific agents and the artifacts inside them, nobody can say which agents return value and which are expensive duplicates of the one sitting three folders away. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. Two of those three are visibility problems before they are strategy problems.

Start with one skill

Pick one skill this week that more than one of your agents uses. Ask who owns it, which agents depend on it, and what breaks if you delete it tonight. If those answers take longer than five minutes to assemble, that skill is not governed. Neither is anything built on it.

Gartner predicts the average global Fortune 500 enterprise will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025. Nobody governs 150,000 agents by hand. Everyone can govern the parts they are made of. So when the executive asks how many agents you have, the answer that survives next quarter’s sprawl is a different one: here is what they are made of, here is who owns those parts, and here is what happens when one of them changes.

The Cats of Context & Chaos

Two cats in a laboratory beside a stitched-together AI agent and a tray of labelled spare parts

Congratulations. Now who owns the arm? | Source: Context and Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.