The Model Is Old. The Column Is New.

The last part ended on convergence: every craft migrating to the same posture, judgment over production. This part opens on something that sounds like its opposite, the team adding owners rather than collapsing into one, and the two only seem to disagree. The crafts converge on the posture; the team still has to divide the work, because the objects that judgment acts on stay distinct and the supervision failures live in the seams between them. Convergence of posture, division of labor: that is the whole move, and it is why this part is about a model that grows rather than a model that is replaced.

The collaboration model is not new. The way responsibility sorts across a software team, who decides, who shapes, who builds, who runs, is decades old, and across twenty years of reorganizations I watched that shape add seats and never once replace itself. The agentic shift did not invent the model and is not replacing it, and anyone who tells you the agentic era requires a brand-new operating model is selling the thing the most credible voices in the field explicitly refuse to sell: the people who built the dominant framework for organizing software teams have said plainly that AI does not need new team types, that the existing structures are the right foundation. They are correct, and a book that opened by announcing a revolution in the model would lose its most informed readers in the first paragraph. How the model grows to absorb the new work, seat by seat and stage by stage, is the subject of a later part; what this one needs is narrower, the picture of the work itself that shows where the new seats have to go.

What changed is not the model. It is that the agentic product added a second pipeline the old model never had to staff, and the old model has no chair for a pipeline.

Two pipelines, four transformations

Here is the structure the rest of this part hangs on, and it is worth drawing carefully because it organizes everything the previous part showed you in pieces.

The work of building a software product is four transformations in sequence. Intent comes first: deciding what should exist and why. Then structure: deciding how it should be shaped, what fits the existing system, what the architecture must be. Then build: making the thing. Then operate: running it once it is live. Every team that has ever shipped software ran those four transformations, and the collaboration model is just the question of who owns each one. The product manager has tended to own intent, the architect structure, the engineers build, operations the running. That row, intent to structure to build to operate, is the model that has been stable for twenty years, and it is the model that is correctly described as old.

Now lay a second row beneath it, because the agentic product has two of these pipelines, not one. The first pipeline builds the agent: intent for what the agent should do, structure for how the agent is shaped, build for the agent’s components, operate for running the agent as a service. That pipeline is the one every team knows, the old model applied to a new kind of artifact. The second pipeline is different in kind. It is the pipeline that supervises the running agent: intent for what must be true to trust the agent, structure for how the supervision is shaped and what gets physically enforced versus merely requested, build for the guardrails and the instruments and the recovery paths, operate for watching the agent and stopping it when it goes wrong. Call the first pipeline Channel 1, building the agent, and the second Channel 2, supervising it, the two channels this book has used from its first pages. The collaboration model of an agentic product is not a row. It is a grid: four transformations across, two channels down, eight cells, and every cell is a responsibility that some person on the team either owns or does not.

The grid is not a new operating model. It is the old operating model, drawn twice, because the agentic product is two products, and the second drawing is the one the team forgot to staff. Every cell in the Channel 1 row has an obvious owner, because building the thing is the work every team already knows how to divide. The product manager has an intent cell, the architect a structure cell, the engineers a build cell, operations a run cell. Fill in that top row on any real team and it fills in easily, because it is the row the team was built for. Then try to fill in the bottom row, and watch what happens.

The column that comes up empty

Channel 2’s column is where the chairs are missing, and it is missing in a way that is visible in the data, not just in the argument.

Who owns the intent of Channel 2, deciding what must be true for the running agent to be trusted? On most teams the product manager half-owns it, because the previous part of this book showed that this is where the prior framing left it, and the previous part also showed why that is not enough, because the trust conditions span drift and enforcement and correctness and recovery, which no single person can see. Who owns the structure of Channel 2, the decision about which guarantees are physically enforced walls and which are requests in a prompt? That is the architect’s, and most teams have an architect, but the previous part showed that the boundary the product manager specifies and the wall the architect builds are two different things with an open seam between them. Who owns the build of Channel 2, the guardrails and the six instruments and the recovery paths? Partly the architect, partly an operations function, and the previous part showed the instruments going unbuilt because the responsibility was smeared across three roles each assuming another held it. And who owns the operation of Channel 2, the standing job of watching the running agent and stopping it? That is the agent supervisor, the AgentOps role, and here the data is blunt: it is not a staffed role on most teams. A large share of deployed agentic systems run with no production observability at all. There is a salary band for the engineer who builds the agent and no established one for the person who operates its supervision. Responsibility for the running agent is, in the field’s own descriptions, distributed across security and platform and engineering in a way that means no one is accountable for it. The industry named the shift out loud: this is the year, one of the large vendors wrote, that companies stop building agents and start running them, which is an admission that the running, the entire Channel 2 operate cell, was the part nobody had staffed.

