In the first article of this series, I made the argument that when agentic execution takes over the middle of the delivery system, the quality of what goes in becomes the single highest leverage point. The input layer is everything. The natural next question in that argument is the one this article is built around: if execution is automating, what does the team that produces those inputs actually look like? How small can it get before it becomes fragile? And what does each person on that team actually do?
Teams are shrinking, but not disappearing
The agentic shift is compressing team size. The monitoring, facilitation, and administrative overhead that justified larger teams is automating. Organizations that were running scrum or Kanban teams of six, eight, ten people are starting to ask whether they need that many people anymore.
The honest answer is: probably not. But smaller is not arbitrarily better. And there is a floor below which team composition becomes fragile regardless of how capable the agentic stack is.
That floor is not a fixed number. It is a capability threshold.
The minimum viable team size is determined by the knowledge distribution across the team, not by headcount alone. A team of ten with knowledge concentrated in two people is more fragile than a team of four where knowledge is distributed evenly. The agentic stack doesn’t change that math. It sharpens it.
Why five works when three doesn’t, yet
Three people can work. But only under a very specific and rare condition: full parity of knowledge across all three members. Every person on that team can cover for every other person, technically and from a product perspective. If one person is out, the team doesn’t stall. If one person leaves, the team doesn’t lose a capability it can’t replace.
That configuration exists. In fully agentic greenfield organizations, with the right investment in the harness and the right cultivation of capability over time, three person teams with that kind of parity become achievable. That’s the direction this is heading and I’ll come back to it at the end of this article.
But in most organizations today, that level of parity is the exception, not the rule. Specialization has deepened, not narrowed. Front end and back end are increasingly distinct disciplines. Product knowledge lives in different people than engineering knowledge. T-shaped practitioners exist but true full-stack-plus-product parity across an entire team is rare.
Five gives you resilience without requiring that level of parity. You have enough redundancy to absorb normal human variability, illness, turnover, context-switching, without needing everyone to be a complete generalist. Five is the practical floor for most real-world organizations in the transition period we are actually in.
The transitional team you already have
What makes five workable as a starting point is something organizations are discovering as they move into this transition: it maps almost exactly onto roles that already exist in most agile delivery organizations.
A flow enabler. A product owner. Three engineers.
The agentic shift doesn’t blow that structure up. It compresses it and evolves what each role does inside it. Organizations navigating this well aren’t redesigning their org charts from scratch. They’re recognizing that the team shape they already have is the right starting point, and that the work is evolving capability inside those roles rather than replacing them.
The scrum master or agile coach moving toward the flow enabler identity is still the person who helps the team resolve ambiguity, navigate conflict, and advocate for best practices, whether that’s within the agentic harness or on the team itself. What shifts is how much of their presence any single team requires over time. More on that in a moment.
The product owner is still the person carrying the product input layer, the market judgment, the prioritization calls, the stakeholder relationships. What shifts is that the harness absorbs a meaningful portion of the low level administrative and market signal work that used to consume significant PO hours. Backlog mechanics, usage data aggregation, adoption tracking. The harness surfaces that signal. The PO interprets it and decides what to do with it.
The engineers are still writing code, reviewing outputs, making technical decisions. What shifts is the nature of what they’re working with and the inputs they’re responsible for generating.
The flow enabler’s presence follows team maturity
Here is where the headcount question gets complicated, and where I want to be direct about something most frameworks gloss over.
In the early stages of this transition, the flow enabler is embedded. They are counted as part of the team. They need to be. A team that is just beginning to work in an agentic model needs more support, not less. The harness is being built. Practices are being established. The human coordination work is at its highest volume precisely because everything is new and the team hasn’t yet developed the muscle memory to operate without frequent guidance.
This is the same principle behind any maturity model. Coaching intensity is highest when the team is newest to the work, and it decreases naturally as the team develops capability and the harness absorbs more of the monitoring and facilitation load.
As the team matures, something interesting happens. The flow enabler finds themselves needed less on any given team, not because coaching becomes less important but because the team has internalized the practices and the harness is carrying the detection and facilitation work that used to require constant presence. That creates capacity headroom the traditional scrum master role never had. And that headroom allows the flow enabler to support more teams.
This isn’t a cost-cutting argument. It is a natural consequence of the role evolving. The value the flow enabler delivers is no longer measured by hours present in ceremonies. It is measured by the quality of the systems they’ve built and the speed at which they can show up and resolve the things those systems can’t handle: ambiguity, conflict, the judgment calls that require a human in the room.
The org chart catches up to this reality on its own. You don’t have to decide upfront whether the flow enabler is on the team or adjacent to it. In the early transition, they’re on it. As the model matures, they distribute. The answer changes with the team’s maturity, which is exactly how it should work.
The PO doesn’t get the same distance
It’s worth being explicit about one important asymmetry in this model.
The flow enabler gains scalability as the team matures. The product owner does not, at least not in the same way or on the same timeline.
Product judgment, market signal interpretation, and prioritization calls are harder to delegate to the agentic stack in the near term. The harness can surface data. It can’t weigh competing stakeholder priorities, read organizational politics, or make the call about which bet is worth taking when two reasonable options are in front of you. Not yet. That work stays human and it stays close to the team.
The PO gets relief from administrative burden. They don’t get distance. They carry more weight in fewer hours, which is a different kind of evolution than the flow enabler experiences. Both roles are evolving, but in different directions.
The engineering champion: local knowledge on every team
As the flow enabler scales across multiple teams, something else becomes necessary. They can’t be the sole carrier of embedded coaching knowledge on each team. There has to be someone inside the engineering team who holds that knowledge locally.
Not a full coach. Not a manager. Someone with enough pattern recognition and enough trust from the team to be the first line of signal interpretation when something is off. The person who notices that the acceptance criteria in today’s refinement are drifting toward technical compliance rather than outcome thinking, and says something about it before the story goes to execution.
What emerges in organizations that are doing this well is a deliberate knowledge transfer from the flow enabler to that person. Not a formal coaching engagement. An ongoing relationship where pattern recognition gets encoded locally, and the flow enabler maintains that relationship as a quality check rather than a constant presence. The flow enabler’s scalability is partly a function of how well that local knowledge carrier has been developed on each team they support.
The north star: the product engineer
The engineering champion concept has a destination.
The organizations thinking most clearly about this are asking a specific question about every team they have: who on this team is developing toward the intersection of front end, back end, and product knowledge? Someone who can construct inputs to the agentic stack that are simultaneously technically precise and outcome-oriented. Someone who understands the user, understands the system, and can translate between them without a human translation layer in between.
That person is what I’d call the product engineer. Not the narrow technical role the market has been using that term for. A practitioner with full stack capability combined with genuine product and market understanding. The unicorn that makes the three person team viable. Rare today. Worth cultivating deliberately.
The distinction worth noting: the product engineer is not a role you staff from outside. It is a capability that emerges from within. Some organizations are being pitched models that treat this as a standalone dedicated hire. That approach adds headcount, creates dependency on a single person, and doesn’t address the knowledge distribution problem at its root. Growing this capability inside existing team members compounds over time.
The engineering champion is the intermediate step. The product engineer is the destination.
Where this is heading
Most organizations are going to spend the immeadiate future in the transition state: five person teams, T-shaped engineers, a PO staying close to the team, a flow enabler whose presence decreases as team maturity increases. That is the practical reality for enterprise organizations at scale and there is nothing wrong with operating there. It’s the right configuration for where most teams actually are.
The three person team with full knowledge parity is the future state. Fully agentic organizations with mature harnesses and deliberately cultivated product engineers will get there. It will take time, investment, and a clear-eyed view of what the harness needs to carry for that configuration to be resilient.
The north star is worth naming now so that the decisions being made in the transition state are building toward it rather than away from it. Every T-shaped engineer developed, every engineering champion cultivated, every harness capability added is a step toward a team that can operate with fewer people and more leverage.
Five is the floor. Three is the horizon.
This is the second article in The Agentic Reality Series. It builds on The Input Layer is Everything. The white paper, The Living Product, describes where agentic delivery is heading. This series fills the gap between that destination and where organizations are today. Next: The Coach Who Builds, on what the flow enabler role actually requires in practice and what coaches need to develop to get there.
