The two Archgate agents — developer and planner — that orchestrate ADR-compliant AI development, reading decisions before coding and validating after.
Where skills are focused capabilities, agents are the orchestrators. An Archgate agent governs an entire interaction with your AI coding tool: it knows the governance loop, invokes the right skill at the right moment, and treats your ADRs as absolute constraints. The editor plugins install two agents — one that writes code, and one that only plans.
developer — the orchestrator
Section titled “developer — the orchestrator”The developer agent is the default agent the plugin installs. It is a general-purpose development agent that enforces ADR compliance across every code change by following a fixed workflow:
- UNDERSTAND — read the applicable ADRs first. The agent runs
archgate review-contextto get condensed Decision and Do’s and Don’ts briefings for the files in scope, so it knows the constraints before writing anything. - PLAN — design an approach that complies with every applicable ADR. If a constraint conflicts with the task, the agent flags it rather than silently violating it.
- WRITE — implement code against the constraints it just read.
- VALIDATE — run
archgate checkfor fast deterministic validation, then invoke the reviewer skill for structural and judgment-based review. Violations are fixed before proceeding; warnings are surfaced to the user. - CAPTURE — invoke the lessons-learned skill to codify any new patterns from the session.
The developer agent is judicious about cost: it runs the full validate-and-capture cycle for initial task completion, but skips the heavier reviewer and lessons-learned steps for minor follow-up tweaks (a rename, a value change) where archgate check alone suffices.
ADR-driven refusal
Section titled “ADR-driven refusal”The most important behavior of the developer agent is that ADRs are hard blockers. If a task would require code that violates an ADR, the agent refuses, names the ADR that would be violated, and suggests a compliant alternative that achieves the same goal. If the user insists on bypassing it, the agent refuses again — ADR compliance is mandatory, not advisory. This is what makes prevention real rather than aspirational: the agent will not write non-conforming code in the first place.
planner — read-only design
Section titled “planner — read-only design”The planner agent is a read-only counterpart. It reads ADRs and explores the codebase but never writes, edits, or creates files. Its job is to produce a detailed, ADR-compliant implementation plan that you — or the developer agent — can then execute.
A planner output includes an ADR compliance summary (which ADRs apply and how the approach satisfies each), a file-level implementation strategy, dependencies and sequencing, ADR risk areas, governance gaps where no ADR yet applies, and a verification strategy. Like the developer agent, the planner refuses to propose any approach that would violate an ADR.
The read-only constraint is the point: you can safely explore options and trade-offs with the planner with zero risk of unintended changes, then hand the approved plan to the developer agent to implement.
How the agents use skills
Section titled “How the agents use skills”Agents do not duplicate skill logic — they invoke skills. The developer agent calls reviewer and lessons-learned as the VALIDATE and CAPTURE steps; both agents lean on cli-reference to load exact command syntax rather than guessing, and on adr-author whenever an ADR must be written. This separation keeps each piece focused: agents own the workflow, skills own the capabilities.