So the grid, filled in truthfully on a typical team, has a full top row and a bottom row that is half-empty, with the rightmost cell, operate the supervision, simply blank. That blank cell is the literal picture of every failure the last part walked through. Silent degradation lived in the blank operate cell and the smeared build cell, because no one owned watching the agent across time. The nine-second deletion lived in the open seam between the Channel 2 structure cell, the wall, and the Channel 1 intent cell, the agent’s job, because the boundary was decided and never enforced. The green checkmark lived in the Channel 2 intent and build cells, what must be true and who keeps the golden dataset honest, because no one owned the trust condition. The runaway loop lived in the blank operate cell, because no one owned the burn-rate seat. Every seam in the previous part is a hand-off across this grid, and every empty owner is a cell in the Channel 2 column. The previous part gave you the failures one at a time. This is the structure they were instances of.

There is one corner of this column where someone is, in fact, already doing the work, and naming it now keeps it from later looking like a contradiction. On engineering teams using coding agents, the engineer has quietly started supervising one: reading what the agent generated, catching where it drifted, holding the boundary on what it is allowed to touch. That is real Channel 2 work, performed today, and a later part of this book makes the engineer the existence proof that the supervisory posture is learnable, because someone is living it. But notice exactly what it is and is not. It is an individual improvising supervision over the agent that helps build the product, out of necessity, with no title and no mandate and no one having staffed it as a job. It is not the organization owning supervision of the business agent it ships to customers, which is the column this grid is about. The engineer supervising their coding agent proves the work is doable; it does not prove the work is staffed. The column is not empty because the skill does not exist. It is empty because the skill exists in one corner, unnamed and unbudgeted, and the organization has not yet recognized it as a seat that the rest of the agentic product needs filled. Grassroots improvisation by one role is not an operating model, and mistaking the first for the second is how a team concludes it has solved a problem it has merely gotten lucky with so far.

Why the column is empty, and why a chair will not fill it

It would be easy to read all this as a staffing oversight, the kind of thing a team fixes by hiring an AgentOps engineer and moving on, and that reading is wrong in an instructive way. The Channel 2 column is not empty because teams forgot a hire. It is empty because the old model adds chairs, and Channel 2 is not a chair. It is a whole pipeline.

Look again at the career arc, because it is the tell. Two in a box became a trio became four in a box, and each step added a seat, a single new kind of judgment, a person. The model knows how to absorb a new chair; it has done it repeatedly, and the addition of business or design as a fourth seat did not strain it, because a seat slots into the existing row. You can hire one more person and seat them at the table without anyone noticing the table got bigger. But Channel 2 is not one more seat in the existing row. It is a second row, a parallel pipeline with its own intent and structure and build and operate, and you cannot hire a second pipeline the way you hire a fourth chair. A pipeline has to be recognized as existing before anyone can be assigned to it, and the old model, which sees the work as one row, does not have a place in its picture for a second one. That is why the column comes up empty even on teams that are not negligent and not understaffed. They are staffing the model they can see, and the model they can see has one pipeline, and the second pipeline is invisible to it precisely because the model never had a row for it. You do not forget to fill a cell you can see is empty. You fail to fill a cell that your picture of the work does not contain.

This is the difference between the agentic shift and every prior reorganization. The earlier additions, two to three to four in a box, were the model recognizing it needed one more kind of judgment and adding it. The agentic shift is not asking for one more kind of judgment. It is asking the team to staff a second pipeline the one-pipeline model has no way to see, and the teams that fail are not failing to hire. They are failing to redraw the picture, and you cannot staff a row you have not drawn.

The conversation that keeps the column empty

