Let us develop a small feature in Flutter and find out how an orchestrator leverages these roles.<\/p>\n
![\"A](\"https:\/\/tothenewone.online\/blog\/wp-ttn-blog\/uploads\/2026\/09\/multi-agent-sdd-workflow-v2-1024x576.png\")
The orchestrator manages the flow; specialised agents produce evidence, and humans retain approval.<\/em><\/p><\/div>\n The raw request is intentionally simple:<\/p>\n Let users download an article and read it later without an internet connection.<\/p><\/blockquote>\n It is sent directly to the coding agent and this introduces hidden decisions around download limits, duplicates, persistence and storage failure. Rather, the orchestrator takes the feature through the five roles below.<\/p>\n The Orchestrator Agent acts as the traffic controller. It assigns each role its packet that holds the feature ID, spec version, approved inputs, allowed operations, output format and criteria for when to stop. It validates the output, logs it and forwards it to the next role. If the Product Agent has a question that was left unresolved, the orchestrator stops the work and seeks input from humans. If QA identifies a missing criterion, it does not refer the issue to the builder but forwards it back to Product. It cannot alter the scope, architecture choice or merge decision.<\/p>\n The Product Agent does not choose a database or write Dart. Its job is to remove ambiguity and produce acceptance criteria.<\/p>\n Prompt:<\/strong><\/p>\n Act as a product analyst. Convert the requirement into numbered, testable acceptance criteria. Identify missing decisions and edge cases. Do not propose implementation details.<\/em><\/p><\/blockquote>\n After a human answers the open questions, the shared spec might contain:<\/p>\n feature: Offline Article Saving This is the first human checkpoint. Product approves the behaviour before any architecture is designed.<\/p>\n The Architecture Agent receives the approved spec and project conventions, then produces a short decision record.<\/p>\n Prompt:<\/strong><\/p>\n Design the smallest solution that satisfies OFF-01 to OFF-04.<\/em> A useful response would define:<\/p>\n The agent may recommend SQLite or the existing local store, but a developer approves the choice.<\/p>\n The Builder Agent now has fewer decisions to invent. It receives the approved spec, architecture note, project rules, and the exact files it may modify. Here is the core business logic in Dart:<\/p>\n Prompt 1 sample code<\/em><\/p><\/div>\n The comments are intentionally tied to requirement IDs. They make reviews searchable and help the next agent connect code with expected behaviour.<\/p>\n The QA Agent receives the spec and public behaviour, then searches for tests that would expose a wrong implementation.<\/p>\n Prompt:<\/strong><\/p>\n Create tests for every requirement ID. Prioritise boundaries, persistence,<\/em> For `OFF-03`, a useful test checks both sides of the limit:<\/p>\n Test Case code example<\/em><\/p><\/div>\n QA may also flag that the service catches every error, including programming errors. That deserves review.<\/p>\n The Reviewer Agent receives the spec, architecture decision, code diff, and test results. It should not silently \u201cimprove\u201d the implementation. Its job is to return evidence. A concise review might look like this:<\/p>\n OFF-01: PARTIAL \u2014 persistent store selected, restart test missing This report is far more useful than \u201cthe implementation looks good.\u201d A human reviewer can see what is proven, what is assumed, and what must happen before merge.<\/p>\n Multi-agent development is not five chat windows discussing a feature endlessly. Each role needs a clear input and a limited output:<\/p>\n Store artifacts beside the code. Every handoff includes the spec version and requirement IDs, so agents use approved files rather than remembered chat history.<\/p>\n Start with one feature in a shared repository. Create spec.yaml, architecture.md, test-report.md, and review.md. Give each role its own agent session and instructions; allow the Builder to edit code, while Product, Architect, QA, and Reviewer initially write only their own artifacts. The orchestrator reads the files and routes work, but does not edit the spec or code.<\/p>\n Use OFF-01 to OFF-04 as the only approved requirements. 2. Let it ask Product for the spec, then pause for human approval.<\/p>\n 3. Route the approved spec to Architecture, then Builder and QA.<\/p>\n 4. Let Reviewer compare every artifact and test result.<\/p>\n 5. Merge only after a person resolves the review findings.<\/p>\n Now run one feature sequentially. Product writes spec.yaml; a person resolves its questions and marks it approved. Architect proposes storage and state management; a developer accepts or revises that Keep each handoff short: version, requirement IDs, artifact, evidence, open questions, and status. If OFF-03 changes from 20 to 50, increment the spec version and rerun affected roles. Do not let agents use old chat messages as authority. Once this manual workflow is dependable, automate routing, keep human approval gates.<\/p>\nOur feature: Save an article for offline reading<\/h1>\n
The Orchestrator: Manage the flow, not the decisions<\/h1>\n
1. Product Agent: Turn the idea into observable behaviour<\/strong><\/h2>\n
\nrequirements:
\n– id: OFF-01
\nrule: A saved article is readable after the app restarts.
\n– id: OFF-02
\nrule: Saving the same article again must not create a duplicate.
\n– id: OFF-03
\nrule: A user can store no more than 20 articles.
\n– id: OFF-04
\nrule: A storage failure shows a retry action without losing the screen state.
\nout_of_scope:
\n– synchronising downloads between devices<\/p><\/blockquote>\n2. Architecture Agent: Design within real constraints<\/h2>\n
\nFollow the existing repository pattern. Keep storage replaceable and<\/em>
\nbusiness rules testable without Flutter widgets. List risks and trade-offs.<\/em><\/p><\/blockquote>\n\n
3. Builder Agent: Implement against requirement IDs<\/h2>\n
![\"Prompt](\"https:\/\/tothenewone.online\/blog\/wp-ttn-blog\/uploads\/2026\/09\/Screenshot-2026-09-18-at-11.35.19-PM-300x294.png\")
4. QA Agent: Attack the boundaries<\/h2>\n
\nduplicate actions, and failures. Report any criterion that cannot be proven.<\/em><\/p><\/blockquote>\n![\"Test](\"https:\/\/tothenewone.online\/blog\/wp-ttn-blog\/uploads\/2026\/09\/Screenshot-2026-09-18-at-11.35.30-PM-300x107.png\")
5. Reviewer Agent: Compare, do not rewrite<\/h2>\n
\nOFF-02: PASS \u2014 duplicate path avoids store.put
\nOFF-03: PASS \u2014 boundary test covers exactly 20 items
\nOFF-04: PARTIAL \u2014 failure result exists, retry UI test missing
\nArchitecture: CONCERN \u2014 broad catch may hide unexpected defects
\nDecision required: developer review<\/p><\/blockquote>\nThe handoff contract matters more than the agents<\/h1>\n
\n\n
\n Role<\/strong><\/td>\n Reads<\/strong><\/td>\n Produces<\/strong><\/td>\n Must not do<\/strong><\/td>\n<\/tr>\n \n Orchestrator<\/td>\n Status and approved artifacts<\/td>\n Work packets and audit trail<\/td>\n Make product or technical decisions<\/td>\n<\/tr>\n \n Product<\/td>\n Raw requirement<\/td>\n Acceptance criteria<\/td>\n Choose technology<\/td>\n<\/tr>\n \n Architect<\/td>\n Approved spec, project rules<\/td>\n Design decision<\/td>\n Change product scope<\/td>\n<\/tr>\n \n Builder<\/td>\n Spec and design<\/td>\n Code<\/td>\n Invent missing behaviour<\/td>\n<\/tr>\n \n QA<\/td>\n Spec and interfaces<\/td>\n Tests and gaps<\/td>\n Weaken criteria to pass<\/td>\n<\/tr>\n \n Reviewer<\/td>\n All artifacts and results<\/td>\n Evidence report<\/td>\n Approve on behalf of humans<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n How to start your first multi-agent environment<\/h1>\n
\n
\nRun Product \u2192 human approval \u2192 Architect \u2192 human approval \u2192
\nBuilder \u2192 QA \u2192 Reviewer \u2192 human merge decision.
\nFor each handoff, record the spec version, changed files,
\nevidence, open questions, and next owner. Stop if an answer
\nwould change scope; ask a human. Retry a failed task once.<\/p><\/blockquote>\n
\ndecision. Builder implements against those two approved files. QA writes tests and records gaps. Reviewer checks the spec, code diff, and test results. The orchestrator sends gaps back to the relevant role, then
\nstops for a human merge decision.<\/p>\nReferences:<\/h1>\n