Agent Designer: Building the Platform That Builds Multi-Agent Systems

The appeal of coordinating networks of specialized agents – one validating documents, another scoring risk, a third enforcing compliance – is enormous. The distance between that vision and a running system, however, compounds across four structural gaps.

Agent Designer was built to close all four at once – letting both business and technical teams design, visualize, run, and export multi-agent networks starting from nothing more than a description or a PDF.

Agent Designer is two things simultaneously. First, it is a meta-agent system – the platform uses a multi-agent pipeline to design multi-agent systems. One internal agent scaffolds the network structure, another writes each node’s behavioral instructions, another validates the resulting graph, and a final one serializes it to a config file. Second, it is a visual IDE – the output isn’t just a file on disk, it renders immediately as an interactive, animated graph in the browser.

It is worth being explicit about what the platform is not: not a general-purpose assistant, not a drag-and-drop workflow builder, and not a deployment platform. Its narrow focus is bridging a human’s description of what they need to a correctly structured, running multi-agent system.

Design-time produces a config file. Runtime reads that same file back into a live agent hierarchy. Nothing gets redeployed to change behavior – the config is the contract.

When a graph lives in Python, it is hard to diff, can’t reload without a redeploy, and doesn’t survive being handed to another team. A proprietary, human-readable config format – a superset of JSON – is what the platform standardized on instead. An entry with instructions is an agent; an entry without one is a pure tool.

# illustrative, not a real deployed agent
{
  name: "Fraud_Prevention_Manager"
 
  llm_config: { model_name: "gpt-4o" }
  max_iterations: 40000
 
  instructions: """
    Detect fraud patterns, route to
    specialist agents. Aggregate risk
    scores before escalating.
  """
 
  tools: [
    "Transaction_Analyser"
    "Rule_Engine_Agent"
    "Human_Review_Agent"
  ]
}

name

The unique ID other agents reference in their own tools array to delegate to this one.

llm_config

Per-node model selection – orchestrators can run a frontier model while leaf agents run something cheaper.

instructions

The system prompt injected at spawn time. It lives in config, so behavior changes without a code change.

tools

Child agent names or coded tool names. This array is, quite literally, the delegation graph.

This is itself a multi-agent system – one internal agent scaffolds structure, another writes instructions, another validates the graph – orchestrated tool call by tool call, and streamed back to the user as it happens.

1. 01

   Describe

   Plain text, a PRD upload, or both together – a note like “focus on GDPR compliance” layered on the document.

2. 02

   Design

   The design agent plans a sequence of tool calls: create network, add agents, wire connections, write instructions, validate.

3. 03

   Visualize

   The moment design finishes, it renders as an interactive graph, auto-arranged by hierarchy.

4. 04

   Export

   Query it immediately, keep refining it in conversation, or export it as a runnable Python project.

Every tool call goes through the pure Python graph manager, which maintains in-memory state. The LLM never directly mutates state – only through the tool interface, making the process auditable and reversible.

Design produces a proprietary config file. That file is inert until the NetworkLoader reads it and instantiates real, running agents. This load sequence turns the config’s structure into executable objects – and it happens fresh the first time a network is queried, then gets cached.

1. 01

   Parse

   The internal parser resolves the file into a Python dictionary tree, walking every entry for its name, instructions, downstream tools, and toolbox references.

2. 02

   Find the top agent

   The loader subtracts the set of all agents referenced as someone’s downstream tool from the full agent set – whatever’s left with zero incoming edges is the entry point. More than one candidate raises a hard error.

3. 03

   Build bottom-up

   Leaf agents get their tools bound first. A downstream reference becomes a StructuredTool (agent), a registered class (toolbox), an MCP connection (an https:// URL), or a recursive sub-network load (a path starting with /).

4. 04

   Assemble & cache

   Each agent is wired into a full AgentExecutor – system prompt, LLM, bound tools, iteration limit – and the whole network is cached by name, so every later query skips straight to execution.

What turns this from an invisible backend process into a pulsing graph is a callback handler that hooks into five points in the execution lifecycle – an agent deciding to call a tool, a tool starting, a tool finishing, a tool erroring, and the top-level chain finishing. Each hook emits a WebSocket event, which the frontend turns into a live state map of every agent.

The execution doesn’t just run somewhere on a server. It visibly ripples through the same hierarchy the design flow built, one node at a time.

Every node’s treatment reflects real execution state, streamed live as the network runs. In a network with twenty nodes on screen, this is how a user finds the one that matters.

IdleHollow ring, no glow

Node exists but hasn’t been called yet in this run.

ExecutingFilled, pulsing halo

The active agent is unmissable while it runs.

CompletedFilled, steady

The agent returned a result and passed it back up the chain.

FailedDashed ring

An exception surfaced on the node itself, not buried in a log.

Any designed network can be exported as a self-contained, runnable Python project – a real codebase an engineer can read, modify, and own. The generator produces complete, runnable projects, not snippets: receive the output, run pip install -r requirements.txt, fill in .env, run python main.py – a working multi-agent system, no assembly required. Six components make up the pipeline.

• ConfigParser – reads and validates the network file: agent definitions, tool references, the top agent, LLM config, and the dependency graph between agents and tools.
• AgentGenerator – writes a Python class per agent from a template, encapsulating its system prompt, tool bindings, and executor construction as idiomatic code.
• ProjectScaffolder – lays out the full package: agents/ and tools/ directories, network.py for orchestration, config.py for environment-driven settings, and a main.py entry point.
• DependencyManager – inspects the LLM provider and tool types actually used, and writes a minimal, pinned requirements.txt – never a bloated, generic list.
• DocGenerator – writes a README.md customized to that network: an agent roster, setup steps, the network’s own sample queries, and a configuration reference for every required variable.
• GitHubPublisher – validates the token up front, runs the generator into a temporary directory, creates or updates the target repository, and pushes an initial commit straight to GitHub.

loan_processing_ai_network/
  src/
    agents/
      __init__.py
      decision_orchestrator_agent.py
      customer_interaction_agent.py
      document_verification_agent.py
      ...
    tools/
      __init__.py
      document_data_extraction_tool.py
      external_data_integration_tool.py
      ...
    network.py          # orchestration and assembly
    config.py           # settings from environment
  main.py               # entry point
  requirements.txt      # generated by DependencyManager
  README.md             # generated by DocGenerator
  .env.example          # all required keys
  Dockerfile            # optional, containerized deploy

What comes back from a publish is a working repository URL, not a zip the engineer still has to set up.

The net effect for an engineering team: the platform’s job ends at a real, versioned, documented codebase sitting in their own GitHub org – not at a proprietary runtime they have to keep depending on.

One click exports plain Python – agents, tools, network.py, a generated README – that runs immediately. Hardening it for production is a separate, deliberate step, following three recurring patterns.

Note

These are internal demonstration builds, generated to evaluate what the design pipeline can produce across domains and complexity levels. They are not part of Nablon’s productized offering and are not deployed for any client. Treat them as illustrative examples, not a services catalogue.

What emerges from a close look at Agent Designer is a consistent engineering philosophy: instead of a template system or a form wizard, it is a constrained LLM agent that produces architectures by reasoning about a domain, guided by a handful of hard structural rules.

The platform’s proprietary config format gives that output a portable, diffable, hand-editable home. Real-time streaming turns debugging from log archaeology into live inspection. Code generation means the platform is never a silo – a team can use it for high-level design and own the generated code entirely from there.