Most AI agent discussions I’ve seen focus on grand visions of replacing human workers. But the more I dig into how agents actually work in practice, the more they remind me of microservices architecture patterns from a decade ago-same promises, same pitfalls, same need for thoughtful design boundaries.

Hannah Foxwell’s talk on agent teams crystallizes that successful agent implementations aren’t the ones trying to build general-purpose replacements for people. They’re the ones that look suspiciously like well-designed distributed systems.

You can give a task to an agent. You don’t give them a job.

This distinction matters more than it sounds. When I see teams struggling with AI adoption, it’s usually because they’re trying to hand over entire job functions to a single agent. But agents, like microservices, work better when they have narrow, well-defined responsibilities.

an agent might be more like a microservice than it is a person. You can give it a task to do. You can give it a function to perform. You can prompt it or engineer it and give it access to things, and it can do that one thing really well.

I’ve found this maps directly to how we learned to decompose monolithic applications. The same principles apply: single responsibility, clear interfaces, bounded contexts. The difference is that instead of decomposing code, we’re decomposing cognitive work. I also wonder if that’s why managerial roles tend to find a lot more value from these tools compared to others.

Don’t give your agent 400 tools, it’s going to get really confused. One to three tools per agent is the safe and efficient number of tools to give to your agent.

I think this is more about using MCP, but I can echo this. I have survived the past 3 months on claude code without any MCPs and it’s been still great use of my time. And when you fallback to microservices analogies, how many times have we seen services that do “everything” become unmaintainable? The cognitive load problem exists for artificial agents just as much as human ones.

Conway’s Law for Agent Architecture Link to heading

Overall, a team of agents with specific roles will perform better than a single agent.

To add to this, in my experience, Conway’s Law shows up everywhere, and agent teams are no exception. The communication patterns between your agents can mirror structure you setup. If it enables unclear handoffs and overlapping responsibilities, your agent system will suffer.

Sparse communication patterns between agents can improve accuracy and can significantly reduce cost. That’s the main thing because you make sure that the team is focused. There are no distractions. There’s no duplication.

I’ve seen this pattern when I was using a team of agents to build a knowledge based of a team’s codebase. Too much information overloaded the systems across bunch of tools (from claude-code + subagents to AutoGen’s multi-agent framework). When services have too many dependencies and communication paths, the system becomes harder to reason about and more expensive to operate. The same applies to agent architectures.

The successful multi-agent patterns from Allen Chan’s research mirror successful team topologies: supervisor patterns for coordination, pipeline patterns for sequential processing, collaborator patterns for parallel specialization. These aren’t coincidences.

The Failure Modes We Know Link to heading

There’s obviously another reason why we don’t give agents massive amounts of access to all of our data and all of our applications, it’s called principle of least privilege. You want to limit the blast radius of a single agent.

This is security 101, but it’s also operational resilience. When a single agent has access to everything, debugging becomes a nightmare. When something goes wrong, you can’t isolate the problem to a specific domain or capability.

When you’re starting out with this, keep a human in the loop. Then, as we gain more data about the reliability of that agent in performing its tasks, then we can start to step back. Don’t do that on day one.

This maps to how we’ve learned to roll out new services. You don’t deploy straight to production with full traffic. You start with monitoring, observability, and gradual rollouts. The same staged approach applies to agent deployment.

Beyond the Productivity Theater Link to heading

I don’t want to be made better and faster. I don’t think there’s ever been a point in my career where I got to the bottom of my to-do list… For most people and most teams, I think maybe we should be focusing on doing the right work, and doing it better… I want to give the toil to my agents. I want to win back some of those hours in my day. I don’t want to do more, I want to do less.

When I think about successful automation projects, they’ve always been about eliminating categories of work, not just speeding up existing work. Agents that reduce toil create space for higher-value activities. Agents that just make you faster at the same tasks create more work.

Questions Worth Exploring Link to heading

Simon Willison’s point that agents are essentially “LLMs that run tools in a loop” feels reductive but useful. It strips away the anthropomorphic framing and focuses on the technical reality.

I’m curious about the organizational design implications. If agents really do follow microservice patterns, what does that mean for team structures? How do you manage the coordination overhead between human teams and agent teams? When does the complexity of multi-agent systems outweigh their benefits?

And maybe most importantly: how do we avoid rebuilding all the same architectural mistakes we made with microservices, just with AI this time?