There is a second reason the column stays empty, and it is not structural but social, and it is worth naming because it is the harder of the two to fix. The people most loudly describing the agentic team are doing it inside a closed loop. There is a large and growing conversation about the product manager in the agentic era, the product manager as the center of the new team, the product manager who can finally build the thing alone by vibing it into existence, the product manager as the hero of the agentic product. It is an energetic conversation and some of it is insightful, and it has one defining property: it happens almost entirely among product managers, talking to other product managers, on the channels product managers read. The engineers and the designers and the architects it describes are not in it. They are not writing it and they are not reading it, and so the discourse circulates among the people who already agree with it and never reaches the people whose cooperation it would need to be true.

That closed loop is part of why the supervision column stays empty, and the mechanism runs through an old tension. The relationship between the product manager and the engineer has always carried a power struggle, who has the final call, who depends on whom, whose judgment wins when they disagree. It is not abstract; it is the daily texture of the box. And the hero discourse pours fuel on it, because the product manager who announces that they can now build the product themselves, that the engineer’s hard part has been automated and the product manager is the one who remains, has said the single most reliable thing for making an engineer stop listening. So the conversation that is supposed to be redrawing the team is, in practice, widening the rift inside it. The more the product manager is celebrated as the center, the more the rest of the box tunes the celebration out, and the cross-role agreement that staffing the second pipeline actually requires, the architect agreeing to own enforcement, the engineer agreeing the supervision is real work, becomes harder to reach, not easier. A team cannot staff a pipeline its members are too busy contesting status to draw together.

The antidote is the thing this whole part is built on, and it is why the grid and not a ranking of roles is the right tool. A grid of responsibilities derived from the work does not say who is the hero. It says here is the work, and here is who owns each piece of it, and it grounds every seat in a cell of the actual labor rather than in a claim of centrality. The architect is not in the picture because architects deserve standing; the architect is in the picture because someone has to own whether the boundary the product manager specified is actually enforced, and that is work, and it belongs to neither the product manager nor the engineer. Staffed from the work, the question stops being who matters most and becomes who owns this cell, which is a question a team can answer without a fight, because it is about responsibility and not rank. The empty column is, in the end, a refusal to draw the picture together, and the discourse that turns the drawing into a contest over who is central is making the refusal more likely, one triumphant post about the heroic product manager at a time.

The methodology that built one pipeline beautifully

The clearest evidence that the field has the same blind spot is the most advanced thing the field has produced, and it is worth looking at directly, because it is not a strawman, it is a serious and well-built piece of work, and that is what makes it the right foil.

Amazon Web Services published a full AI-native development methodology, its AI-Driven Development Lifecycle, a careful and well-argued reimagining of how a team builds software with agents at the center. It is right about a great deal. It correctly observes that the sprint’s cadence broke and renames it. It correctly pulls the up-front design disciplines back into the core. It is built around stating intent and decomposing it under human validation, which is the planning discipline this book keeps insisting on. As an account of how a team builds an agent, it is the best articulation available, and I do not want to damn it, because the parts it gets right it gets right.

But read its structure against the grid and the blind spot is exact. Its phases run from intent to construction to operations, which is Channel 1’s row, drawn well, intent and structure and build and operate for building the agent. And its operations phase, the rightmost cell, is about keeping the service healthy: telemetry, anomaly detection, deployment, scaling. It watches whether the agent is up, not whether the agent is still right. There is nothing in it about the agent’s behavior drifting over months, nothing about the golden dataset aging, nothing about the supervisor eroding, nothing about who watches the watcher. Its entire treatment of human oversight is a single recurring assertion that humans validate the critical decisions, stated as if oversight were a settled primitive rather than the hard, eroding, distributed thing the last part spent six chapters showing it to be. And its founding principle is role convergence: developers transcend the old silos, the methodology says, reducing the need for specialized roles, keeping the team minimal. That principle is correct for Channel 1. Collapsing the build roles, letting one fluent engineer span what used to be infrastructure and front end and back end, is exactly the right move for building the agent fast. And it is the precise opposite of what Channel 2 needs, which is role proliferation, the architect and the eval owner and the supervisor and the domain expert, because the supervision failures are distributed and no converged generalist can see all of them at once.

