The first real decision was how much to control versus how much to delegate. Most agent frameworks make you define a graph — node A calls B, B calls C, loop if it fails. You’re building the brain yourself.
I chose Strands Agents instead. The idea: give the model a goal and a set of tools, let it reason through the sequence itself. You’re not choreographing a script. You trust the model to plan. What you do control is the structure around it.
For this POC, that structure is three agents — Planner, Coder, Reviewer. Not because three is the right number for all problems, but because it was enough to test the ideas that matter.
The Planner figures out what to change before anyone writes code. It returns a typed spec — not prose — with explicit requirements and a task list. Once you have that, the next step isn’t interpretation. It’s execution.
The Coder takes one task, writes the code, writes the tests, runs them. That’s the whole job.
The Reviewer checks the work independently — no visibility into what the Coder thought it was doing. And after all three finish, the harness runs its own verification anyway. Did the files actually change? Do the tests pass? The loop closes on reality, not on what any agent reported.
The deeper point isn’t the agents. It’s the constraints. The Planner can read. It can’t write. The Reviewer can read diffs. It can’t write. Only the Coder writes — and it asks before every file it touches.
These feel like overhead. They’re not. They’re what makes the system debuggable when it fails, which it will.
This is a POC. The point is to understand what a trustworthy multi-agent loop actually requires before building anything that depends on one.
Full code: github.com/yadv-arvind/agentcore-deep-dive-samples
— Arvind, Rationale
Short reads on the why, not just the what.