The Agentic AI Team - The Empty Column

[yoramfriedman]

The Empty Column

Post 7, The Agentic AI Team series

---

Take any team that ships an agentic product and ask them to draw their team structure on a whiteboard. They will draw it fast, because they have drawn it a hundred times before. A product manager decides what to build. An architect decides how it fits together. Engineers build it. Operations runs it once it ships. Four boxes, one arrow running left to right, and everyone in the room nods, because that is what a software team has looked like for twenty years.

The drawing is not wrong. That is the uncomfortable part. It is just incomplete in a way nobody in the room can see, because the model they drew was built for a different kind of product than the one they are now shipping, and the model does not know it is missing anything.

The old model is not the problem

It is worth saying plainly: the product manager, architect, engineer, operations lineup is a good model. It did not become good by accident. It maps cleanly onto the work of building something, deciding intent, shaping structure, constructing it, running it, and every team that has ever shipped software has run some version of that sequence. Two decades of reorganizations added seats to it, never replaced it. That durability is earned.

So this is not an argument that the model is broken or that the roles in it are obsolete. It is an argument that the model was built to staff one pipeline, and an agentic product needs two.

A grid, not a row

Picture the same four stages, intent, structure, build, operate, as a row across the top of a grid. That row is what the old model staffs, and it staffs it well. Now add a second row beneath it, because an agentic product is not one thing to build. It is two.

The first row builds the agent: what it should do, how it should be shaped, its components, running it as a live service. The second row supervises the agent: what has to be true before anyone trusts it, how the supervision itself is structured and enforced, the guardrails and instruments and recovery paths, and the ongoing work of watching it once it is live and stopping it when it drifts.

Call the first row Channel 1 and the second Channel 2. Draw them together and you get a grid: two rows, four columns, eight cells. Every cell is a piece of work that either has an owner on your team or does not.

Here is what that grid looks like, in the plainest form:

  Intent Structure Build Operate

Channel 1 (build it)	what it's for	how it's shaped	the components	run it as a service
Channel 2 (supervise it)	what must be true to trust it	what gets enforced vs. requested	guardrails, instruments, recovery	watch it, stop it, recover it

Fill in the top row on almost any team and it fills in fast, because that row is the work everyone already knows how to divide. Fill in the bottom row, and watch what happens.

The column that comes up empty

Run this exercise on a real team, without flattering the results, and the pattern is not subtle. Ask who owns deciding what must be true before this agent is trusted, and the answer is usually the product manager, halfway, because nobody else has claimed it and the trust conditions touch drift, correctness, enforcement, and recovery all at once, more ground than one role can watch alone.

Ask who owns deciding which guarantees are hard walls the system physically cannot cross, versus soft instructions the agent is merely asked to follow. That one belongs to the architect, in principle. In practice it is frequently a decision nobody made explicitly, so the system defaults to whichever is easier to build, which is usually the soft version.

Ask who builds the guardrails, the monitoring, the path back when something goes wrong. Ownership here tends to be split across an architect and an operations function, each assuming the other has it further covered than they do.

And ask who owns watching the thing once it runs, on a standing basis, day after day, this is the cell that comes up blank most often. Not thinly staffed. Blank. There is a well-understood job description and a market rate for the engineer who builds an agent. There is rarely an equivalent for the person whose job is to watch it run.

Put the two rows side by side and the shape is consistent across teams: a full top row and a bottom row that is half-staffed at best, with the rightmost cell, ongoing supervision, empty more often than not.

Where the money actually gets lost

The empty column would be a tolerable inefficiency if the failures it produces were minor. They are not, and the reason is that the costliest agentic failures rarely live inside a single cell. They live in the seam between two cells, in the hand-off where one person's job ends and nobody has confirmed whose job starts next.

Here is the shape of it, stripped of any particular vendor or system. A product manager specifies a boundary: this agent may act on its own up to a certain point, and beyond that point it must stop and ask. That is an intent-level decision, a Channel 2 cell. Somewhere downstream, an engineer builds the agent to operate inside that boundary, a Channel 1 cell. The two cells look adjacent on the grid. They are not the same cell, and the confirmation that the boundary was actually built as a hard stop, not just described in a document, is a separate piece of work that sits in the seam between them.

On a team without a named owner for that seam, everyone can be doing their job correctly and the boundary still doesn't hold. The product manager wrote the specification. The engineer built to the specification as understood. The gap is the part that was never anyone's explicit responsibility: verifying that what was specified is what got enforced. When that agent later takes an action past the line it was supposed to respect, the postmortem finds three people who each did their part and no one who owned the connection between the parts.

That is not a hypothetical edge case. It is the general shape of how agentic failures happen, because an agent that decides and acts on its own, rather than following a fixed set of rules, will eventually meet a situation the specification did not anticipate, and what happens next depends entirely on whether the hand-offs around it were owned or assumed.

Why the column stays empty

It is tempting to treat this as a staffing gap, the kind of thing solved by posting one more job requisition. That undersells what is actually missing.

The old model knows how to add a seat. Across a generation of reorganizations it absorbed new kinds of judgment one chair at a time, and each addition slotted into the existing row without disturbing it. Channel 2 is not one more chair in that row. It is an entire second row, with its own intent, its own structure, its own build, its own operate. You cannot hire a second pipeline the way you hire a fourth teammate, because a pipeline first has to be recognized as existing before anyone can be assigned to own a piece of it.

That is the honest answer to why the column stays empty even on capable, well-resourced teams. They are staffing the model they can see. The model they can see has one row. The second row is not being neglected; it is invisible to a picture of the work that never had a place for it. You do not forget to fill a cell you can see sitting empty. You fail to fill a cell your map of the work never drew.

Drawing the grid on your own product

Here is the exercise, and any team can run it in an hour with nothing more than a whiteboard and the willingness to be honest about the answers. Draw the two rows and four columns. For each of the top-row cells, write the name of the person who owns it. For each of the bottom-row cells, do the same.

Most teams get through the top row without hesitation. The bottom row is where the conversation slows down, and the slowing down is the finding. Someone will say "I think that's on the platform team," and someone else will say "I thought that was yours," and that exchange, uncomfortable as it is in the room, is worth more than the exercise that produced it, because it surfaces the assumed owner before an incident does it for you.

Then go one step further and ask, for every boundary between a top-row cell and its corresponding bottom-row cell, who confirms the hand-off actually happened. Not who is responsible for the work on either side. Who checks that what one side specified is what the other side built. That question, asked out loud in a room, is usually the first time anyone has asked it.

What the empty cell is quietly waiting for

None of this requires abandoning the team you have. The product manager, architect, engineer, and operations lead are not being replaced by this grid. They are being asked to notice that a second set of questions has been sitting next to their familiar ones the entire time, unassigned, waiting for someone to claim it.

The grid does not tell you who those people should be. It only tells you that the cells exist, whether or not anyone is sitting in them. A team that draws the grid without flinching and finds its bottom row empty has not discovered a flaw in its people. It has discovered the shape of the work it has been doing without realizing half of it was still undone, and the next question, the one that actually decides whether the empty column gets filled or stays that way through the next incident, is who in the room is willing to say the cell is theirs.

---

This post is part of The Agentic AI Team series on SAP Community, adapted from the book "The Agentic AI Team," which examines how the software team reshapes around runtime ownership when the product decides and acts on its own. The full framework, including the collaboration grid and the hand-offs where agentic products actually fail, is at agenticaiproductmanagement.com.