And it is not only the methodologies. Look at how the best teams in the field hire for the agentic product manager, and the same column is empty in the same way. A director at one of the major labs published the characteristics she looks for in an AI product manager, and they are a thoughtful and demanding list: product taste, systems thinking, the instinct to de-risk a bet, deep hands-on intuition for how the models behave. Read against the foundations of this book, the list is correct, it is the judgment-over-production shift stated as a hiring bar, from someone hiring at the frontier. And read against the grid, it describes a magnificent Channel 1 product manager and names no one else. Six characteristics for the one seat, and not a word about who owns whether the boundary is enforced, who keeps the eval honest, who watches the running agent. The interview questions that go with the list are all Channel 1: pitch the vision, survive the commoditization, deconstruct the system, spot the undervalued feature, build the narrative. None of them ask who supervises the thing once it ships. The hiring bar and the methodology are the same omission from two different directions, and the labor market completes the picture: the product-manager role at these labs commands compensation that has become its own headline, while the roles that own the supervision column do not yet have an established price, because the field has not yet fully admitted they are jobs. When the most advanced methodology, the most thoughtful hiring bar, and the salary survey all describe Channel 1 in loving detail and leave Channel 2 a single word or a blank, the omission has stopped being any one team’s oversight and become the field’s, which is exactly the evidence that the empty column is structural and not a failure of attention.

The methodology is a document and the hiring bar is a job post, but the field has gone further than either: it has started rebuilding the org chart itself, and the new chart has the same hole. In 2026 the largest technology companies began reorganizing into what the industry now calls the AI pod, a small, capability-organized team, leaner and more senior, with new titles like AI builder and AI pod lead, the production work handed to the agent and the humans pushed up toward judgment. Meta restructured its labs this way and cut thousands of roles to get there; others followed under their own names. The consultancies productized it, an AI pod you can buy by the sprint. And as a way to build conventional software faster, it is, like the AWS method, largely right. Collapse the build roles, let a senior generalist direct the agent, ship leaner. For the first of the two things this book separated, building a familiar product with AI in the workshop, the pod is a good answer, and I do not want to wave that away. But every public version of it describes the same row of the grid and stops. The pod is organized around capabilities and throughput; its human-in-the-loop is a step in the build, did the agent write good code, not a standing watch on a shipped agent deciding for a claimant six months later. None of these models names the autonomy boundary, the eroding supervisor, or the person on the receiving end, because the pod was designed for products that do not act on their own after they ship, and it is being applied, increasingly, to products that do.

That application is a quiet and expensive bet, and it is worth naming because the people making it cannot see the bill yet. A pod is the right team low on the autonomy ladder, where the agent suggests and drafts and a human commits, and the failures are recoverable by construction. The trouble is that no product stays there; the whole direction of travel is up the ladder, toward agents that act, and the judgment a company cuts when it trims to a lean pod, who decides whether the agent should have acted, whether it is drifting, whether it is safe for the person it will never meet, is exactly the judgment the higher rungs demand more of, not less. The cut looks brilliant while the products sit low, because the dashboards improve and the team is cheaper, and it reveals itself only later, on the night a shipped agent is quietly wrong at scale and the most experienced person who could have seen it was let go two quarters ago because the agent made them look optional. Some organizations sense the gap and try to fill it with a separate risk or safety or governance team bolted on beside the pod. It helps less than it looks, because a supervisor given a mandate but no authority, sitting outside the pod’s charter, is watching from across the room, and supervision that cannot stop the agent is not supervision. It is commentary. The grid is not satisfied by adding a chair labeled oversight. It is satisfied only when the supervision column is owned, inside the team, by people with the standing to act.

That is the foil, and it resolves into a single line that is also this book’s structural claim. The most advanced methodology in the field is a Channel 1 masterpiece that calls Channel 2 “oversight” in one bullet and walks away. It is right that the build pipeline should converge its roles and move fast. It is silent on the supervision pipeline, which must proliferate roles and watch slowly, because it cannot see that the supervision pipeline is a separate pipeline at all. Merge to decide, separate to ship: collapse the roles that build the agent, and separate the roles that supervise it, and the methodology that does the first while forgetting the second is the whole industry’s blind spot rendered as a polished diagram. The rest of this part is about the second pipeline, the one the diagram is missing, and about the hand-offs inside it where the work the last part documented fails.