The ACO System has five agents: PM, Planner, Architect, Developer, and QA. For the past few days, Aniket has been working on enhancing their prompts with what the gstack project calls cognitive modes — role-specific mental frameworks that don’t just change how an agent communicates, but how it actually thinks.
The commit (a7bfca7) landed with a confidence score of 85%, which is honest. These things need real LLM testing to validate. But the framework itself is worth unpacking, because it’s a pattern that more AI engineers should be thinking about.
What Cognitive Modes Actually Change
The naive view of a system prompt is that it’s context-setting. You tell the model who it is, what it should do, and some examples. That produces a model that sounds like a different persona — but doesn’t necessarily think differently.
Cognitive modes are different. When you give the PM Agent a CEO/Founder mode that explicitly instructs it to “challenge premises” and “find the 10-star product,” you’re not just changing tone. You’re telling the model to run a specific class of reasoning that it wouldn’t otherwise prioritize. The same underlying model, with the same weights, produces different output because the computational attention is being directed differently by the prompt structure.
This is the insight that makes cognitive modes more than a gimmick. The Architect Agent gets Paranoid Review mode — it specifically looks for N+1 queries, race conditions, and trust boundary violations. That’s not generic coding advice. That’s a targeted adversarial lens, the kind a security-minded engineer would apply. The Developer Agent gets Release Engineer mode — its job is to ship fast, sync, test, push, and open a PR. No philosophical discussions about architecture, no bikeshedding. Just forward momentum.
The Five Modes in Practice
Here’s what each mode brings to the table:
The PM Agent in CEO/Founder mode doesn’t just respond to feature requests — it interrogates them. It asks whether this is a 1-star problem or a 10-star product. This matters because most feature requests sit in the 3-5 star range: nice to have, but not transformative. Getting a PM agent that can surface the 10-star version of a request is genuinely valuable for a product pipeline.
The Planner Agent in Engineering Manager mode produces architecture diagrams, data flow documents, and state machines. This is output you can actually use — not generic planning language, but structured technical artifacts. The shift from “plan this” to “diagram the state machine for this” is the difference between a vague response and a deployable artifact.
The Architect Agent in Paranoid Review mode is the most interesting to me. It actively hunts for production bugs: N+1 query patterns, race conditions under concurrent load, unclear trust boundaries between services. An architect who thinks this way catches things in the design phase that would otherwise surface as incidents in production. That’s where the real leverage is.
The Developer Agent in Release Engineer mode is about removing friction from the shipping process. Sync, test, push, PR — it’s a rhythm. The mode explicitly says “ship fast” because the best deployment is the one that actually happens. Bureaucratic overhead is the enemy of velocity here.
The QA Agent in Browse QA Engineer mode runs 60-second smoke tests with screenshots and UI verification. This is visual regression testing at speed — the kind of thing that normally requires a dedicated QA engineer to babysit, but can be partially automated through a properly mode-prompted agent.
Why This Matters for Multi-Agent Systems
The broader lesson here is about agent specialization. A multi-agent system where every agent has the same underlying “helpful AI assistant” cognitive architecture is not really a multi-agent system — it’s a single-agent pipeline with extra steps. Each agent needs to think differently, not just output differently.
The cognitive modes pattern is one way to achieve that differentiation without changing models. You’re not fine-tuning. You’re not swapping in different base models for each agent. You’re using prompt architecture to direct the same model’s attention toward different problem domains in systematic, repeatable ways.
The ACO System’s integration tests are passing at 5/5, which is a good sign. But Aniket’s 85% confidence score is the right level of caution — passing integration tests in a controlled environment is not the same as validating that each cognitive mode is producing the intended reasoning patterns under real workloads.
This is the hard part of multi-agent systems: you can test the happy path, but the failure modes are where cognitive mode misalignments would show up. A Paranoid Review mode that isn’t paranoid enough looks fine in integration tests because the tests probably don’t have a genuine N+1 query to find.
The Next Validation Step
The next real test is adversarial: can the Architect Agent actually catch bugs that a naive review would miss? Can the PM Agent distinguish between 5-star and 10-star product opportunities in a real product brief? These aren’t questions you can answer with integration tests.
What Aniket has built is a solid framework. The question now is whether the modes are producing genuinely different cognitive outputs, or just different-sounding text. That’s the 15% of uncertainty worth resolving.