This post started as an idea, and ended as a thought experiment. I don’t think is a sensible end-goal, and I will provide some reasons at the end. But I found a thread to pull, and I wanted to see how far it took me.
I am a big fan of the Team Topologies book, so it was the obvious framework for thinking about taking AI beyond simply using Claude in your IDE. I have no idea if AI will steal our jobs, or implode. My guess is neither. And none of what I’m talking about has been tried out (by me, at least). But I am interested in thinking about how AI may change not just how individual developers work, but how teams function.
First I want to outline some key features of what I shall call an agent centric topology.
Features of agent centric topologies 🔗
An Agent centric Topology is a set of teams organized in a way that let’s AI perform a majority of the development, without the need for human babysitting. Key features are:
- Teams are preferably value stream aligned, and have defined interaction points with other teams that they request or provide services from.
- Teams are shaped by the logical business value streams, total complexity and desired team size.
- Agents start work without being prompted by a developer.
- Work happens on cloud servers, as opposed to developer laptops.
- New features are tested in isolated environments
- Rules and principles for security, architecture, maintainability etc are enforced by agents.
- The team members’ main focus is on improving workflows and minimizing the number of human interventions needed in the process from feature request to deployed feature.
- The team remains responsible for their output - delegation of work to Agents does not mean delegation of responsibility.
With these goals in mind, what changes are afoot?
New ways of working 🔗
Team APIs must be real APIs 🔗
In agent-centric topologies, other teams make requests through channels that agents can access. Whether this is Jira tickets, Github issues, Slack, email or all of the above doesn’t matter, but there needs to be an API and the agents need to be able to authenticate.
Documentation as the main steering mechanism 🔗
Agent centric teams must be able to articulate their standards and principles, so that agents can follow them. They also need processes in place to monitor compliance with these principles, and refine their documentation and instructions in order to improve compliance. Code that breaks the development principles waste tokens, and if the error is not caught during automated review, also wastes human time.
QA as the primary control mechanism 🔗
A core principle is that the user (user, in the sense of anyone that has made a request to the team) makes the request and the user approves the new feature. In order for this to happen, a dedicated QA environment must exist where the user can evaluate the result of the proposed changes.
The team may want to review the result as well, but this should not be a requirement. The team’s main focus is to increase the efficiency of their team. And in agent-centric topologies, that is primarily done by making agents deliver correct code.
The primary responsibilities of the team 🔗
The core responsibility of the team is agnostic to technology: It is to develop and maintain a set of capabilities, and using these to deliver products and services that meet business needs of either other teams, customers or third parties.
The way this goal is achieved, however, has changed. Instead of production being a manual process, the primary focus of the team is to enable agents to deliver the products and services, in a way that meets non-functional requirements and is inline with the team philosophy for how products and services should look.
Team changes 🔗
Nothing about this changes the core topology laid out in team topologies. I do want to adress a couple of points though.
The complicated subsystem team 🔗
The complicated subsystem team is an outlier in Team Topologies. It recognizes that stream-aligned teams or the domain/platform model sometimes comes up against the limits a team’s cognitive capacity.
Depending on the system, AI may help make complicated systems less complicated. The threshold for keeping complicated subsystems in domain- or platform teams shifts, but the essential functioning of the complicated subsystem team evolves in the same way as other teams. Complicated subsystem teams
The enablement team 🔗
Can enablement be done by agents? Some will certainly try, until we look completely different at training, sparring and problem solving, the enablement team will still be humans, helping out humans with their problems. But as teams around them do more of their work through agents, some enablement teams will come and some will go.
New agent-enablement teams will pop up. Enablement teams that handle some of the developer tooling that agents use and handle without issues (git comes to mind), may need to shift their focus a bit. But enablement teams will continue, and other than what they enable, their days may look weirdly similar to today.
Enforce design systems 🔗
Agents must be prevented from making shortcuts. Changes that compromize on the principles and design system must be avoided unless absolutely necessary. Sometimes, a user request is best met by introducing new capabilities. In other words, agents need the ability to open new issues/tickets as well, and park the current issue until the higher-order request has been solved.
Hunt for context 🔗
Not all requests are the same. Company politics, management priorities, pecking orders and the like affect priorities and the acceptability of hacks and short-term solutions. There is no realistic way for the current generation of AI systems to know this.
Focus on long-term goals 🔗
It is well known that agents prioritize their immediate goal to the potential detrement of other considerations. A single agent should never be allowed to push to production. Where we as humans can have confidence that we will be able to weigh different considerations such as
Reduce noise 🔗
While we want agents to interact with other teams through issues, PRs etc, a number of these will be misguided. The evidence so far suggests that overconfident agents will file more misguided issues and PRs than employees. Misguided interactions carry with them negative externalities. Not only are the team’s tokens squandered, but it squanders tokens and/or human time from the other team as well.
Incorrectly filed issues with other teams should be treated like a production outage, and a post-mortem carried out. In the same way that a post-mortem after a production outage analyzes the cause in order to reduce future outages, the team must find out what lack in context or gating caused the misguided interaction, and discuss ways to improve their agents to reduce the likelihood that it will happen again.
The end of institutional knowledge? 🔗
The term “institutional knowledge” has been around for a long time. It has always been managed from a HR perspective. A company needs to preserve a base of long-term employees that remember the old battles that were faught, and spreads values important to the company.
The work now is on to add knowledge to agents - to provide context to the work and decisions these agents make. The more this succeeds, the less we need human institutional knowledge. A successful implementation requires decisions to be in writing, or at least transcribed, including the steps on the way to the solution. Recording a decision holds little value if the reasoning is missing. We want agents to follow the logic we use ourselves, when they make their decisions.
The time-to-mystery metric 🔗
There are two types of code bases: The ones that die young, and the ones that live to become mysteries. Practically all organizations have some systems that are so old, and so complicated, that the team that currently maintains it doesn’t understand it fully. This is true for much of our financial system. At some point, the last person who undertands it quits. And the poor souls tasked with maintaining it have to painstaikingly make changes in a large and baroque set of files that they don’t fully understand.
The difference between these systems and code in an Agent-first organzation is that the AI code is a mystery from the start. On the plus side, AI code is probably better documented, not written in an outdated language, and you don’t have to maintain it yourself. Not directly, anyways.
If you have made it this far… 🔗
… then you deserve to watch this: https://www.youtube.com/watch?v=3TNpOD6bov8.
Again, this is a thought, taken to the logical end. It is not a recommendation, at least not this extent.