Every AI session in AITM — whether it's the coder, the reviewer, or a chat you're having right now — draws on the same shared, always-current knowledge base instead of starting from a blank page.

Knowledge & Document Sharing

Contracts — the project's fact sheet

A contract is a saved fact about how one specific piece of your project behaves — a small, structured note describing what a part of the code does, which files are involved, and what to be careful about. Contracts are created and updated automatically after tasks merge, based on what actually changed. Before writing any code, an agent reads the contracts relevant to its assignment, sees flagged "danger zones" where a small change has historically had outsized consequences, and can find precedent from earlier tasks that touched the same area.

The knowledge graph

Contracts don't exist in isolation. AITM maintains a knowledge graph for each project that connects variables (dot-notation codes like UI.PANEL.CHAT or BL.PIPELINE), contracts, DOM elements, screenshots, and documentation — all cross-referenced. Look up a variable and you'll find the contracts, files, and screenshots connected to it; look up a contract and you'll find the variables and files it governs.

You can browse this graph yourself through the Variable Explorer, which lets you search variables, drill into their detail, and see any screenshot preview tied to a UI element.

Hints — reusable house rules

Hints are short, standalone rules you (or a past task) have taught AITM, which get applied automatically going forward — e.g. naming conventions or response shapes. Before an agent starts a step, AITM automatically finds hints relevant to what it's about to do and includes them in its context, so you never have to repeat the same convention across every task you create.

Shared agent templates

Every pipeline step's AI prompt is assembled in layers: a provider preamble, shared templates common to all steps, the step's own agent instructions, an optional per-project override, and finally your own customizations. That layering guarantees every pipeline step, and every AI provider, gets the exact same project conventions and rules — no drift between what the architect knows and what the coder follows.

Handoff between steps

Each pipeline step ends by emitting a structured, machine-readable handoff block. That block becomes the next step's starting context, bridging the gap between two otherwise fresh AI sessions — and because the handoff format is provider-agnostic, it works identically whether the next step runs on Claude, Gemini, DeepSeek, or Ollama.

Shared session groups

Architect, Code, Review, and Fix can run inside one continuous AI conversation rather than four disconnected ones. That means the implementer still remembers the design decisions from the architecture step, and the reviewer still remembers exactly how the implementer reasoned through the change.

Auto-generated documentation

After every merge, AITM regenerates per-module knowledge docs, a project-wide knowledge digest, and a searchable index. Documentation, doc-contracts, and doc-pointers are indexed in a per-project SQLite database and linked directly to variables and behavioral contracts, so cross-task references keep feature evolution traceable long after the original task is archived.

Brainstorm, Chat, and external agents

Conclusions from a @KEYWORD brainstorm session are reusable in any future task prompt. Chat itself is fed by a cached knowledge digest, so it can answer project questions without re-reading your whole repository every time. And because the entire knowledge base sits behind one GraphQL endpoint, MCP servers can expose it to external AI agents too.