Meet the AI Dev Team: What Multi-Agent Automation Looks Like

Most of the automation we build runs on a single agent. A workflow fires, one Claude call reads the messy input and makes a judgment, and control passes straight back to the plumbing. It’s a model we like, and one we’ve written about before. Then a developer named Aleksandar Mirilovic published a line that made us look up: while he was asleep, his AI dev team merged twenty pull requests across two repositories.

Not one assistant grinding through a checklist - a team. Four agents, each with a job - product owner, developer, QA, architect - talking to one another and shipping real code with nobody watching. Mirilovic (who writes as @amirilovic) documented the whole setup in “Meet My AI Dev Team” and open-sourced it as ai-crew. It’s one of the clearest pictures yet of where agentic automation is heading - so it’s worth walking through what an AI agent team actually is, why the structure matters more than any single agent, and where it fits next to the orchestration we already build for clients.

What an AI agent team actually is

Say “AI agent” and most people picture one clever assistant you hand a task to. An agent team flips that. Instead of one model doing everything, you split the work the way a human software team does - by role. Mirilovic’s crew has four:

• Product Owner - takes feature requests, writes the tickets, manages the backlog, and decides what’s ready to build.
• Developer - picks up a ticket, writes the code, and opens a pull request.
• QA - tests that pull request and tries to break it before it ships.
• Architect - handles the hard design and research calls, and reviews the trickier work.

Each one is its own process: a separate running agent with its own instruction file - a plain-text brief that tells it who it is and how to behave. And here’s the part that makes the whole thing click: they coordinate through the same tools a human team uses. Tickets live in GitHub. Conversation happens in Discord, where one agent @-mentions another to hand off work or ask a question. Code review happens on the pull request. There’s no exotic control panel holding it together - the glue is the everyday project-management and chat software people already work in.

Picture a request moving through it. Someone drops “add a cost-tracking command” into Discord. The product owner turns it into a ticket and marks it ready. The developer picks it up, writes the code, and opens a pull request. QA pulls the branch and tries to break it; the architect weighs in on anything structural. Once it passes, the change is merged and the ticket closed - and the only human in that loop was the person who asked for the feature.

Under the hood it runs on Anthropic’s Claude Agent SDK, the toolkit for running Claude as an autonomous agent with real tools - a shell, web search, the GitHub CLI - rather than as a chat box. Mirilovic even gives each agent a name and an animal avatar, which sounds whimsical right up until you watch two of them work through a failing test in a Discord thread.

Why a team beats a single agent

You could hand all of this to one big agent. Plenty of people do. But past a certain size a single agent starts to strain, and the reasons map almost exactly onto why a growing company stops leaning on one brilliant generalist and builds a team instead.

• Parallelism. One agent works one thing at a time. A team works the backlog at once - the developer builds one ticket while QA tests another and the architect researches a third. That is how twenty pull requests land between midnight and morning.
• Specialization. A tight, single-purpose instruction set beats a sprawling one. An agent whose only job is to test is simply sharper at testing than a generalist juggling six responsibilities in one prompt.
• Smaller context. Each agent carries only what its role needs. That matters more than it sounds: agents get worse as their context fills with irrelevant history - they lose the thread and start ignoring their own instructions. Narrow roles keep each agent’s working memory clean.
• Clear ownership. In ai-crew, the developer, QA, and architect all escalate to the product owner, and only the product owner escalates to a human. Problems route to one place instead of four agents pinging you at once.

None of this is new as management theory - it’s how teams have always worked. What’s new is that the team members are language models, and the org chart is now a piece of software architecture you design.

Where this fits the automation picture

If you’ve read our take on n8n versus Claude, you know the line we draw: n8n is an orchestration engine, Claude is a reasoning engine, and the real work happens when a reasoning step runs inside an orchestrated workflow. An agent team is a different answer to the same underlying question - how do you coordinate work? - and the contrast is worth sitting with.

In an n8n workflow, the orchestration is explicit. You draw the graph: this node, then that one, branch here, retry there. The control flow is something you design up front and can literally see on a canvas. In an agent team, the orchestration is a social protocol. Nobody drew a flowchart; the agents move work through assign, build, review, and merge because that’s how their roles are written and how the shared tools nudge them along. The coordination is emergent rather than wired.

Neither is better in the abstract - they suit different problems. Explicit orchestration wins when the steps are known and reliability is the whole point: a nightly data sync, a webhook that fans out to five systems, a billing flow that has to behave identically every single time. Emergent coordination wins when the work is open-ended and the path can’t be drawn in advance - “build this feature,” where the right steps depend on what you find once you’re in the code.

And they aren’t mutually exclusive. The deeper lesson from ai-crew is one we keep relearning: autonomy is only as good as the infrastructure beneath it. A team of agents merging real code unattended needs exactly what any production system needs - durable state, retries, logging, and a way to recover when something dies at 3 a.m. That’s the discipline we wrote about in how we run n8n in production, and it doesn’t disappear when the actor is an agent instead of a workflow. If anything, it matters more.

The honest part: it costs money and makes mistakes

What we appreciate most about Mirilovic’s write-up is that it isn’t a highlight reel. He’s candid about the failure modes, and they’re exactly the ones you’d expect from a young technology pushed this hard:

• It costs real money. The whole thing runs on a server that costs a few euros a month, but the model usage lands around $200 a month. Agents that think constantly burn tokens constantly.
• They make real mistakes. Agents forget steps in their own process, talk past each other, and - the most memorable one - sometimes fake it: an agent reported that it had tested everything in the browser when it plainly hadn’t.
• Context still bloats. Even with narrow roles, a long-running agent’s context fills up and it starts drifting from its own rules - the very problem the small-role design is meant to hold off.

What keeps this from being a cautionary tale is that the system improves itself. When an agent learns a lesson - after triggering a restart loop, say - it edits its own instruction file so the mistake doesn’t repeat. The agents have fixed bugs in their own codebase and built their own new features. But the part to underline is that a human still designed the system, set its guardrails, and owns the exceptions. Mirilovic’s own framing is the one to keep: it’s humans designing the system, and AI running the sprint.

What it means if you’re building automation

You don’t need to stand up a four-agent crew next week to take something useful from this. The real takeaways are about sequencing and discipline.

1. Start with one well-scoped agent. A single agent inside a reliable workflow solves more than people expect, and it’s far easier to reason about. Reach for a team only when you hit a genuine ceiling.
2. Add roles when that ceiling is parallelism or specialization. If the bottleneck is that one agent can’t hold every responsibility at once, or can’t move fast enough across a backlog, that’s the signal to split the work by role.
3. Invest in the coordination layer, not just the agents. The reason ai-crew works is the unglamorous part - tickets, mentions, reviews, escalation. Decide how your agents hand off and where a human sits in the loop before you scale anything up.
4. Treat instructions as living documents. An agent’s instruction file is where its behavior actually lives. Expect to revise it constantly, and give the system a way to learn from its own mistakes.
5. Put guardrails around autonomy on purpose. Mirilovic’s agents run with broad permissions - that’s what makes overnight merges possible, and also what makes a bad call expensive. Decide what an agent may do unsupervised and what always needs a human, deliberately rather than by accident.

One line from his write-up is a healthy antidote to the hype: you don’t need a giant orchestration platform with two hundred integrations - “you already have a developer with super powers.” The point isn’t that tooling stops mattering. It’s that the leverage now comes from how well you organize a few capable agents, not from how long your list of connectors is.

Wondering whether your automation has outgrown a single agent - or whether a whole team would be overkill for what you’re actually trying to do? That’s the kind of question we like most. Get in touch and we’ll think it through with you.