This is what Epsilon was originally built for. Decompose a project into components, assign them to agents, build in parallel, test, QA, fix what broke, and repeat — without restarting the whole job when one component fails. The dag topology handles most projects. The tree topology scales to larger ones.
The prototype phase is easy: one agent, one task, one output. The problem starts when the project has ten components that need to coexist, some of which depend on others, and any one of them might fail tests and need a fix cycle. Without infrastructure for decomposition, parallel execution, and targeted retries, you end up babysitting a single agent through a sequential process that could take hours.
The workflow maps a project spec to a dependency graph, executes independent components in parallel, and loops on failures until QA passes. For larger projects, the tree topology adds team-level isolation via git branching.
An agent reads the project specification and produces a component graph: what needs to be built, what each component depends on, and what can be built in parallel. For a REST API, this might mean: data models, database layer, business logic, API handlers, tests, and documentation — with explicit dependency edges between them.
AgentComponents with no unresolved dependencies are dispatched immediately. As each dependency completes and writes its output to the shared workspace, components waiting on it are unblocked. Multiple agents work simultaneously — the data model and the test scaffolding can be built at the same time, since neither depends on the other.
Agent — parallelOnce all components complete, a test runner executes the test suite. This is a plain function call — run the tests, collect pass/fail results per component, write results to the workspace. No LLM needed here.
Function callA QA agent reads the combined codebase and the test results, then makes a judgment call: does this actually work as a system? It checks for integration issues that unit tests miss — API contracts that don't match, missing error handling at boundaries, inconsistent naming. It produces a structured QA report with pass/fail status and specific issues.
AgentComponents that failed tests or QA are re-assigned to agents with the failure context: the error message, the QA notes, the relevant section of the workspace. Only the failed components are fixed — the parts that passed are not touched. This is the core of Epsilon's dag topology: structured failure with targeted retries.
Agent — targeted retryThe build-test-QA-fix loop repeats until all components pass. For large projects using the tree topology, sub-teams each have their own workspace branch. When a sub-team's component passes, it gets merged. The tree handles integration across sub-teams without any one agent needing to hold the full project in context.
QA loopWhen a component fails, Epsilon doesn't restart the whole run. It knows which step failed, what depended on it, and what's safe to reuse. Fix cycles touch only what broke. On a 15-component project, fixing two failing components doesn't re-run the other 13.
Every agent reads from and writes to a shared workspace directory. The workspace is the emerging codebase. There's no prompt engineering to pass code between steps — later agents just read the files earlier agents wrote. The QA agent reads the actual code, not a summary of it.
For projects too large for a single dag run — think 50+ components, multi-service architectures — switch to the tree topology. Sub-teams work in isolated git branches. Integration happens at merge points. You get team-level parallelism without coordination overhead.
The project spec is the task. Epsilon handles decomposition, parallel builds, the QA loop, and targeted retries. You get a workspace with passing tests.
# build a REST API for a task management app $ epsilon runs create --topology dag \ --task "Build a FastAPI task management service: CRUD for tasks and projects, PostgreSQL backend, JWT auth, full test suite" run_id: r-2d5e8b topology: dag status: running decomposed: 8 components dependency graph resolved building: data_models, auth_utils, db_layer (parallel) # check progress $ epsilon runs get r-2d5e8b complete: data_models, auth_utils, db_layer running: api_handlers, test_suite queued: integration_tests, docs, qa_review qa_result: pending (loop 1 of max 3) qa_result: failed issues: 2 api_handlers: missing error handling on 404 paths db_layer: connection pool not released on exception fix cycle 1: reassigning 2 components qa_result: passed all tests green artifacts: workspace/ # larger project: use tree topology with git branching $ epsilon runs create --topology tree \ --task "Build a multi-service e-commerce platform: catalog, cart, checkout, notifications" run_id: r-5a1c9f topology: tree status: running sub-teams: 4 branches: feature/catalog feature/cart ...