Picture an AI that takes a ticket off the board, splits the work between front-end and back-end, writes the code, reviews it, adds the tests, and opens a pull request.
Now picture it failing halfway through, with no clue which part broke.
Most people meet that second picture first.
The trouble with one agent that does everything
At Levi9, we spend our days moving tickets through the loop every engineer knows: refine, build, review, test, ship. The obvious way to automate that with AI is to hand the whole loop to one capable agent and let it run. It works, right up until it does not. When a single agent quietly grabs a ticket and produces the wrong result, there is no seam to inspect. You are left staring at a black box.
So, we built the opposite. Rather than one agent doing everything, we set up a team of small agents, each with a single job, and a conductor to coordinate them.
The orchestrator’s only job is to call a given agent and decide whether the work is good enough to move to the next step. The orchestrator intentionally stays lightweight. Rather than carrying implementation knowledge, domain expertise, or tool-specific instructions, it focuses only on classification and routing decisions, leaving execution to the specialists.
Each agent has its own responsibilities. This separation has a practical benefit: every specialist receives only the context, tools, and skills required for its slice of the workflow. Smaller prompts mean faster inference, lower token consumption, and less time spent re-processing information that has no relevance to the current task.
An orchestrator, an intake, and a handful of specialists
The implementation flow begins where the work begins. Usually that is a ticket, but the Ticket Intake agent can also take a prompt straight from a developer when the ticket is not ready yet. It reads the work over Azure DevOps, checks that it is genuinely ready (a clean branch, acceptance criteria, dependencies, a clear split between front-end and back-end work), and then makes a call: does this go to one implementation agent or both? If the change is front-end only, just the front-end agent runs. When both are needed, the back-end and front-end agents pick up their halves and run in parallel.
A Code Review agent then checks both sides. If something is off, it sends the work back to whichever agent needs to fix it, not to both at once. Only once review passes does a Test agent write its unit tests, and only then does a PR agent open the pull request and update the ticket. A matching debug flow behaves the same way but starts from a bug report rather than a ticket, and a separate refinement flow decides whether a ticket is even ready to be built in the first place.
The order is not accidental. We first had tests written straight after the code, but review kept sending work back, which meant rewriting the tests every time. Moving the Test agent to the very end, after review confirms the feature is done, stopped that churn.
The small decisions that make it usable
Two design choices do a lot of quiet work. First, not every agent should be visible to a person. A simple true or false flag hides the agents that only make sense inside a flow, so nobody is faced with a PR agent sitting idle with nothing to act on. Agents pass work between themselves through a hand-off, and the person at the keyboard can jump in or step away at any point.
Second, each agent runs on the model that suits its job. The intake agent, which does something simple, runs on a small and inexpensive model. The heavier research agents run on stronger ones, with a fallback if the first choice is unavailable. It is a practical way to keep token spend down instead of paying premium rates for trivial steps.
The reward for all this structure is control. When something goes wrong, we can debug at the level of the individual agent. Each agent is simple, with its own flow and its own skills, which makes it far easier to spot when one has done something wrong and to change just that one.
Watching it run, rough edges and all
In a full run, the whole chain fires. The orchestrator pulls the repository, cuts a feature branch, moves the ticket to “Doing”, splits the work, and the front-end and back-end agents build in parallel. Review passes. Tests are written and pass. A pull request appears at the end.
It is not magic, and we do not pretend it is. Sub-agent progress is sometimes hard to see, and a step can stall while it waits for us to approve or reject a command by hand. That is a sore point: you always have to track where it got to. Being honest about the rough edges is part of what makes the approach credible rather than a polished sales pitch.
Start big, then split
The system did not arrive fully formed. It grew from two agents to seven or eight, one split at a time, whenever we could not work out why a step was failing. That is also our advice to anyone starting out: begin with a couple of larger agents that do the main work, then break them into smaller ones as the cracks appear. That is how we went from two agents to seven or eight. Because every agent is a small, self-contained unit, the whole thing is modular: we can add a new agent, drop one, or slot a new one into the flow without unpicking the rest.
The roadmap is already taking shape. We want each run to leave behind a short memory of the session so the next ticket starts smarter, and we are weighing up automated end-to-end tests through a separate Playwright-driven flow. A few limits remain to iron out, such as how agents tucked into nested folders reference one another.
The mindset, not the tooling
What makes this worth paying attention to is not the tooling. It is the mindset. Treat AI agents like a team you can manage, hold accountable, and improve one member at a time, rather than a single oracle you have to trust blindly. That is the kind of hands-on experimentation we do at Levi9 to work out what actually holds up before it goes anywhere near a customer’s codebase, and it is the difference between an AI demo and an AI practice.
***This article is part of the AI9 series, where we walk the talk on AI innovation.***
In this article:
Levi9 Serbia
