Team Topologies for AI Agents

Team Topologies was created to reduce cognitive load on human teams and help them deliver faster with clear boundaries.

But what happens when some of your team members are AI agents?

Most companies treat agents like faster developers. Give them a repo. Give them a task. Review the code. But agents do more than write code.

They:

• Make hidden design decisions
• Optimize only what they can see
• Ignore what is outside their context

That is exactly the kind of problem Team Topologies was built to solve.

The Four Team Types Revisited

Stream-aligned teams

In Team Topologies, stream-aligned teams are responsible for one product, one service, or one clear business domain.
Their goal is to deliver value end-to-end. They own features, changes, and outcomes in that stream.

Agents work best when scoped the same way. They can have clear ownership, clear boundaries. and clear goal.

Problems start when an agent reaches across domains that were never clearly separated.
If boundaries are fuzzy, the agent will blur them even more.

How to prevent it?
Define clear repo ownership, restrict cross-domain changes in CI, and scope agents technically to one bounded context at a time.

Platform teams

Platform teams build shared infrastructure, APIs, and internal services so other teams can move faster.

In the age of agents, this becomes critical. A strong platform team should provide:

• Clear internal APIs
• Machine-readable standards
• Architecture rules and proper Architecture decision records
• Security policies as code

If constraints are explicit, agents can follow them.

If not, they learn from random code patterns and scale the worst examples.

Practical advice:
Invest in clean APIs, OpenAPI specs, linters, and automated checks.

Enabling teams

Enabling teams help others improve practices and adopt new capabilities.

Now the question is: Who teaches the agents how your company builds software? Who defines:

• Architecture principles
• Integration rules
• Security standards?

If nobody owns this, the agent learns from whatever it finds.

What helps?
Create curated context packages for agents with proper skills. Provide approved examples. Treat agent onboarding like team onboarding.

Complicated subsystem teams

These teams own highly complex or sensitive parts of the system that require deep expertise. For example:

• Pricing logic
• Risk models
• Security modules

Not every part of your system should be open to autonomous modification.

Recommendation:
Mark critical areas clearly, require stricter review, and limit agent write access where risk is high.

Conway’s Law Still Applies

Conway’s Law says that systems mirror the structure of the organization that builds them.

And you can really see that with agents.

If your team boundaries are unclear, domains overlap, and ownership is fuzzy, the agent will reflect exactly that in the code. It simply copies the structure it sees.

An agent will not fix a messy organization.
It will just scale it faster.

So before adding more autonomy, it is worth taking an honest look at your team topology.

If you’re thinking about introducing AI agents into your engineering organization, don’t start with more prompts.

Start with structure.

I help teams design environments where agents work safely, stay within clear boundaries, and actually increase delivery speed instead of creating hidden chaos.

If you want agents to become a real multiplier for your software development, let’s talk.