I built this because I was curious whether coding agents could handle a whole development loop instead of answering one prompt and leaving me to coordinate everything else.
← Back to all work
Engineering case study · AI Systems Engineering · 2026
CodeFlow Agent
A graph-managed development agent that separates planning, implementation, QA, and review into specialist roles with explicit handoff conditions. The graph structure makes control flow and retry logic inspectable.
Central idea
What this system investigates.
Specialized agents need observable handoffs and explicit verification conditions, not just a long chain of prompts.
Problem
Why this system exists.
AI coding tools typically help with a single prompt and leave the developer to coordinate planning, implementation, tests, and review manually. The interesting question is what happens when those handoffs become an explicit, stateful system with defined verification conditions between each stage.
System architecture
How the system is organized.
- Analyze request
- Plan work
- Implement change
- Run QA
- Review output
- Prepare delivery
Implementation
Methods and engineering choices.
Specialized agents share graph-managed context and are assigned narrow responsibilities across the development lifecycle. Execution and verification are treated as separate stages so generated changes can be challenged before delivery. The graph structure makes retries and control flow inspectable rather than hidden inside a long, opaque prompt chain.
Results and evidence
What the current record demonstrates.
- 18-commit public repository with tests and architecture documentation covering the agent graph design
- Dedicated architect, developer, QA, reviewer, and DevOps agents with bounded, non-overlapping responsibilities
- Docker-oriented execution model and explicit project configuration for reproducible runs
- Roadmap and design documents expose planned work clearly alongside currently implemented work
Verification
Checks performed and their scope.
- Tests and explicit QA/review stages separate verification from implementation.
- Graph control flow and retry conditions are documented as inspectable system behavior.
Limitations
What this work does not yet establish.
- End-to-end reliability is still being measured.
- The first production-ready workflow is intentionally not yet generalized.
Engineering decisions
Decisions that define the model boundary.
- Used a graph so control flow and retries are inspectable and testable independently of model behavior.
- Separated reasoning roles from verification roles to prevent agents from evaluating their own output.
- Kept the project labeled in development while end-to-end reliability is still being measured and documented.
A note from the build
What stayed with me.
Splitting work into specialist roles does not automatically make it reliable. The handoffs, retry conditions and checks between stages are where much of the real engineering happens.
I learned to treat an agent workflow like software—with state, branches and failure paths—not as a chain of confident responses that will somehow end well.
Next step
What I would investigate next.
Publish repeatable demo runs with recorded completion and failure rates, and narrow the first production-ready workflow to a single, well-defined task type.
Source and related work