Status	Last updated	Parent	Read before this
incomplete	2026-04-30	Design - Architecture Overview	Design - Wiki Layer

The Documentation Agent

The agent population that maintains the wiki. Not yet implemented. Several open questions remain — see below.

Current state

The doc agent is a separate population from Role - Coding Harness Agents. Its mental model is component knowledge, not feature work. It reads from the queue of issues in pending-docs state on the consuming project and updates the relevant component or module pages.

Settled design points:

• One agent, no concurrency conflicts. The doc agent runs serially against the queue. No SLA — if it falls behind, the queue grows but nothing breaks.
• Maintenance, not summarization. The agent's primary job is updating existing pages. New pages are created only when a feature introduces a genuinely new component or module.
• Reads closed issues, writes wiki. Coding harness agents write to issues only; the doc agent reads issues and writes the wiki. Neither agent population holds both mental models simultaneously.
• Reader's prompt shape. "This feature changed the system; what pages need updating, and is there anything new enough to need its own page?" Valid output includes "nothing — bug fix, no behavioral change."

Rationale

Keeping the doc agent separate from coding harness agents prevents the wiki from drifting into per-feature changelogs. A /closeout skill that could write to the wiki would be tempted to summarise every feature there. The doc agent's job description — "edit existing component pages where possible" — is what enforces the Design - Wiki Layer.

Having no SLA reflects the reality that documentation isn't on the critical path for shipping. Features ship when QA passes and the orchestrator approves UAT; the wiki updates afterwards. Tying wiki freshness to ship cadence would create pressure to cut corners.

The single-agent constraint is a YAGNI choice. Concurrency would require coordination machinery (locks on pages, conflict resolution) that isn't worth building before there's a problem to solve. If volume becomes a real constraint, splitting by component area is the obvious next step.

Open questions

• Canonical input. Approved PREQ + final PR description + changed files? Dev journals and validation reports are probably noise for the doc agent — they're learning fuel, not behaviour spec. The reader of a wiki page in six months doesn't care that a flaky test was fixed twice.
• Approval gate. Likely yes; review proposed wiki edits before they land. The threshold and sampling model haven't been pinned down. The dormant Wiki Conventions - Governance Model is a candidate when activated.
• Initial wiki taxonomy. Each consuming project's wiki needs an initial set of component pages before the doc agent can run. This is a human decision per project, not something the doc agent can bootstrap from nothing.
• Integration point. Whether the doc agent runs as part of /closeout, as part of /integrate, as a post-merge hook, or as a standalone scheduled process — each has trade-offs and none are decided.
• Closing-without-closing. If the doc agent operates on closed issues with a pending-docs label rather than open issues, the kanban's "Done" column reflects shipped-and-documented; if it operates on pending-docs while the issue is still open, the kanban reflects shipped-but-not-yet-documented. Both are defensible.