Aniket pushed a commit to the ACO System workspace on March 13, 2026. The message was modest: feat: enhance ACO system prompts with gstack wisdom. The diff was not. Five agent prompts — PM, Planner, Architect, Developer, QA — each received a distinct cognitive mode drawn from real engineering disciplines. The PM Agent got CEO/Founder thinking: challenge premises, find the 10-star product vision. The Architect got Paranoid Review: hunt for N+1 queries, race conditions, trust boundary violations. The Developer got Release Engineer mode: ship fast, sync, test, push, PR.
This is not a prompt engineering trick. It’s an architectural statement about what multi-agent pipelines actually need.
Why Generic Capability Isn’t Enough
A capable language model can write code, review architecture, and plan features. The SWE-bench Verified score of 87.6% on Claude Opus 4.7 tells you the model can handle these tasks in isolation. But a multi-agent pipeline doesn’t run tasks in isolation — it runs them in sequence, with each agent producing outputs that become the next agent’s inputs.
The failure modes in that setting aren’t about whether an agent can do the task. They’re about whether the agent’s output is shaped for the next stage in the pipeline.
A PM agent that outputs a loose user story with business context is useful for human stakeholders. It’s nearly useless for a Planner agent that needs architecture diagrams, data flow definitions, and explicit state machines. The two outputs require completely different cognitive postures. The PM agent needs to think like a CEO — what problem are we solving, why does it matter, what does the customer actually need? The Planner agent needs to think like an engineering manager — given this problem, what does the system look like, what are the data shapes, where does state live?
The ACO commit added exactly this shaping. The PM Agent prompt now explicitly invokes CEO/Founder cognitive mode. The Planner Agent prompt invokes Eng Manager cognitive mode with explicit instructions for architecture diagrams. Each agent’s output is now pre-shaped for consumption by the next stage.
The Paranoid Architect Pattern
The Architect Agent’s upgrade is the most instructive. The new system prompt adds Paranoid Review mode — actively hunting for N+1 query patterns, race conditions in concurrent operations, and trust boundary violations across service interfaces.
This is a specific, named failure mode that every senior engineer has encountered. An N+1 query happens when a system loads a list of records, then makes one database query per record to fetch related data. It’s a classic performance anti-pattern that a code-generating model will reliably produce unless specifically prompted to detect it. Race conditions between concurrent agent writes are exactly the problem that git_sync in markdown-vault-mcp tries to solve — and that problem only surfaces when two agents are operating on the same repository simultaneously.
The Paranoid Architect cognitive mode isn’t about making the Architect “more thorough.” It’s about making it produce outputs that have already survived a specific class of production failures. An Architect operating without paranoid mode will produce a technically correct architecture that fails under concurrent load. An Architect operating with paranoid mode flags the trust boundary between the payment service and the notification service before the first line of code is written.
The Release Engineer Mode
The Developer Agent received the most operationally specific upgrade: Release Engineer mode. The instruction set is explicit about the workflow — ship fast, sync, test, push, PR. Not “write good code” or “follow best practices.” The actual sequence of operations that moves a change from a local branch to a merged PR.
This matters because the gap between “code written” and “code shipped” is where most multi-agent pipelines fall apart. An agent that writes clean, passing unit tests but doesn’t know how to handle a rebasing conflict with a human’s concurrent commit is not a production-ready Developer agent. It’s a code generator with aspirations.
Release Engineer mode makes the Developer agent handle the actual git workflow: force-push when the local branch is stale, force-pull when the remote has diverged, create the PR with the correct metadata, and handle the case where the branch name conflicts with an existing one. These are not generic capabilities. They are specific git operations with specific failure branches and specific recovery strategies.
What This Means for the Pipeline
The ACO pipeline — PM → Planner → Architect → Developer → QA → Human Review — is only as strong as the translation between each stage. A PM agent that thinks like a CEO produces user stories that a Planner agent working like an engineering manager can actually break down into technical tasks. An Architect that thinks like a paranoid reviewer produces designs that have already survived production failure mode analysis. A Developer that thinks like a release engineer ships PRs that QA can actually test.
The benchmarks for individual agents keep improving. Claude Opus 4.7 at 87.6% SWE-bench Verified is a genuine achievement. But the multi-agent pipeline isn’t measured by a single benchmark — it’s measured by how often a complete human-requested feature makes it from issue description to merged PR without a human intervention to unstick a stage.
The cognitive mode pattern is a bet that the answer to that question lives in prompt design, not model capability. You don’t need a smarter model. You need the right mental model for the job.