Architect agent
The Architect agent plans changes, scopes risk, merges review findings and makes go/no-go calls. It runs in ten of the sixteen built-in workflows.
The Architect agent is the planner of an AI CodeOps session. It turns a task into a concrete approach: the files and modules to change, the key decisions and trade-offs, and the risks. In review workflows it has a second job: it reads what the other agents found and merges it into one answer.
It is the most used agent on the platform. It runs in ten of the sixteen built-in workflows, and in Architecture Debate it runs three times.
Where it runs
| Workflow | Step |
|---|---|
| Plan, Build, Review & Test | Plan |
| Security-Sensitive Change | Scope change |
| Parallel Review | Merge findings |
| Architecture Debate | Architect A, Architect B, Final synthesis |
| Threat Model | Scope & data-flow |
| Swarm Inspection | Merge summary |
| Feature SDLC | Technical design |
| Release Readiness | Go / no-go |
| Incident Response | Root cause |
| Performance Tuning | Optimization plan |
Inputs
- The task you wrote when you started the session.
- A read-only snapshot of relevant files from the project's repository, when the project has one.
- The output of the earlier steps in the same session. When it runs first, it has only the task and the code.
- Tools from MCP servers your workspace has connected, if your workspace policy allows them.
Outputs
The Architect returns text: a plan, a design, a merged summary or a decision, depending on the step. Two of these outlive the session:
- In Plan, Build, Review & Test and Performance Tuning, its plan is synced to the workspace plan board as plan items.
- In Architecture Debate, its Final synthesis is saved as a proposed Architecture Decision Record (ADR). It is never accepted automatically. A person accepts or rejects it.
When a session runs on the platform's models with the Auto tier, the Architect's steps go to the Premium tier first, because its output steers every step after it. See models and tiers.
Example run
Illustrative example, not a recorded session. Matt starts Plan, Build, Review & Test with the task "add rate limiting to the public login endpoint". The Architect reads the auth routes in the snapshot. It proposes a fixed-window limiter keyed by IP address and account, names the middleware file to add and the two route files to touch, and decides to answer with HTTP 429 and a Retry-After header. It flags one risk: a shared office IP could lock out a whole team. The Builder, Reviewer and Tester then work from that plan, and its steps appear on the plan board.
Limits
- It reasons from the code it is shown. It does not run the code, profile it or read production data.
- In Release Readiness its go/no-go is advice. What actually holds a change is the release gate: tests, the findings review and approvals.
- In long workflows, earlier steps reach it in shortened form, so very long outputs lose detail.
- A plan is only as good as the task. A vague task gets a generic plan.
Frequently asked questions
Does the Architect agent write code?
No. It writes a plan or a decision in text. The files are written by the session's code pass after every step has finished, with the plan as part of its input.
Can I change how the Architect agent behaves?
Yes. Create a custom agent named Architect on your workspace's Agents page to replace its instructions or run it on a different model.