What a Team
Looks Like When
Everyone Has Agents.

Large organizations are starting to give people agents. Product managers can turn rough notes into requirements. Engineers can assign an issue and receive a pull request. Designers can explore several directions before lunch. Risk and operations teams can analyze documents that would have taken days to work through manually.

Most of this is being introduced as productivity. The employee stays in the same role, the work moves through the same process, and an assistant helps each person finish their piece faster.

That is a reasonable place to start, but it also means we are building agents, skills, and frameworks around the way work happens today. I think we need to spend more time on a different question: what does the work look like when every person has a small team of agents doing much of the heavy lifting? The answer is probably not the same process moving at twice the speed.

The operating model changes when the agent stops being a better text box and starts becoming a participant in the work. It can gather evidence, use tools, make a plan, produce an artifact, run a test, respond to feedback, and continue while the person moves to something else. If every function can suddenly produce more, the institution also has to become better at deciding, reviewing, integrating, and releasing what gets produced.

I expect the product team to remain the center of that work. What changes is who, or what, is doing the execution around it. The future team begins to look less like a fixed group of people passing work between functions and more like a group of accountable people directing agents toward one shared outcome.

The Process We Have Was Designed for a Different Constraint

A traditional product operating model divides work among specialists and coordinates the handoffs. Product identifies the problem and writes requirements. Design creates the experience. Engineering implements it. Testing validates it. Security, legal, compliance, architecture, and operations review the parts that fall within their responsibility.

Agile improved this model by bringing people closer together, shortening the planning cycle, and giving teams a repeatable structure for shipping software. That structure made sense for the tools and constraints of the time. Specialist capacity was scarce, implementation took time, and work needed to be broken into pieces that people could estimate, assign, and track.

Agents change some of those constraints. A product manager can explore data, draft a requirement, create a prototype, test an API, and ask an agent to inspect a repository before an engineer has formally started. An engineer can delegate several bounded changes in parallel. A control partner can compare a proposed experience against policies and prior decisions before a scheduled review.

Expertise does not become less important. It gets used differently. Less time is needed to create a first version of something. More attention is needed to frame the problem, choose the evidence, set boundaries, compare the outputs, and decide what is good enough to move forward.

I can already see the tension at work. Controls partners are putting checks and processes in place for AI products, which is necessary. But much of that process is manual. Product teams fill out forms, update documents, wait for reviews, answer another round of questions, and repeat. As the number of AI features increases, the review capacity does not automatically increase with it. The process gets longer, and teams can become discouraged before they have enough evidence to know whether an idea is even useful.

This is close to the systems problem described in Google's 2025 DORA research. The research found that AI adoption was associated with stronger throughput and product performance, but could still reduce delivery stability when the surrounding delivery system was weak. Faster work in one part of the process does not help much if it creates a larger queue in the next part. The process itself has to absorb the new capacity.

The Team Becomes a Group of People Directing a Network of Agents

I still think the durable product team matters, especially inside a large institution. People need shared history, trust, customer understanding, and clear responsibility for an outcome. Agents expand what that team can do, but they do not replace the need for a team that understands why the work matters.

The future product team may be a relatively small group of accountable people surrounded by agents that can work across the product lifecycle. Some agents research. Some inspect customer feedback or operational data. Some maintain product context, turn decisions into specifications, create prototypes, write code, generate tests, prepare release evidence, or monitor what happens after launch.

I do not think every job title needs a matching digital employee. The more useful approach is to give agents clear jobs within the work. One might keep the product documentation current. Another might compare a proposed change with customer evidence. Another might create test cases or assemble the evidence needed for a control review. The human team decides how those pieces come together and whether they are moving the product in the right direction.

For this to work, the people and the agents have to be singing from the same sheet of music. They need the same view of the problem, the customer evidence, the decisions already made, the product documentation, the architecture, the policies, the current code, the evaluation criteria, and the state of the release. Without that shared context, each agent can produce work that looks reasonable on its own but does not fit with the rest of the product.

There also needs to be a person who owns the outcome. An agent can prepare a recommendation, implement a change, or run a test. A person still has to decide why the work matters, which tradeoff is acceptable, when an exception is justified, and whether the evidence is strong enough to proceed. Accountability cannot be delegated just because execution can be.

Anthropic's research on Claude Code offers an early clue about how this may work. In the sessions it studied, people made more of the decisions about what should be done, while the agent made more of the decisions about how to carry it out. I would not treat that split as permanent, but the direction makes sense to me. People spend more time setting direction, applying judgment, and checking the result. Agents do more of the steps required to get there.

