> ## Documentation Index
> Fetch the complete documentation index at: https://agmxcode.com/llms.txt

# What the system remembers

> Most coding systems treat requirements as ephemeral chat messages or disconnected text files.
> AGMX binds specifications directly to concrete code symbols and tracks real-world realization automatically.
> When code changes, the system detects specification staleness through deterministic hashing rather than heuristic LLM guesses.

## The continuous knowledge loop

Knowledge in AGMX forms a closed loop anchored by real code. Rather than drifting silently, specifications update, link, and invalidate in direct response to landed commits.

![Diagram showing the feedback loop from landed commits and anchor hashing to staleness detection, task linking, and live prompt injection around the central spec graph.](/assets/diagrams/knowledge-loop.svg)

1. **Work lands**: When an execute run completes and passes review, the runner merges the worktree and pushes the commit to the shared branch.
2. **Anchor hashing on the runner**: The runner extracts the code of touched symbols that correspond to existing spec anchors and fingerprints them.
3. **Deterministic staleness detection**: The server compares reported fingerprints against recorded anchor hashes. If an anchored symbol changed, the associated specification item is immediately flagged as stale, with the specific commit recorded as the reason. No LLM evaluation is involved.
4. **Automatic task linking**: Upon landing, the server automatically links the completed task and touched code to affected specification claims.
5. **Live spec for the next agent**: When subsequent tasks are planned or dispatched, the next agent is told to read the live specification for its task and project before it starts.

## Specification claims, anchors, and relations

Specifications in AGMX are structured records defining expected behavior:
- A kind: requirement, decision, constraint, interface, or design.
- A status: draft, active, stale, or superseded, accompanied by a confidence rating.

Claims connect to actual code through anchors. An anchor binds a specification claim to a specific file and symbol with one of four explicit relationships:
- `implements`: The symbol realizes the specification behavior.
- `constrains`: The symbol enforces an architectural boundary or rule.
- `tests`: The symbol verifies compliance with the specification.
- `documents`: The symbol describes or annotates the specification.

Claims also connect to each other through relationships such as depends on, refines, conflicts with, or duplicates. Tasks link to claims as implementing, modifying, referencing, or violating them. When work lands, touched code links to claims automatically.

## Agreed versus built: derived realization

In AGMX, neither human nor agent manually toggles a specification from planned to finished. Realization is derived directly from repository evidence:
- A claim is agreed when accepted into the specification graph.
- A claim becomes built only when its anchored code exists and a linked task implementing it has landed.

The list of agreed-but-not-built claims forms the active project backlog, providing clear visibility into remaining commitments.

## Knowledge base and semantic search

Broad domain knowledge, architectural designs, and operating runbooks reside in a searchable knowledge base.

Articles are categorized and titled, supporting semantic vector search that automatically falls back to keyword matching if vector services are unavailable. Responses explicitly indicate whether fallback occurred, ensuring transparent search behavior.

## Notes, idea inbox, and implementation designs

The knowledge network also supports lightweight forms of project memory:
- **Idea inbox**: Captures raw ideas without requiring compute overhead or gates, holding them until they are promoted to tasks.
- **Notes**: Attaches lightweight notes directly to projects and tasks to capture operational commentary.
- **Implementation designs**: For lower-cost executors, a written implementation design must pass mechanical completeness checks before dispatch, ensuring all required design elements exist without relying on an LLM judge.

To see how landed tasks update this graph, review [The AGMX workflow](/workflow/). To understand how specs feed into agent prompts, read [What an agent knows](/context/). For multi-agent planning and review details, visit [How agents work together](/coordination/).

## For an AI agent reading this

When reading from the knowledge network, use `spec_get` to inspect active specifications, code anchors, and backlog claims.

This page describes the architecture of the knowledge network. Always fetch `https://<team>.agmxcode.com/coordinator-rules.md` on your team's install for live, binding coordinator rules.