AnswersPublished11 sources
Why an AI coding agent should not approve its own work
The proposal organizes work around end to end tasks, with Analyst, Architect, Coder and Supervisor as changing responsibilities—not separate agents. A task contract defines the scope, inputs, deliverables and required checks, while a single task record remains the authority for status.
Published byImages generated with GPT Image 2
Research answer
Key takeaways
- The proposal organizes work around end to end tasks, with Analyst, Architect, Coder and Supervisor as changing responsibilities—not separate agents.
- A task contract defines the scope, inputs, deliverables and required checks, while a single task record remains the authority for status.
- Release requires two separate conditions: valid machine check evidence for the exact candidate and an independent review bound to that same candidate.
- The document is an engineering blueprint, not evidence that the controls have been implemented or deployed.
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W](https://d15bya8fi85z1v.cloudfront.net/chat/q56Obxge3SXqN702YfUAgiNDcqV2/images/6E24A376E76904A90134/1B133D0C9F45F4EDC443.png)
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"本草案将业务流、任务契约、实测证据和独立审查收敛为一套可机械校验的治理设计。交付仅为会话中的工程规范草案，不表示控制器已经实现、宿主已经加载规则，也不授权代码实施、目录迁移或删除历史资产。\n\n 任务按端到端业务流组织，不按角色建立物理文档目录。\n 角色切换改变工作视角，不产生新的执行权限或独立审查身份。\n. Topic tags: general web, llm, agents, ai, automation. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts wit
A coding agent can switch from planning to implementation and then review its own changes. But changing roles in a prompt does not make the final review independent—and a successful test run does not, by itself, prove that a candidate is ready to ship.
That is the central idea in a proposed governance blueprint for a “BMAD-Solo” workflow: keep the work in one end-to-end business flow, but require both machine evidence and independent approval before release. The document is a design proposal, not a report of a system already built or tested.
One workflow, four responsibilities
Rather than creating separate folders or agents for every role, the proposal treats Analyst, Architect, Coder and Supervisor as responsibilities within a single workflow. Analyst clarifies the goal and acceptance criteria; Architect freezes the design and boundaries; Coder produces a candidate; Supervisor reviews it against the agreed requirements.
The distinction matters because a role name is not a security boundary. An agent switching from Coder to Supervisor may change its perspective, but it does not become an independent reviewer. The proposal therefore calls for approval by a genuinely separate, trusted reviewer—or a separately verified review process. If that separation is unavailable, the work can be presented as a draft, but it should not be described as having passed an independent gate.
The idea responds to a wider concern in agentic software work: dividing work among agents does not automatically produce complementary contributions, and dependencies can allow local mistakes to cause broader task failures, according to the abstract for the AutoSwarm paper.1 The proposed blueprint takes a conservative approach: define responsibilities and dependencies explicitly, then check the final result against a fixed contract.
The task contract is the source of truth
Each task would have one authoritative record describing its objective, inputs, permitted changes, deliverables, dependencies, required checks and non-goals. A separate pointer could identify the active task, but would not duplicate its status. Test logs, review signatures and release records would each serve a different purpose rather than becoming competing versions of the task’s progress.
This is meant to reduce a familiar failure mode in automated workflows: a summary or checklist says “done” while the underlying evidence is missing, stale or tied to a different version of the work. The proposal says that the task record should bind checks and approvals to the exact candidate being considered. If the candidate changes, the relevant evidence and approval may no longer apply.
Two gates before release
The release rule is deliberately simple: required machine checks must pass, and an independent review must approve the same candidate. A missing result is not a pass. Neither is an agent’s own claim that tests succeeded.
Machine evidence should come from a controlled execution process and record details such as the command run, exit status, test collection, skipped cases, candidate identity and environment. The reviewer, meanwhile, should examine the change against the task’s requirements—including edge cases, failure handling, ownership boundaries and whether tests were weakened or omitted.
Even passing both gates would not automatically authorize every action. The blueprint treats permissions, dependencies and release scope as separate prerequisites: approval to assess a candidate does not automatically grant permission to merge, deploy or publish it.
A careful proposal, not a finished safeguard
The design also highlights a limitation that can be easy to overlook: editable files and local scripts cannot prove that evidence is authentic if the same actor can change the candidate, test results and approval record. The release decision needs a trusted execution and approval boundary, and downstream systems must accept only the exact candidate that was approved.
That boundary is described as something to implement and verify, not something already present. The document explicitly stops short of claiming that the controller exists, that a host application loads the proposed rules, or that any tests have passed. It also argues against automatically deleting older task records: historical material and unfinished obligations should be protected during any later migration.
The broader takeaway is practical. An AI workflow can use one model and still separate implementation from approval—but only if the separation is real, the evidence is tied to the work being released, and a trusted release mechanism enforces the decision. A prompt that says “review your work” is not a substitute for those controls.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "Why an AI coding agent should not approve its own work"?
The proposal organizes work around end to end tasks, with Analyst, Architect, Coder and Supervisor as changing responsibilities—not separate agents.
What are the key points to validate first?
The proposal organizes work around end to end tasks, with Analyst, Architect, Coder and Supervisor as changing responsibilities—not separate agents. A task contract defines the scope, inputs, deliverables and required checks, while a single task record remains the authority for status.
What should I do next in practice?
Release requires two separate conditions: valid machine check evidence for the exact candidate and an independent review bound to that same candidate.