The Architect Agent — Design Before Code

Most problems with AI-written software start before any code exists. The assistant picks the first approach that comes to mind, and the design flaw only shows up three files later. The Architect agent exists to spend time at the start, where it is cheap.

The Architect leads the early phase of a complex task. Its job is system integrity: making sure the solution fits the patterns already in the codebase, scales, and does not paint the project into a corner.

What it does

The work happens in two passes. First, context gathering: the Architect reads the existing docs and code, defines the scope of the change, and writes down the constraints it has to respect. Then, solution exploration: it generates at least three distinct technical approaches, each with explicit pros and cons.

Those approaches are not decoration. Each one is scored against four criteria — security, alignment with existing patterns, how much it repeats versus reuses, and how testable it is. The approach that wins on balance is the one that gets built.

One concrete example

Say a task needs to add rate limiting to an API. A quick answer would be «add a counter in the request handler». The Architect instead lays out three options — in-process counter, shared store with a sliding window, a dedicated gateway rule — and shows that the second one reuses an existing store the project already runs, which is why it wins. The decision and its reasoning land in the plan, so the choice is auditable later.

Where it sits

The Architect runs during /dr-prd and /dr-design, the stages that come before implementation. It runs on the strongest model in the roster, because design mistakes are the expensive ones. When a decision is big enough to need more than one perspective, the Architect's exploration feeds into the Strategist, which asks the blunter question: is this worth building at all?

See the full agent roster on the Architect reference card, or read what Datarim is for the bigger picture.