10x faster and reliable: rebuilding a client's AI agent as a team of agents

Full walkthrough

An AI agent built for one of my clients used to take more than a minute to respond, and I brought that down to seven seconds. I also fixed the reliability issues, like the malformed JSON responses that kept breaking it. In this case study I'll show you exactly how the solution was built, demonstrate it live, and at the end I'll explain the one mistake I see made again and again across AI projects.

The problem

My client's product is for staffing agencies - agencies that get permission to run recruitment on behalf of other companies. They can spin up client-branded landing pages for a specific vacancy. Before AI, someone edited those pages by hand: take a template, update it for each job and each recruiter, over and over.

So the client built an AI agent to speed that up. Instead of editing by hand, you tell the agent "update this page for a fulfillment-center area-manager role," give it the images and the job details, and it updates every section - requirements, benefits, testimonials, recruiter contacts, the call to action.

It worked, but two things did not. First, it was slow - even a small edit could take a minute. Second, it was unreliable. Maybe one in ten or twelve times, the agent returned a broken response. Ask it to change the primary buttons from orange to yellow, and sometimes you'd get malformed output back. Hard to reproduce, but when it happened the only fix was to ask again.

Why it was slow and fragile

To understand the fix, you need to see what sat behind the chat. The whole landing page is represented as JSON - a big block of text that holds the styling, all the copy, the requirements, every piece that builds the template. The agent was a single AI agent driven by one large system prompt, and that one agent had to regenerate the entire JSON on every change.

That's the root of both problems. The JSON is huge, so writing it all out is slow. And because the agent produces it token by token in one long pass, the chance of a mistake somewhere in that giant output is high - which is exactly where the broken JSON came from.

The fix: one agent becomes a team

Here's the way I think about it. We had one AI agent doing all the work. Replace the word "agent" with "person." If one person works on a project, they work at a certain speed. Add a second person - and split the work properly, so they aren't stepping on each other or waiting on each other - and the work goes roughly twice as fast. Add six people working in parallel on well-separated tasks, and it's roughly six times faster.

So instead of one agent regenerating the whole JSON, I built a team of agents that work at the same time, each responsible for a smaller section - one group handles styling and fonts, another handles copy, and so on. Because each agent only writes its own small piece, the work runs in parallel and the chance of any one of them making a mistake drops sharply. That's how you get both the speed and the reliability at once.

The result

Same interface as before, except now six agents work in parallel on each request. I ran the same query that used to take a minute - "update the job page content" - and it finished in about five seconds with a report of what changed. To show the team really ran in parallel, I opened the OpenAI logs: the request count jumped by six at the same timestamp, each agent handling its own section, no conflicts and no waiting on each other.

I tested it on more edits - reduce the requirements to three, double the salary, change the button color, rename the recruiter - and it made every change correctly in about four seconds. The old single-agent version would still take close to a minute on the same request, because it has to recreate the entire JSON every time.

The mistake I keep seeing

At the start I mentioned a recurring mistake. When the client and I first talked, the ask was "let's fix the prompt - get a prompt engineer to look at it and optimize it." The instinct behind that is reasonable: you want to protect the codebase, so instead of giving an outside person access to the whole project, you build a UI that only exposes the prompt. They can edit the prompt and test the agent, edit and test again.

But the problem was never the prompt. It was the architecture - one agent carrying too much work. So that edit-and-test loop just runs forever without fixing the real issue. Days go by, then weeks, and by the time it's clear the prompt was never the bottleneck, a competitor who knows how to build it properly may already have shipped.