Systems Architect

The Core Software Team keeps feature-level work aligned. Requirements, architecture, implementation, QA. The Systems Architect deepens that alignment for problems that are bigger than a feature.

Alignment. Architectural decisions are documented with context and tradeoffs, not made implicitly during implementation.

Scalability. Growth limits are identified before they become incidents. Mitigation is planned, not reactive.

Maintainability. Refactoring follows a target state and migration strategy instead of happening ad-hoc.

These qualities matter most when the work is structural. Refactoring a core abstraction across six modules. Deciding whether to extract a service or keep it monolithic. Evaluating whether your data model can handle the next order of magnitude of growth. Choosing a caching strategy that affects three layers of the stack.

The Tech Lead handles feature-level architecture well. The Systems Architect handles the problems that cross feature boundaries. It evaluates tradeoffs at the system level and documents decisions so they're understood six months later.

Not every feature needs it. You bring in the Architect when a refactor is large enough that getting the target state wrong means doing it twice. When scaling concerns cross module boundaries. When a design decision carries real risk and you want a second opinion before committing.

It produces architectural analysis and recommendations. The Tech Lead takes that guidance and turns it into sequenced work the developers execute.

This is a single, specialized agent. It exists because structural decisions are the most expensive ones to get wrong, and they deserve focused reasoning rather than a general-purpose pass.

If your codebase is growing and you're accumulating structural decisions that feel risky to get wrong, this agent makes those decisions less expensive.