Scaling Agents in Organizational Contexts
Part 20 of the AOD series
In early 2026, I lived through the most carefully planned blackout of my career. A state government was replacing the legacy financial system that had run its books for roughly two decades. The replacement was a modern software-as-a-service (SaaS) platform, and the switch from the old system to the new one, the cutover, ran over many weeks. At the core of that cutover sat the hardest stretch. The old system was turned off while years of financial records were transformed and imported into the new one. During that window, no one in the state government had access to either accounting system. The new platform is the accounting system for an office that oversees tens of billions of dollars in funding and millions of business transactions a year, so every dollar had to come out the other side and match.
The migration plan ran past 450 steps, with hundreds of people executing it. As head of risk, security, and compliance for the program, I owned the application's security. The core team met every 8 hours to monitor the data transformation, including at 4 AM, because a cutover like this does not pause for business hours. When a process that had been running for more than a day failed, the team traced the root cause, relaunched it, then found several processes that could safely run in parallel and won the lost day back. A rollback plan existed the whole time, and we never touched it.
Then my hour came. When we got the keys to the application for the first time, I had 60 minutes, starting at 1 AM, to activate the tester accounts so teams of testers could validate that the historical data had transformed correctly and the application could open to employees. Behind that hour sat the identity work that had mapped thousands of users across more than a hundred departments into a few hundred security roles before anyone could log in at all.
When the first user logged in, a wave of relief came over me. All those meetings, sleepless nights, and preparation paid off. The result was zero unplanned downtime, with every balance reconciled.
The reason that night belongs in a book about coding agents is simple. The go-live did not succeed on heroics. It succeeded because the discipline already existed before the first byte moved. The identity mapping was designed in advance, the checkpoint cadence was scheduled in advance, the reconciliation criteria were written in advance, and the evidence of all of it accumulated inside the plan itself. Enterprises run this discipline every day for human users. The question this chapter takes up is what happens when the next thousand identities your organization provisions belong to coding agents instead of people.
Agent Permissions Are the New IAM
Identity and Access Management (IAM) is the discipline of deciding who gets access to what, granting exactly that much, and being able to prove it afterward. Every enterprise already runs it. Your badge, your login, and the folders you can see are all downstream of someone's IAM design. The practice is so familiar that we forget it is a design exercise at all.
One part of that migration translates directly to coding agents. The team did not design thousands of bespoke permission sets, one per user. They designed a few hundred security roles, then built a crosswalk in Excel that mapped every user's security level in the old system into a role in the new one. Thousands of people compressed into a few hundred roles. That compression is the discipline itself, not a shortcut around it, because a role taxonomy can be reviewed, audited, and maintained in a way that thousands of individual permission sets never will be.
Designing permissions for coding agents is the same exercise. Define a small set of permission tiers that answer four questions: which repositories can this agent touch, which tools can it call, which data can it read, and which environments can it reach. The word repository here just means the shared folder where a team's code lives. Then map each agent's job function into a tier. A read-only analysis tier can examine code but change nothing. A sandboxed development tier can write code in an isolated workspace. A gated deployment tier can ship, but only through a human approval. A documentation agent does not need deployment credentials. A test-writing agent does not need production data. A fleet of coding agents needs a handful of tiers, not a bespoke permission set per agent, for the same reason a few hundred roles governed thousands of humans across the state.
Agent permissions ARE the new IAM. Provision coding agents the way you provision employees, with scoped roles and individual identities, not the way you install tools.
The individual identity matters as much as the tier. Each coding agent needs its own identity, never a shared service account, which is a login owned by a system rather than a person, because you cannot audit what you cannot distinguish. When a change lands in a repository at 2 AM, "one of the agents did it" satisfies no auditor I have ever met. The migration doubled as a security upgrade for the state along these same lines. We implemented single sign-on (SSO) and multi-factor authentication (MFA), tightened role-based access to finer granularity, scoped data access by agency, and encrypted data movement in and out. A user in one agency saw that agency's data and nothing else.
Coding agents need that same boundary drawn around data. Scope each agent's context by team, by project, and by data classification. An agent working in one team's repository should never carry another team's secrets in its working memory. Readers who came through Chapter 2 will recognize this as context encapsulation grown up. The discipline of protecting what an agent holds in working memory during a session becomes, at enterprise scale, an organizational boundary.
Underneath all of it sits one plain-English rule. A coding agent gets the access its job requires and nothing else, the same standard you already hold every new hire to. Least privilege is not a new invention for agents. It is the oldest rule in IAM, pointed at a new kind of user. And the rule has a maintenance habit attached. Enterprises recertify human access on a schedule, reviewing who still holds access they no longer need. Agent permission tiers deserve the same rhythm, because an agent's job function drifts just like a person's does.
The lifecycle wrapped around that identity has to be just as deliberate. An agent's credential gets issued when the agent is provisioned, rotates on a schedule that runs at machine speed because there is no human at a prompt to answer a multi-factor challenge, and gets revoked the moment the agent is retired. Revocation is the agent world's rollback plan, the containment lever you pull when an agent goes wrong, so the evidence of what it did has to live somewhere the agent cannot reach, because a worker that can edit its own audit log is not auditable. Ownership of this work usually lands on platform engineering to run, with security setting the standard it runs to.
The crosswalk between the two worlds transfers the discipline, not the difficulty. Non-human identity is harder in nameable ways. There is no person at the keyboard to challenge, and the delegation chains branch every time one agent spawns another.
Audit Trails and the Evidence Factory
Enterprises do not have an agent-capability problem. They have an agent-evidence problem. The models are capable enough, and the pilots usually prove it. What stalls adoption at scale is the moment someone outside the pilot asks for proof.
Watch how your own company buys software and you can see the shape of that moment. Procurement stopped taking vendors at their word years ago. Codrut Andrei's Product Security in 2026 report catalogs the pattern across the industry. Every security question a customer asks now maps to an evidence artifact the vendor must produce. Ask whether the product is secure by design and the answer is a threat model. Ask whether activity can be audited and the answer is logs. Ask what is inside and the answer is an inventory. Trust arrives as documents, not assurances.
Coding agent adoption is about to be interrogated the same way, by your auditors, your regulators, and your own leadership. The questions are already forming, and they sound like this:
- Who approved this agent's change?
- What specification was it building against?
- What did the agent touch along the way?
- Who reviewed the output before it shipped?
- What data could the agent see?
None of these questions is new. They are the questions change-review boards have asked about human changes for decades. The only novelty is who did the work.
If your teams run the Agentic Development Lifecycle (ADLC), the six-stage lifecycle Part II of this book built out (Discover, Define, Plan, Build, Deliver, Document), every one of those questions is answered before anyone asks it. Discover and Define produce the spec. Plan produces the approved plan, with inputs, handoffs, and constraints made explicit. Build produces the review records and checkpoint results. Deliver produces the gate evidence showing the work met its criteria. Document closes the loop by writing down what was learned for the next session. The evidence pack assembles itself as a byproduct of doing the work properly.
Teams that bolt coding agents onto existing workflows get the opposite experience. Their first audit becomes archaeology. They reconstruct who approved what from chat scrollback and commit history, under deadline, from memory. The work itself may have been fine. The evidence does not exist, and in an enterprise, evidence that does not exist is work that did not happen.
This is the deepest lesson I carried out of that cutover. Nobody sat down after go-live to write the audit trail. The plan of more than 450 steps, the checkpoint results from the every-8-hours meetings, and the reconciliation records were the audit trail, produced as a side effect of disciplined execution. The plan was the evidence.
Data deserves the same byproduct treatment. During the migration, every file moving in or out of the new system moved encrypted, and access stayed scoped by agency. For coding agents, the equivalent claim should be just as easy to make. You should be able to state, for any agent in your fleet, exactly which data it could see and exactly where its outputs could flow. If you cannot state it, you cannot defend it.
Team Structures for Enterprise AOD
The structural question comes next. If coding agents do more of the building, what do the humans organize into?
Enterprise Agentic-Oriented Development (AOD) does not reorganize around headcount. It reorganizes around small human units directing fleets of coding agents. The working unit of delivery is a pair. A product manager (PM) owns the what and the why. An Agentic Engineer owns the how. The Agentic Engineer is the practitioner role this book has been building since Chapter 6, the person who designs agent systems and orchestrates specialists rather than prompting one model at a time. When delivery demand grows, you add pairs. The team does not swell, the fleet does.
Above the pair sits strategy, and the Product Triad from Chapter 8 still holds there. A Business User, a UX/Product Designer, and an Agentic Engineer decide together what deserves to be built and why it matters. On the agent side of the line, the Governance Triad introduced in Chapter 2 (a PM agent, an architect agent, and a team lead agent) remains the management layer that keeps executing agents aligned between human check-ins.
What changes most at enterprise scale is how coordination happens. It moves from meetings to artifacts. Hundreds of people coordinated the cutover through a single plan of more than 450 steps, and the every-8-hours meetings were checkpoints against that artifact, not substitutes for it. Agentic teams coordinate the same way. The spec is the coordination surface, the ADLC stages are the checkpoints, and when the artifact carries the coordination, you do not need a status meeting to know whether you are on track. You need to read.
This is what makes enterprise adoption tractable. An engineering organization of thousands does not adopt coding agents through thousands of separate experiments. It adopts them through small structured units that do the work, shared permission tiers that scope the access, and one shared evidence trail that catches everything. The structure is the scaling mechanism.
You Can't Mandate Culture
Permission tiers and evidence trails are necessary, and they are not sufficient. They scope what an agent is allowed to do, but a manipulated agent can still do real damage entirely inside the tier you granted it. Adoption is a culture problem before it is a tooling problem. You can mandate licenses and you can mandate training completion. You cannot mandate belief.
I learned this as the product leader of the global DevSecOps capability, the security side of how software gets built and shipped, at a large financial services company. We had world-class security tooling and an adoption problem that no amount of tooling could solve. Developers had every scanner and security gate they needed and little appetite for any of it. Instead of pushing a mandate, I built a Security Champions community. We found the strongest security advocates across the program and made them educators rather than enforcers. Monthly champions meetings gave peers a forum to present regulatory changes and answer each other's implementation questions. Annual hackathons hosted by outside experts turned learning into doing. Every developer in the program was onboarded to the global security offering, vulnerability remediation got faster, and licensing costs dropped through consolidation because teams were finally using the right tools the right way.
The same playbook moves to coding agents almost unchanged. The four moves are these:
- Champions, not enforcers. Find the practitioners already getting results and make them your champions, because their credibility with peers outweighs any executive memo.
- A recurring forum. Give the champions a standing meeting where practitioners answer each other's implementation questions. The question blocking adoption is rarely "why would I use this" and usually "how do I make this work in my codebase."
- A shared library, built early. Prompt patterns, spec templates, and project-knowledge files that worked for one team become the on-ramp for the next, the same role our documentation store played for security adoption.
- A sequenced rollout. Move deliberately from pilot team to champions to standard practice, and let visible wins recruit the skeptics that rollout decks never will.
Education enables what mandates cannot force. That was the engine of the champions community, and the community itself was the cultural counterpart to a process transformation this book has already narrated. Chapter 6 tells that story, the rebuild of a DevOps team into a DevSecOps team where security moved out of developer training and into automated gates. Gates hold the standard in place. Champions make people want to meet it.
Treat your skeptics accordingly. Most of them are not wrong about the risks. They are early about the controls. Hand them the permission tiers from this chapter and the evidence trail the ADLC produces, and watch how many turn into your strongest champions. Skepticism about ungoverned adoption is not resistance. It is a job application for governance.
AOD Beyond Engineering
The strongest evidence that AOD is an organizational discipline rather than an engineering one is where the discipline shows up next. The next adopter is not another software team. It is a legal department.
Anthropic's 2026 Agentic Coding Trends Report tracks coding agents expanding well beyond engineering. The report describes Anthropic's own legal team using coding agents to cut a marketing-review process from two or three days to twenty-four hours, including a lawyer with no coding experience who built self-service triage tools. It profiles Legora, an AI-powered legal platform where lawyers assemble agentic workflows without engineering backgrounds. And it reports Zapier reaching 89% AI adoption across the organization, with more than 800 internal agents deployed.
Read those cases for the pattern underneath them. A lawyer directing a coding agent needs a scoped permission tier, an individual identity for the agent, an evidence trail for what the agent produced, and a community of peers to learn from. That list should sound familiar, because it is the permission tiers, the evidence trail, and the champions community from this chapter, applied unchanged. The job title changed. The discipline did not.
When the same governance model fits a software team, a legal department, and an operations group, you are not looking at an engineering tool rollout. You are looking at an organizational discipline for delegating work. Engineering got there first because coding agents matured there first, but nothing in the permission tiers, the evidence trail, or the champions community depends on code. They are how an enterprise extends trust to any new worker, and the same shape is already arriving in operations, finance, and compliance, anywhere work can be specified, delegated, and verified.
Why This Matters Now
Your enterprise does not need to invent governance for coding agents. It already owns the three assets this chapter describes: the identity discipline that scopes access, the audit discipline that produces evidence, and the change-management muscle that builds genuine adoption. The pair-plus-fleet team structure is simply how those three assets get put to work. All of it runs in production today, pointed at humans.
AOD is the crosswalk. It maps organizational discipline you already trust onto a new class of user, the way our Excel crosswalk mapped thousands of state employees into a few hundred security roles. Nobody designed that migration from a blank page. Nobody should design agent governance from one.
The timing matters because the questions are coming whether you prepare or not. Organizations that treat coding agents as ungoverned tools will reconstruct their evidence after the fact, under deadline, the way unprepared audits always go. Organizations that extend their existing discipline will already hold the answers when the questions arrive. The gap between those two postures is not budget or talent. It is the decision to treat coding agents as what they actually are, a new population of users entering systems your organization already knows how to govern.
What's Next
Chapter 21 continues Part IV, the book's Practical Wisdom arc, by mapping the harness landscape, the ecosystem of tools that has grown up to enforce the discipline this book describes, where AOD sits on that map, and where the field is heading next.
I keep returning to that first login. The wave of relief was real, but it was not luck, and it was not delivered by the technology. It was hundreds of people, a plan of more than 450 steps, and a few hundred carefully designed security roles paying off in one quiet moment. Every enterprise adopting coding agents today is writing its own version of that moment, whether it knows it or not. The preparation you do now decides whether it arrives as relief or as firefighting.