The Self-Building Agent: A LangChain4j Experiment
Kevin Dubois, Mario Fusco · rss · 2026-07-24 source ↗ Reader 🖥️
In a controlled experiment where a code assistant designed and rebuilt its own multi-agent coding system, replacing an autonomous LLM-driven supervisor architecture with a deterministic, pre-declared workflow architecture cut end-to-end task time roughly threefold by eliminating LLM-induced coordination overhead, establishing a concrete speed-versus-autonomy trade-off between the two patterns.
practical · mixed — An experience-report narrative (a code assistant designs and rebuilds its own multi-agent system, tested against real buggy code) that closes with an explicit argumentative/prescriptive conclusion (when to choose which architectural pattern).
Structure
| Part | Role |
|---|---|
| Opening bullet summary | hook / thesis preview |
| "Vibe Coding" an Agentic System | narrative setup |
| Putting the Agentic Coder to Work | empirical test #1 |
| From Supervisor to Workflow | empirical test #2 (comparative) |
| Conclusions | synthesis / prescription |
Key terms
- Supervisor pattern
A LangChain4j agentic-framework pattern where one root agent (annotated @SupervisorAgent) autonomously decides, at runtime and via the LLM, which sub-agent to invoke next and what arguments to pass, without a pre-scripted call sequence. - Workflow pattern
A LangChain4j agentic pattern (composed of SequenceAgent and LoopAgent) that declares the agent-to-agent control flow as a fixed, deterministic sequence of steps, with optional bounded iterative loops, authored in advance rather than decided by an LLM at runtime. - MonitoredAgent
A new LangChain4j interface (introduced in version 1.12.2-beta22) that, when extended by the root agent interface, automatically produces an execution-trace report of agent invocations and the system's topology, with no additional instrumentation code. - Tool-calling loop (exceeding max round trips)
A failure mode where an LLM-driven agent repeatedly invokes tools without reaching a terminating condition, caught only by LangChain4j's configurable default cap of 100 sequential tool invocations (AiServices.maxToolCallingRoundTrips()); observed with gpt-4o in this experiment. - "Vibe coding" an agentic system
Letting the LLM code assistant autonomously design and implement the multi-agent system directly from documentation and a single prompt, with the humans testing/observing the result rather than authoring the architecture — applied self-referentially here (the assistant clones its own operating pattern).
Propositions
- explicitA code assistant, given only LangChain4j's documentation and source code and a single instruction to "design an agentic coder based on it that is a clone of yourself," autonomously designed and implemented a multi-agent coding system modeled on its own operating pattern (explore, plan, implement, execute) — evidencing at least implicit self-knowledge of its own internal workflow.conf: high
- explicitThe self-built supervisor-based agentic coder, when run with a sufficiently capable model, successfully fixed four deliberately introduced bugs in a Calculator class (off-by-one loop bounds, integer-division truncation, wrong max initialization, off-by-one factorial) and passed all 11 unit tests.conf: high
- explicitIn a head-to-head comparison on the identical bug-fix task, the workflow (fixed-sequence) architecture completed the task about three times faster than the supervisor (autonomous) architecture — roughly two minutes versus more than six minutes — because the workflow eliminates the LLM-induced coordination overhead of a supervisor that must autonomously decide, at runtime, which sub-agent to invoke next and with what arguments.conf: highextendsThe Anatomy of an Agent Harness · p10 — Adds a second, independent empirical data point (LangChain4j supervisor-vs-workflow, ~3x) for the same general effect the harness-anatomy piece cites via LLMCompiler's ~3.6x ReAct-vs-plan-and-execute speedup: removing dynamic, LLM-decided step-by-step coordination in favor of a pre-planned/declared execution path yields a large, similarly-sized speedup.supportsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p13 — The measured 3x speedup from replacing supervisor coordination (LLM-decided at runtime) with workflow coordination (framework-enforced SequenceAgent/LoopAgent) is a concrete before/after case supporting the claim that declarative, framework-enforced coordination beats LLM-driven coordination expressed in prompts.
- explicitThe workflow pattern is preferable when efficiency, speed, and predictability matter and the task decomposes into predefined sequential stages (optionally with bounded iterative-refinement loops); the supervisor pattern is preferable when autonomy and dynamic flexibility are prioritized over execution speed, at the explicit cost of being "significantly slower" due to its coordination overhead.conf: high
- explicitThe identical agent architecture and task failed with the older/default model (gpt-4o) — entering a tool-calling loop that exceeded LangChain4j's default cap of 100 sequential tool invocations — and succeeded, with no code changes, when the model was swapped to a newer one (gpt-5-mini), showing the same harness's outcome is model-dependent.conf: highextendsDon't train the model, evolve the harness · p5 — Extends the harness-vs-model-transfer finding with a more extreme case: the identical multi-agent harness and task goes from complete failure (unbounded tool-calling loop) to full success purely by swapping the underlying model, with zero changes to the harness itself.
- explicitLangChain4j's new MonitoredAgent interface makes an agentic system's invocation history and topology directly inspectable — without requiring the developer to write instrumentation code — simply by having the root agent interface extend MonitoredAgent.conf: high
- implicitThe workflow implementation's execution topology, despite containing more agents and edges than the supervisor's (five pipeline stages including two internal loops, versus four flat sub-agents), still executed faster overall — indicating that node/edge count in an agent topology is a poor proxy for wall-clock cost compared to whether coordination decisions are made by an LLM at runtime versus pre-declared.conf: medium
- implicitLangChain4j's agentic-framework API is legible and complete enough that an LLM can read its documentation and source code and independently produce a working, non-trivial multi-agent system without human architectural guidance beyond the initial one-sentence prompt.conf: high
- explicitConverting the system from a supervisor to a workflow architecture required making the supervisor's previously implicit summarization responsibility explicit as a dedicated SummarizerAgent pipeline step — moving from an autonomous to a deterministic architecture forces implicit sub-tasks to become named, ordered steps.conf: high
- explicitThe workflow's execution loop bounds iterative self-refinement with both a quality gate (evaluation score greater than or equal to 0.8) and a hard cap (maximum 5 iterations), explicitly trading potential further correctness for bounded runtime and token cost.conf: high
Arguments
Choose the workflow pattern over the supervisor pattern when execution speed, efficiency, and predictability matter, because forcing agent coordination into a fixed, framework-enforced sequence rather than leaving it to LLM-driven runtime decisions removes a large, measured overhead cost. strength: medium
Explicit premises:
- The workflow-based implementation completed the identical bug-fix task in about two minutes versus more than six minutes for the supervisor-based implementation (roughly 3x faster).
- The only architectural difference the authors attribute the gap to is how coordination is decided: the supervisor autonomously generates each sub-agent invocation and its arguments at runtime via the LLM, while the workflow follows a pre-declared SequenceAgent/LoopAgent structure.
- Both implementations reached the same correct outcome (all 11 tests passing) on the same buggy Calculator code.
Implicit premises:
- Runtime differences between two implementations that reach the same correct output and differ mainly in one architectural dimension can be attributed to that dimension.
- LLM reasoning about "what to call next and with what arguments" costs measurably more wall-clock time than executing a pre-declared call graph.
Inferences:
- A same-task, same-code-assistant, same-underlying-agents-where-reused before/after comparison is treated as isolating the coordination mechanism as the causal variable for the speed difference.
The same agentic architecture and prompt can flip from complete failure to full success purely by swapping the underlying LLM, with no change to the agent code, tools, or task. strength: low
Explicit premises:
- With gpt-4o, the supervisor-based system entered a tool-calling loop and was terminated after exceeding the 100-invocation cap.
- With gpt-5-mini, the identical system (same agents, same Calculator bug-fix task) completed successfully, fixing all bugs and passing all 11 tests.
Implicit premises:
- No variable besides the model changed between the two runs (prompt, agent code, tools, and task were held constant).
- gpt-5-mini's improved tool-calling/reasoning behavior, rather than run-to-run stochastic variance, explains the outcome difference.
Inferences:
- A single before/after model swap with one variable changed is treated as demonstrating a categorical model-capability difference.
Narratives
- The authors prompt a code assistant to study LangChain4j and design an agentic coder that clones its own architecture; the self-built system first fails with one model and succeeds with another on a buggy Calculator class, and is then redesigned from an autonomous supervisor into a deterministic workflow to compare speed and topology.
→ Carries every claim in the article through one continuous, concrete running example (the Calculator bug fix) rather than abstract description, letting the reader watch the same task move through four experimental variants: supervisor+gpt-4o (failure), supervisor+gpt-5-mini (success, with topology trace), and workflow+gpt-5-mini (success, faster, with a different topology trace).
Questions addressed
- ✅ Can an LLM-based code assistant design and implement a working multi-agent coding system for itself, given only a framework's documentation?
Yes — the assistant produced a supervisor-based system with four coherent sub-agents (Explorer, Planner, Implementer, Executor) that, run with a capable enough model, successfully fixed real bugs and passed all tests. - ✅ Which architecture is faster: an autonomous supervisor-coordinated multi-agent system, or a fixed workflow/sequence-coordinated one?
The workflow pattern was measured at roughly 3x faster (about 2 minutes vs. more than 6 minutes) on the identical task, attributed to eliminating the LLM-induced coordination overhead of the supervisor's runtime dispatch decisions. - ✅ Does model choice matter for whether an agentic tool-calling system completes its task or gets stuck?
Yes — the identical architecture and prompt entered an unrecoverable tool-calling loop with gpt-4o but completed successfully with gpt-5-mini. - ✅ Is the workflow pattern's determinism a strict improvement over the supervisor pattern, or a genuine trade-off?
The article explicitly frames it as a trade-off, not a strict win: choose workflow when speed/predictability/efficiency dominate; choose supervisor when autonomy and dynamic flexibility matter more than execution speed. - ⭕ How reliable or repeatable is the reported ~3x speed difference, or the gpt-4o failure — were these single runs, or averaged over multiple trials, given that LLM agent behavior is inherently stochastic (as the article's own gpt-4o-vs-gpt-5-mini episode already demonstrates)?
Gaps
- incompleteThe headline 3x speed comparison (2 minutes vs. more than 6 minutes) appears to be reported from a single run of each architecture on one bug-fix task, with no repeated trials, variance/error bars, or statistical treatment — despite the article's own earlier episode showing that the very same supervisor design can fail outright (gpt-4o tool-calling loop) or succeed (gpt-5-mini) depending on run conditions, which is direct in-article evidence that these systems' behavior and timing are not fully deterministic run to run.
Read next: Read alongside the LLMCompiler ReAct-vs-plan-and-execute speedup (reported as ~3.6x in extract-anatomy-of-an-agent-harness#p10) and any papers reporting variance/repeated-trial data for tool-calling agent latency, to judge whether a ~3x supervisor-vs-workflow gap is a robust effect size or an artifact of one measured run each. - incompleteThe article attributes gpt-4o's tool-calling-loop failure to it being an "older, less advanced" model but never rules out simpler alternative explanations — an agent/tool design that happens to interact badly with gpt-4o's specific tool-calling format or default parameters, a transient API issue, or the 100-invocation cap being miscalibrated for this particular task graph — before crediting the fix entirely to "the newer model."
Read next: Compare with harness-vs-model attribution findings, e.g. extract-dont-train-evolve-harness#p5 on how much of an observed capability gain is harness-transferable versus genuinely model-specific, before accepting that a model upgrade alone explains the fix. - incompleteThe article never reports token consumption or dollar cost for either architecture, despite explicitly citing "excessive LLM calls and token usage" as the reason for capping the workflow's execution loop at 5 iterations — so the reader cannot tell whether the workflow's wall-clock speed advantage also translates into a token/cost advantage, or whether the supervisor's extra time is spent on cheap idle waiting versus expensive extra LLM calls.
Read next: Read alongside any cost-accounting treatment of agent architectures (e.g. token-cost-per-task benchmarks) to see whether speed and cost move together or diverge between supervisor- and workflow-style coordination.
Related documents
- The Production Gap: 5 Patterns for Building Long-Running AI Agents
- Looking back at the Future of Software Engineering unconference
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- Jacob Langvad Nilsson's Post
- 11) AI-spesial med Vilde Opsal og Anders Sveen
- Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE
- Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch
- 20 Loop Design Patterns Every AI Engineer Should Know
- Agent Harness Engineering
- Have your agent record video demos of its work with shot-scraper video