Engineering AI Agents to Think and Work Together
We engineered a multi-agent system that can turn a user’s request into coordinated software-building work. Through one conversation, specialized AI agents can build applications, design workflows, connect external services and create other agents. An orchestration layer manages the handoffs, dependencies and context that bring these capabilities together, while users remain in control of what gets created or changed.
The situation
We had already built AI specialists for different kinds of software-building work. One builds working applications, one designs automated workflows, one connects outside services and one creates other AI agents. Each was good at its own task.
A real goal usually crosses several of them. Someone who wants an application and an automated process around it shouldn’t have to discover which specialist does what, repeat the requirements to each, move between interfaces and keep track of what depends on what. Each task had become easier. The whole job hadn’t.
What was missing was a way to approach the goal as a whole, through one conversation. The engineering problem was to make the specialists cooperate without losing the expertise, context and controls that made each of them useful.
What made it hard
Specialists don’t share your memory.
The coordinator sees the whole conversation, but a specialist only sees what it is sent. At first the coordinator paraphrased requests before passing them on. Details got lost, and sometimes it added implementation ideas the user never asked for. When a user answered “yes” to a specialist’s question, the coordinator forwarded just “yes”, which meant nothing on the other side.
It now forwards the user’s message word for word, and after any clarifying questions it sends the original request together with the answers, so the specialist gets the full picture.
Created doesn’t mean ready.
Creating an application takes a moment. Early on, the coordinator saw “creation accepted” and immediately tried to build pages in an application that wasn’t ready yet. Now creation counts as accepted, not ready. The status is checked a limited number of times, and building starts only once readiness is confirmed.
Uncertain actions get the same care. The coordinator never retries a creation it is unsure about, because that is how duplicates get made. If a step fails it says so plainly, never claims that later steps succeeded, and doesn’t automatically resend a failed build request, since part of the change may already have been applied.
The right specialist isn’t always obvious.
Classifying each message up front and sending it to one specialist is cheap, but it handles real conversations badly: follow-ups like “now make it send a reminder”, goals that span several specialists, and questions that need clarifying before anything happens. Users also talk to the assistant from any screen and use words loosely. Someone on the integrations screen who asks for a new page should reach the application specialist, and a request-handling process might be called a “workflow” even though a different specialist owns it.
The coordinator decides from context, and when it genuinely can’t tell, it asks one short question instead of guessing.
Work doesn’t run in a straight line.
Iteration happens at two levels. Within a specialist, the agent reasons, calls tools, looks at what came back and adjusts, sometimes for several minutes. At the coordination level, the coordinator receives intermediate results, reviews them against what the user originally asked for, and decides whether to ask a clarifying question, involve another specialist or request another pass.
Getting the second level right mattered as much as the first. Results, questions and partial work all have to feed the next decision without losing what the user originally asked for. And the loops need limits where limits matter: readiness checks run a limited number of times, and actions that require the user’s confirmation wait for it.
One conversation, several memories.
Each specialist keeps its own ongoing conversation, linked to the user’s chat, so a follow-up like “add a filter to it” reaches a specialist that remembers what “it” is. The coordinator doesn’t resend the whole history on every handoff. For the user, though, the work has to read as one thread.
Early replies sounded like an org chart: “the workflow specialist says…”, with internal names and identifiers mixed in. The coordinator now speaks in the first person and uses the user’s own words, while still relaying the specialists’ facts and questions faithfully so a question the user needs to answer is never dropped. Some builds take minutes, so a specialist’s progress streams into the same chat, which made the wait feel much shorter than a spinner did.
What was built
We built an orchestration layer on top of the existing agent framework, so that one conversation can drive several specialists through a larger goal. The coordinator decides what happens next. The specialists do the work. Ordinary application code handles whatever should be predictable. The user confirms the actions that require it.
Specialists are called only when a request needs them, and exchange work through the coordinator. Solid arrows delegate work with context. Dashed arrows return results and questions to the coordinator, which decides what happens next.
The coordinator is a regular agent on the same framework as the specialists, and its tools are mostly the specialists themselves. It interprets the request, selects specialists, forwards the user’s words along with any clarifications and keeps the conversation coherent. It runs on a small, fast model and sees about half a dozen tools, because its job is understanding and deciding what happens next, not duplicating the specialists’ reasoning.
Each specialist keeps its own instructions, its own memory linked to the user’s chat, and its own tools and access to application services. It does the substantive work in its domain, including its own cycles of reasoning, tool calls and checking results. Specialists use larger models than the coordinator, because the work is theirs.
A specialist’s first result isn’t necessarily the end of the task. What it returns goes back through the coordinator, which can evaluate the work against the user’s requirements and request another pass, involve another specialist or ask the user for clarification. The work can go through several rounds of reasoning and execution while the coordinator keeps the larger context. Specialists exchange work through the coordinator, so it has to carry complete context, because a vague handoff produces vague work.
For the longest-running specialist, the coordinator sees a single tool call. Behind that call, backend code prepares the environment if needed, waits until it is ready, sends the request, streams progress into the same chat and returns a short result. The model never manages infrastructure or polls for status. We reused what was already in place: the framework’s support for agents calling agents, the real-time chat channel and the platform’s existing services.
Users retain control over actions requiring confirmation. Specialists ask before saving things such as a new data structure or a new agent, and the coordinator relays those requests and waits. It never grants approval on the user’s behalf, even when the answer seems obvious. When a user attaches a document or a screenshot, the coordinator doesn’t read it. It passes a reference to the specialist that needs it.
A goal that crosses specialists
A user asks for an application for field technicians to log site visits, with an alert whenever a visit is marked urgent. The coordinator proposes an approach and asks whether to go ahead. Once the user confirms, the application is created and a capped status check confirms it is ready. The application specialist then builds the first interface, working through its own tool calls and checking what it produced.
The coordinator reviews that result, sees that the alert is the next piece of work and asks where it should be sent. With the answer, and with what the first specialist produced passed along, the automation specialist designs the alert. The coordinator reviews the draft against what the user asked for and, where it needs changing, asks for another pass. Throughout, the user sees progress and answers only the questions that need a person.
The result is an application with its initial interface created and an associated alert workflow designed, with the user able to review and approve the work through the same conversation.
Illustrative example, not a production deployment. The coordinator reviews returned work and may request another pass or involve another specialist. The dashed refinement loop shows that step where supported.
What changed
- Navigate the specialist tools and learn what each one does.
- Repeat the context at every handoff.
- Keep track of which piece of work depends on which.
- Describe a larger software-building goal once, in one conversation.
- Specialists coordinate application work, automation and connected capabilities, with context carried between them.
- The coordinator incorporates feedback, revisits work when needed and presents one coherent outcome. The user confirms what requires it.
The value isn’t fewer screens. It is that work spanning several specialists, with dependencies, feedback and revisions along the way, can move forward through a single experience. The original request and the user’s answers survive the trip to each specialist, each specialist keeps working within its own responsibilities, readiness and similar dependencies are handled in code, and progress stays visible. The coordinator stays small because the specialists carry the domain expertise.
The engineering decision that mattered
We deliberately didn’t build one agent with hundreds of tools. That agent would have been slower and more expensive on every turn, more likely to pick the wrong tool, and its instructions would have diluted the tuned instructions of every specialist. Improving one domain could have changed how another behaved. So we kept the specialists focused, each with its own reasoning, memory and application capabilities, and built a coordinating layer to make them work together on larger goals.
We also kept AI reasoning and delegation separate from the predictable operations that belong in software. Waiting for an application to be ready, limiting how often its status is checked and streaming progress are ordinary code, so the model doesn’t spend turns on them. The result is a system that can handle multi-agent work while remaining maintainable, extensible and easy to follow, built on the agent framework, the real-time chat channel and the services we already had.