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

# What an agent knows

> An autonomous agent is only as good as the context it receives before taking its first action.
> AGMX assembles a clean, structured context from project guidelines, verify scripts, file-matched rules, and the live specification graph.
> The agent starts with verified code boundaries and a dedicated worktree graph, rather than guessing how to inspect or test the repository.

## The prompt assembly stack

When a run is dispatched, AGMX constructs the executor prompt deterministically from several distinct layers in a strict order. The prompt provides everything necessary to execute within project boundaries without overloading the agent with irrelevant documentation.

![Layer stack diagram showing the six layers of prompt assembly: project context, verify command, path-matched rules, task and live spec instructions, open review feedback, and worktree code graph tools.](/assets/diagrams/context-layers.svg)

1. **Project context**: Defines repository purpose, architectural principles, code conventions, and high-level boundaries. Saved once and reused across all subsequent runs.
2. **The project's check command**: The project's declared check command ("use this to check your work"). The agent is instructed to validate changes with this command rather than inventing ad-hoc testing routines.
3. **Project rules**: Structured rules defined for the project. Only rules matching the specific files touched by the task are included in the prompt.
4. **Task requirements and live spec**: The user request and instructions to inspect active specifications. If an executor makes changes that conflict with an active spec claim, it must state so for the reviewer.
5. **Open review feedback**: In rework rounds, all unresolved findings from previous review cycles are appended alongside existing instructions, never overwriting the original task description.
6. **Code graph instructions and run boundaries**: Instructions for querying the local code graph and operational boundaries restricting execution to the assigned worktree.

Reviewers receive the identical project context, declared verify command, and path-matched rules to ensure evaluation parity.

## The live specification in context

Specifications in AGMX are not static markdown documents that quickly drift out of date. They are active entities in a relational graph anchored directly to files and code symbols.

Whether a specification claim is marked built or only agreed is dynamically derived at read time based on anchored code presence, hashes reported by the runner, and landed tasks. No user or agent can toggle this state by hand. When an agent reads the specification, it sees the ground truth of what the codebase guarantees today and what remains in the backlog.

For detailed mechanics on how anchors and staleness are calculated, see [What the system remembers](/knowledge/).

## Worktree code graph on the developer machine

Every execute run receives a dedicated code graph built specifically from its isolated worktree. The server does not maintain a repository checkout and never builds graphs remotely.

The code graph is built and queried entirely on the developer's machine:
- Determines blast radius and downstream callers for modified files.
- Searches code symbols semantically by meaning.
- Runs direct graph queries across symbols and dependencies.

Because team servers maintain no local checkouts, agents always rely on their local runner graph for code exploration.

## Live rules and the Stop hook

A coordinator agent receives its operating instructions live from the team's server on connect. A lightweight skill installed into local coding CLIs directs the agent to fetch the latest rules from `https://<team>.agmxcode.com/coordinator-rules.md`, ensuring policies never go stale on a laptop.

To prevent agents from prematurely ending their turns while background work is outstanding, AGMX provides a Stop hook for supported CLIs (such as Claude Code and Kimi). When an agent initiates work, the hook blocks turn completion until the agent has waited on those operations.

## Scoped sessions

Conversations in AGMX maintain strictly enforced scopes: global, project, or task. When context windows grow full, coordinators can compact older interactions within their session without altering adjacent sessions.

To learn how tasks transition through these states, visit [The AGMX workflow](/workflow/). To see how agents and humans interact, read [How agents work together](/coordination/). For boundary details on what leaves your machine, consult [What the server sees](/what-the-server-sees/).

## For an AI agent reading this

When gathering context or preparing task runs, use `spec_get` to read live specification items, code anchors, and realization state.

This page describes how context is structured. For authoritative, team-specific coordinator rules, fetch `https://<team>.agmxcode.com/coordinator-rules.md` directly from your server.