How to organize small teams working with AI agents

AI-assisted teams can cover more of a delivery workflow with fewer handoffs, but smaller is not the point. Ownership is.

An AWS re:Invent talk on team structures in an agentic world gave me a useful frame for this question. The talk proposes small pods of expert generalists supported by agents. I would not turn its team size into a staffing rule. My test is whether one pod can own a workflow, make the necessary decisions, and stay responsible after release.

Put one workflow on the table

Imagine a customer onboarding workflow that starts with a completed application and ends with an active account. Product defines the rules, design shapes the screens, engineers build the flow, security reviews it, and operations receives the incidents. That is one customer journey split across several queues.

Specialists bring depth, but every handoff can lose context and make the work wait. We accepted that cost because one person could not cover enough of the workflow.

Agents change how much ground a capable person can cover. An engineer does not become a designer or a security specialist, but first drafts, tests, and supporting analysis no longer need their own queue every time. Building the thing got cheap; judgment about what to build and whether the result is any good stayed scarce.

The first question is therefore not how many roles to remove. It is whether a small group can take responsibility for the whole onboarding outcome without hiding the same queues inside a smaller box.

Give the pod authority before cutting the team

Choose the smallest group that can own the workflow safely. For one workflow that may be three experienced people. For another it may require a specialist or a larger team.

Whatever the number, the pod needs one outcome, authority to change the workflow, access to the systems involved, and responsibility for what happens after release. If it must ask another team to approve every meaningful decision, it does not own the work.

Adapted from the team-shape comparison in the AWS re:Invent talk. I use it as an ownership model, not a fixed headcount.

Thoughtworks calls the people who can work this way expert generalists. Its Expert Generalists article describes curiosity, customer focus, strong fundamentals, and comfort working outside one specialist area. Agents extend their reach, but the person still has to choose the work, check the output, and know when a specialist is needed.

I would hire for range and judgment, not only experience with the current framework. Agents are useful for the repeated preparation I have argued they should take off your team, but they do not replace accountability.

Let operational needs shape the support

The real ownership test starts when onboarding breaks in production. A pod that built the flow already understands its rules, tools, data, and limits. A separate operations team first has to rebuild that context.

I would default to build it, run it for agent systems, then test whether it works. DORA currently measures change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. A smaller pod is useful only if the delivery and operational results improve.

Separate build and run responsibilities may still be required. Make that boundary explicit and give both sides enough access and context to investigate problems. Add shared support when several pods repeatedly solve the same supporting problem. Keep it as a service to the pods, not another approval gate.

These operating choices are adapted from the AWS re:Invent framework. The right one depends on the responsibility the pod can safely hold.

Do not spend the talent pipeline

Small senior pods have one serious limit. They do not develop junior people by themselves.

Senior people built judgment through practical work and review. If agents take over much of the work that used to provide that practice, companies need another route for juniors to gain experience. Anthropic's labor-market research found suggestive evidence of slower hiring for younger workers in highly exposed occupations. AWS CEO Matt Garman has also argued that companies should keep hiring graduates, as removing junior roles weakens the future senior talent pool.

The pod is one delivery shape, not a template for the whole company. Use senior-heavy pods where they fit, and keep a deliberate path for practical work, review, and progression.

Use an ownership test, not an org chart

Return to the hypothetical onboarding workflow. Can the pod change the rules and the implementation? Can it resolve an incident without waiting for a new queue? Does it control one customer outcome, rather than a list of steps owned elsewhere?

If the answers are yes, a smaller AI-assisted pod may work. If not, shrinking the team will not remove the handoffs. It will only make them harder to see.

Sources

• A leader's guide to advanced team structures in an agentic world, AWS Events. Provides the attributed starting point for the small-pod and expert-generalist model adapted in this article.
• Expert Generalists, Thoughtworks. Defines the breadth, depth, curiosity, and customer focus behind the role.
• DORA's software delivery performance metrics, DORA. Defines the five current delivery metrics named in the article.
• Labor market impacts of AI: A new measure and early evidence, Anthropic. Reports no systematic rise in unemployment alongside suggestive evidence of slower hiring for younger workers in AI-exposed roles.
• AWS CEO Matt Garman Doesn't Think AI Should Replace Junior Devs, WIRED. Records Garman's argument that removing junior roles would weaken the future talent pipeline.