Prototype architecture and case study · 2025
AgentMesh
A single LLM asked to build software stops at the first thing it gets wrong.
Overview
The problem. A single LLM asked to build software stops at the first thing it gets wrong.
Why it matters. Most useful software tasks need more than one pass: something has to notice the failure, decide what to change, and try again. That is a system-design problem, not a prompting problem.
My contribution
Sole author. Designed and implemented the framework.
- Designed the role decomposition — Planner, Coder, Debugger, Reviewer — and the message contract between them.
- Implemented the iterative loop in Python, with execution feedback routed back into the agents rather than surfaced to the user.
- Built the self-repair path: a failing test result becomes the Debugger's input instead of terminating the run.
Constraints
What the design had to work around.
- Execution feedback is the only automatic signal in the loop; there is no learned critic.
- The framework targets tasks that can be checked by running them, which is what makes automatic repair possible at all.
Architecture
Models, tools, state, evaluation, and the paths the system takes when something fails.
01 · Intake
02 · Build
03 · Check
04 · Accept
Debugger agent → Coder agent— failure diagnosis → repair attemptReviewer agent → Planner agent— rejected work → re-plan
- State
- Model
- Storage
- Tool
- Human control
Text description of this diagram
A requirement enters the system and the Planner agent decomposes it into tasks. The Coder agent writes code against those tasks into a shared working repository. That code is executed and tested; the execution result is the loop's ground-truth signal. When execution fails, the Debugger agent reads the failure and hands a diagnosis back to the Coder agent, which attempts a repair — this is the self-repair path and it runs without human input. When execution passes, the Reviewer agent evaluates the work; if the Reviewer rejects it, control returns to the Planner for re-planning. Accepted work leaves the loop as tested software, with a human check at the end rather than at every step.
Evaluation
Fields marked Not reported are absent from the source material. They are listed rather than dropped so the gaps in the evidence stay visible.
- Architecture
- Four specialized agents — Planner, Coder, Debugger, Reviewer
- Feedback signal
- Execution and test results, routed back into the loop
- Reported outcome
- Converts high-level requirements into non-trivial, tested software with minimal human intervention
- Benchmark / task suite
- Not reported
- Baseline or comparator
- Not reported
- Success rate
- Not reported
- Model versions
- Not reported
Results
The framework takes a high-level requirement and produces non-trivial, tested software with minimal human intervention. That is a demonstration, not a measurement.
- The contribution is the architecture and the case study: a working loop in which execution feedback drives automatic repair.
- No benchmark, baseline, or success rate is reported in the paper, so no comparative claim is made here.
Failure modes and limitations
What this work does not establish, and where it stops being reliable.
- There is no comparative benchmark. Nothing here establishes that the four-agent loop outperforms a single-agent baseline — that comparison has not been run.
- No task suite or success rate is reported, so the demonstrated capability cannot be quantified from the published material.
- Automatic repair depends on tasks being checkable by execution. Work whose correctness cannot be run is outside the loop's reach.
- Model versions are not reported, so results may not reproduce across model updates.
Artifacts
Building an agent that must work outside the demo?
I work on evaluation, grounded tool use, failure recovery, and auditable agent workflows.