The Roles Stay, but the Valuable Parts of Them Change

This changes the shape of product roles without making the roles meaningless. The work that becomes easier is often the work we currently use to show that work is happening: the document, the ticket, the first design, the first implementation, or the status update.

A product manager should not be valuable because only they can turn a meeting into a requirements document. Their value is in deciding which problem deserves attention, connecting evidence across customers and the business, making tradeoffs visible, defining what success means, and keeping the team pointed at an outcome when the work becomes messy.

An engineer should not be reduced to accepting agent-generated code. Engineering judgment moves up a level: system design, constraints, interfaces, failure modes, maintainability, security, and the evidence required before a change can be trusted. The merge decision becomes more important when producing another implementation becomes cheap.

Design changes too, and it is much broader than conversation design. People will interact with software through chat, voice, traditional interfaces, generated interfaces, and combinations that change based on the task. Designers will need to decide what the system should show, what it should generate, when it should ask instead of act, how its current state is made visible, and how someone recovers when it is wrong. A generated interface still needs a clear interaction model. It just may not be the same interface every time.

Control functions need to enter the work earlier as well. Today, reviewers often see the work after important choices have already hardened, and the team assembles the evidence near the end. Agents create an opportunity to generate policy checks, threat models, test evidence, model evaluations, data records, and decision logs while the product is being built. Review can happen while a decision is still easy to change.

The practical question for each role becomes simpler: what must a person decide, what can an agent do, what evidence should come back, and when must the work stop for review? Getting those boundaries clear will matter more than deciding which function owns each intermediate document.

The Institution Needs Common Rails and Room for Teams to Adapt

A large organization will be tempted to centralize this into a single enterprise assistant. One approved interface is easier to explain, fund, and govern. It is also unlikely to understand every product, workflow, policy, and customer well enough to do meaningful work across the institution.

The central platform should provide the common rails: identity, existing permissions, approved models, secure tool connections, logs, evaluations, cost controls, data protections, and a consistent way to require human approval. Product teams should be able to configure the context, workflows, tests, and escalation rules for the problems they actually understand.

There is a real balance here. If every team builds independently, the institution gets duplicated tools, uneven controls, and risk that is difficult to see. If everything is centralized, teams wait in another queue and the platform group becomes the bottleneck. The common platform has to make safe work easier without trying to design every use case itself.

A team should be able to start with an approved agent, connect it only to systems the team is already allowed to use, inspect what it does, and increase its permissions as the evidence improves. The controls should be part of the way the agent works. They should not depend on someone creating a separate packet after the useful work is already finished.

This is where NIST's AI Risk Management Framework is more useful than a passing reference to governance. Its four functions, Govern, Map, Measure, and Manage, describe ongoing work rather than a one-time approval. A team maps the use case and its possible harms, measures how the system behaves, manages the risks it finds, and keeps governance in place as the model, data, and workflow change. NIST's secure software guidance makes a similar point for development: secure practices belong inside the lifecycle. For an agent-enabled institution, the review process needs to operate at the same pace as the system it is reviewing.

The Cadence Shifts From Tracking Activity to Reviewing Evidence

A team with agents should not need more ceremonies to keep track of the extra work. It needs a better shared record of what changed.

The daily conversation becomes less about whether someone finished a document and more about what the system learned, which assumptions changed, what is blocked, where an agent exceeded its boundary, and which decision now requires a person. Planning becomes the act of defining outcomes, constraints, and evidence that agents and people can work against together.

Work can happen in parallel, but decisions still need order. An agent may explore several implementations while another checks policy implications and a third prepares test cases. That does not mean all three outputs should move forward. The team needs clear checkpoints where the evidence is compared and a person commits the product to the next state.

The operating model I can picture is a tighter loop between observation, decision, execution, validation, and learning. Agents do more of the movement inside that loop. People remain responsible for its direction and for the consequences when the product reaches the real world.

This changes the software development lifecycle as much as it changes the product team. Discovery produces context that agents can use. Requirements become living constraints rather than a handoff document. Code, tests, control evidence, and documentation develop together. Release readiness is based on evidence collected throughout the work instead of a scramble at the end.

That is a more meaningful change than faster requirements or faster code. The product team becomes a group of people who can turn judgment into tested action through agents, while still knowing exactly who is responsible for the result.