Designing Agents That Design Agents

"Designing agents that design agents" sounds fancy, and who doesn't love a little recursion? That is exactly why the concept deserves healthy suspicion. Recursion pulls the mind toward the sci-fi version too quickly: self-improvement loops, agents spawning agents.

We build this at Mentiora, but we removed the recursion on purpose. The precise framing is agents that design agentic systems: the designer agent and the designed agent have orthogonal capabilities, both are sandboxed, and communication flows one way. And before any of that, the basics of any business apply: operators and customers come first.

Customer layer: Meet them where they are

                      customer layer
                            |
                            | customers guide priorities
                            v
engineering layer <-- agent maintains --> quality layer
tools/context/actions                    traces/evals/rollback

Start with the human. Engineers want to talk about MCP, tool calls, and loops. Customers want to solve tasks. So we translate: we checkpoint agents with versioning, but we don't call it git. We have advanced agentic tools, but we never mention MCP in the UI. The rule is to explain capabilities, not technicalities.

In fact, don't explain the interface at all. Show what it can do.

familiar chat surface
+------------------------------------------------+
| What should this agent improve?                |
| > make refunds safer                           |
|                                                |
| Agent: I can propose a change and run checks.  |
| [shows change] [runs checks] [asks approval]   |
+------------------------------------------------+

From there, progressive disclosure does the work. The interface starts as a plain chat box, extends itself inline with UI as capabilities become relevant, and then guides the user around the page. Through all of it, the agent's state and goals stay front and center.

Engineering layer: Discipline and rigor

As mentioned in the intro, the dangerous version of “agents designing agents” is giving every agent every tool. Agent edits another agent, which edits functions, which calls tools, which changes behavior, and so on. We need classic computer science rigor to avoid unmanageable outcomes.

                 ┌────────────────────┐
                 │   human operator   │
                 └─────────┬──────────┘
                           │
            ┌──────────────┴──────────────┐
            │                             │
      Copilot (designer agent)           MCP
            │                             │
            └──────────────┬──────────────┘
                           v
           Assistant Layer (designed agent)
                           │
          ┌────────────────┼────────────────┐
          v                v                v
   config authoring   QuickJS functions   chat preview
          │                │                │
          v                v                v
   versioned drafts   bounded VM        app-only HMAC

The clever part is not that the designer agent can touch everything. It can't. The clever part is that both surfaces — the in-admin Copilot and the external MCP connector — meet at one typed tool abstraction: the disciplined Assistant Layer. They go through the same underlying tool shape, with scoped context, membership checks, typed inputs and outputs, and surface-specific permissions.

The powerful parts sit behind boring gates. Configuration changes go through versioned drafts. Functions run in QuickJS: agent-authored JavaScript never touches Node. Each call gets a fresh WASM sandbox with memory, stack, and deadline limits, and no host primitives — no fetch, no process, no filesystem. The chat preview is protected by app-only HMAC tokens, so the human's messages travel through a channel the model can't forge.

The designer agent is more powerful than the agent it designs, but their tool sets are disjoint, and it drives the runtime agent from the outside. Hand the designed agent its designer's tools and you have real recursion, and real problems. We don't.

Quality layer: Make it deployable

Quality is not vibes, and it is not an afterthought once the agent has done something clever. Quality is the layer that decides whether the clever thing is allowed to become real. It owns traces, checkpoints, evals, handoff quality, regression tests, approval gates, and rollback — and every eval is attached to a decision:

capability eval  -> can it do the task?
regression eval  -> did the new version break old behavior?
safety eval      -> did it avoid risky action?
tool-use eval    -> did it choose the right tool?
handoff eval     -> did it stop at the right time?
experience eval  -> did the user understand what happened?

The quality layer answers boring questions continuously, and the agent surfaces the answers to humans: what changed, why, what improved, what broke, whether we can roll back, who approved it, and whether it should become a test case. A concrete example: our in-house prompt-improvement algorithm generates candidate agent changes, and the quality layer ranks them and promotes only what survives.

Agents are a multiplier for producing change. Agents producing agents, by definition, multiply exponentially. The quality layer is what filters the churn. Without it, "the agent improved itself" is another way of saying "something changed and the customer doesn't know why."