Architect

#What the Architect owns

The Architect is the agent responsible for cross-cutting decisions — the kind that ripple across multiple subsystems and where getting it right early is much cheaper than fixing it later. It runs during plan review and is the primary author of ADRs and RFCs.

The Architect's scope:

• Implementation plan review. During /synthex:write-implementation-plan/synthex:write-implementation-plan, the Architect joins the parallel reviewer pass alongside the Designer and Tech Lead. Its prompts focus on technical feasibility, NFR coverage, missing technical tasks, and cross-task dependencies the PM may have missed.
• ADR authoring. /synthex:write-adr/synthex:write-adr launches the Architect in interview mode. The agent prompts for context, decision, alternatives, and consequences — surfacing the assumptions that decision rests on. If you can't articulate alternatives or the evidence for your choice, the ADR isn't ready.
• RFC drafting and review. /synthex:write-rfc/synthex:write-rfc pairs the Architect with the Product Manager — the Architect handles technical depth (proposal mechanics, drawbacks, open questions), the PM handles motivation and scope. Both run a parallel review pass before the RFC opens for discussion.

#How the Architect thinks about decisions

The Architect operates from a small set of principles:

• Smallest reversible step. When in doubt about a decision, the Architect prefers the smaller change that can be reversed cheaply over a comprehensive rewrite. Big-bang changes warrant a full RFC, not a quick decision.
• Make the assumption visible. Every recommendation comes with the assumption it rests on. If the assumption is wrong, the recommendation is wrong — and the user should know which link is load-bearing.
• Distinguish accidental from essential complexity. The Architect flags complexity that comes from how something is currently built (accidental — fixable) separately from complexity that comes from the problem itself (essential — necessary). Reviewers who conflate the two waste your refactoring budget.

#What it does not do

• Implement code. The Architect is purely advisory. It writes ADRs, RFCs, and plan reviews. The Tech Lead implements; the Architect doesn't touch the diff.
• Make merge decisions. Like every reviewer, the Architect is advisory. The orchestrator consumes the findings; you (or your delegated automation) decide what to merge.
• Replace [H] review. When the Architect flags a [H]-criterion concern in a plan or RFC, the user is the final arbiter. The agent surfaces the concern via AskUserQuestion rather than auto-resolving.

#When you'd add the Architect to other commands

The default rosters cover the common cases. Reach for the Architect explicitly when:

• A custom /myorg:bootstrap-feature command needs an architectural sanity check before plan drafting.
• A code review touches infrastructure, contracts between services, or persistence layer changes — add the Architect via code_review.specialists in .synthex/config.yaml.
• An audit script is regenerating a spec from source-of-truth data and you want a human-readable rationale captured alongside.

The cost is minor — Architect reviews are bounded and the loop caps cycles. The benefit is that the architectural reasoning gets recorded next to the change rather than living only in someone's memory.