Agent Builder: Describe It. The Platform Builds It.
We engineered a framework that turns agent definitions into working AI agents, along with a conversational builder that lets users describe what they need. The system connects the appropriate tools, configures memory and handles execution, so each new agent doesn’t have to be developed from scratch.
The situation
The first AI agent took a couple of weeks to build. The second took about as long. Each needed its own model connections, tools, memory and failure handling. Fixes made to one didn’t carry over to the others.
Requests for more agents kept arriving, and many of those agents were meant to be built by people who don’t write code. The customer needed a common framework that could support many agents without repeating the same development work each time. Agents had to be quick to create without a code deployment each, connected to real business systems, and reliable enough for other software to consume their output. Some turns run for minutes, so users needed to see progress. And because many organizations share the platform, each had to see only its own data.
What made it hard
When an agent can’t use a tool, it needs to stop.
Early on, if a tool failed to connect while an agent was being set up, we skipped it and carried on. The agent then behaved as if it had used the tool and made up the results, such as file paths it never fetched. The error only appeared halfway through a conversation.
Now, if any declared tool fails to connect, the agent isn’t built, and the error names the tool and the reason. Tools also have to stay within each organization’s boundaries. Failing at setup turned out to be much kinder to users than failing quietly.
Getting the output right matters.
Many agents return forms, scores and reports that other software reads, so an answer that is almost the right shape is a failure.
- Small formatting mistakes, like a quoted list or a value outside the allowed options. A repair layer fixes the common cases and asks the model to retry when it can’t.
- A field that could never be filled. Under strict structured output, a free-form field could only be empty. The framework detects this and switches that agent to another output method.
- Stale answers. A failed turn could leave the previous turn’s answer in place. The answer is now cleared at the start of every turn.
Silence looks like failure.
Some agent turns run for minutes. The first problem was timeouts: our request style returned nothing until the model finished, and the connection gave up after five minutes. Streaming fixed that, but users then stared at “Working…” with no sign of life. We started with the model’s live narration and added the agent’s to-do list, tool activity and specialist start and finish events, as short labels that never include the data sent to tools.
The last gap was quieter. During a long tool call no text was streaming, so the interface assumed a stall and offered a retry. We added a heartbeat based on wall-clock time, sent whenever nothing else had been sent for a while.
Memory was doing three jobs at once.
The first conversation store was the agent’s memory, the chat history on screen and the list of past sessions, all in one. It kept only a flattened view of messages, so it couldn’t fully restore an agent’s state. We replaced it with a database-backed design from the open-source ecosystem that stores snapshots of agent state and saves only what changed. Very long conversations with many files later failed to load because loading fetched every historical version, so we now fetch only the versions the current snapshot needs. The chat sidebar stays separate from memory, so changing one doesn’t break the other.
What was built
An agent is a description. It says what the agent is for, how it behaves, what it can do, which specialist sub-agents it can hand work to, and what shape its answer takes. The framework reads that description and builds the working agent.
The agent mechanics are open source. We built on LangChain and LangGraph and used the deep agents pattern, where agents plan with a to-do list, keep notes and files in a private workspace and hand sub-tasks to specialist sub-agents. Our engineering is the layer around them.
The Agent Builder
Once agents were descriptions, writing one became a job an agent could do. The Agent Builder is an agent on the framework that works out what the user wants through conversation and prepares the definition. The framework, not the Builder, then turns that definition into a working agent. A user says what they need, and the Builder asks clarifying questions one at a time, searches the platform’s catalog for tools that fit, and explains its suggestions so the user can adjust them. It saves the definition only after the user explicitly confirms. It uses only tools that exist in the catalog, and when it edits an existing agent it changes only what was asked and notices if someone else changed the agent in the meantime.
What changed
New agents could be defined without anyone implementing a runtime for them, and people could design them in a visual builder instead of turning each one into an engineering project. Improvements reached every agent at once: when we fixed file handling, smoothed streaming or reduced token usage, no agent description had to change.
We also found opportunities to make individual agents faster. By tracing each request and testing against consistent tasks, we identified unnecessary operations and work that could run in parallel. The improvements came largely from changing how the agents worked, rather than changing the models.
These are measurements of individual agents and changes. They are not framework-wide figures.
The engineering decision that mattered
We chose to build on LangChain and LangGraph rather than write another agent loop ourselves. That let us concentrate on the problems specific to this platform: tool access, organizational boundaries, reliable outputs, memory and the experience of working with agents.
We also learned that instructions alone weren’t enough for things that had to work every time. Wherever possible, we enforced those requirements in the framework itself. That approach made improvements reusable across every agent built on it.
Related work
Multi-agent orchestration
See how we coordinated specialist AI agents to work toward larger software-building goals.
Read the case study →AI app builder
See how we built an AI application builder on an enterprise-grade platform.
Read the case study →Intelligent UI Automation
See how vision-language models and reusable workflows automate applications without suitable APIs.
Read the case study →