Built-in Agents
The plugin ships two built-in agents — narrow specialists with the MCP tools they need and nothing more.
You rarely invoke agents directly — skills call them, and the host can also trigger them proactively based on your intent (the auditor especially, since it runs in the background). But it helps to know what each does so you can reason about what’s happening when a skill delegates.
archcore-assistant
Section titled “archcore-assistant”A universal read/write agent for complex multi-document tasks.
| Role | Requirements engineering, multi-document planning, relation graph management. |
| Tools | All 8 MCP tools (list_documents, get_document, create_document, update_document, remove_document, add_relation, remove_relation, list_relations), plus Read, Grep, Glob. |
| Max turns | 20 |
| Safety | Every .archcore/ write goes through MCP. Direct Write/Edit calls are not in its toolbox. |
When skills call it
Section titled “When skills call it”/archcore:plan --track iso— building the full BRS → StRS → SyRS → SRS cascade./archcore:decidecontinuations — wiring ADR → spec → plan or ADR → rule → guide with the right relations.- Large-scope refactors of
.archcore/across many files.
What it’s good at
Section titled “What it’s good at”- Keeping the relation graph consistent across five or ten documents at once — creating relations right after the documents they connect.
- Respecting document-type templates — filling the right sections, not just pasting prose.
- Writing every change through MCP tools, never hand-editing files, and planning before bulk creation (it won’t exceed ~10 documents in one pass without confirming).
archcore-auditor
Section titled “archcore-auditor”A read-only auditor for documentation health reviews.
| Role | Detects coverage gaps, orphaned documents, stale statuses, consistency issues. |
| Tools | list_documents, get_document, list_relations, plus Read, Grep, Glob. |
| Max turns | 15 |
| Execution | Runs in the background (background: true) and is invoked proactively — after a batch of document creations, or before a release. The audit runs non-blocking, so you keep working while it reviews. |
| Safety | Read-only by design — cannot create, update, or delete documents. |
When skills call it
Section titled “When skills call it”/archcore:audit— dashboard (default) or full audit (--deep); some of the dashboard numbers come from auditor queries./archcore:audit --drift— find stale documents via code drift, cascade drift, and temporal signals.
What it’s good at
Section titled “What it’s good at”- Returning structured audit reports — not prose summaries.
- Finding orphans: documents with no incoming or outgoing relations that probably should have some.
- Spotting naming inconsistencies, tag hygiene issues, and missing frontmatter.
Host file formats
Section titled “Host file formats”Both agents ship in two file formats side by side under agents/:
.md(archcore-assistant.md,archcore-auditor.md) — consumed by Claude Code and Cursor..toml(archcore-assistant.toml,archcore-auditor.toml) — consumed by Codex CLI. The auditor TOML usessandbox_mode = "read-only",model_reasoning_effort = "high", plus adisabled_toolslist covering the five mutating MCP tools; the assistant TOML usessandbox_mode = "workspace-write".
Tool whitelists are identical across formats — the TOML variants just translate the safety boundaries into Codex’s native sandbox model.
Why two agents, not one
Section titled “Why two agents, not one”Separating the write-capable agent from the read-only one is a deliberate safety boundary. The auditor runs on every review, so it handles more documents and contexts per week than the assistant. Keeping it read-only means a review session can never accidentally mutate state — which is also why it can run in the background and be triggered proactively across a large knowledge base without blocking your work.
Next steps
Section titled “Next steps”- Commands — the 7 user-facing commands that call these agents.
- Troubleshooting — issues you might see with agent invocations.