# Agent context index

Generated: 2026-09-13T04:33:12.042Z
Source build: local
Canonical docs: https://teammately.ai/docs

<doc id="agent-context.index" slug="agent-context" url="https://teammately.ai/docs/agent-context.md" title="Agent context index" updated="2026-08-23" status="stable">
---
id: agent-context.index
title: Agent context index
summary: Use Teammately docs safely from AI agents, retrieval tools, and coding assistants.
kind: reference
product_area: agent_context
status: stable
updated: 2026-08-23
canonical: /docs/agent-context
---

# Agent context index

Use this page to choose the smallest Teammately docs context package that can answer a product, workflow, object, troubleshooting, or code-assistance question. This page is about retrieval surfaces and source boundaries, not autonomous agent behavior policy.

## Task intent

Select a context source before reading or summarizing Teammately docs. Agents should start with the smallest pack or retrieval query that matches the task, then load page-local context only when the answer needs exact wording.

The decision rule is conservative: load less context first, cite stable public pages, and stop before inferring product contracts from draft docs or internal file paths.

## Decision checkpoint

| Agent task | Start with | Escalate only when... |
| --- | --- | --- |
| Route a human to the right docs | `/docs/llms.txt` or machine maps | The user needs page-local wording. |
| Explain category or first path | `/docs/llms-core.txt` | A specific workflow page is needed. |
| Answer an operating question | `/docs/llms-operating.txt` or `/api/docs/context` | The answer depends on exact source confidence. |
| Explain object semantics | `/docs/llms-reference.txt` | Exact page retrieval is needed. |
| Diagnose a symptom | `/docs/llms-recovery.txt` | The symptom spans multiple artifacts. |
| Work through an MCP client | MCP `search` | Exact page or block Markdown is needed through `fetch`. |
| Build an index or audit | `/docs/llms-full.txt` | Full-corpus context is intentionally required. |

## Required context

- Root map: [/docs/llms.txt](/docs/llms.txt) for the concise docs map and recommended loading strategy.
- Core pack: [/docs/llms-core.txt](/docs/llms-core.txt) for category, lifecycle, product boundaries, quickstart, and core model concepts.
- Operating pack: [/docs/llms-operating.txt](/docs/llms-operating.txt) for task and workflow guidance.
- Reference pack: [/docs/llms-reference.txt](/docs/llms-reference.txt) for object model and reference pages.
- Recovery pack: [/docs/llms-recovery.txt](/docs/llms-recovery.txt) for troubleshooting pages.
- Retrieval APIs: [/api/docs/search](/api/docs/search), [/api/docs/context](/api/docs/context), and [/api/docs/page](/api/docs/page).
- Machine maps: [/docs/tasks.json](/docs/tasks.json), [/docs/objects.json](/docs/objects.json), [/docs/surfaces.json](/docs/surfaces.json), and [/docs/troubleshooting.json](/docs/troubleshooting.json).
- Private Docs MCP: `https://docs-mcp.teammately.ai/mcp`, with `search`, `fetch`, and `list` tools after connection with `docs:read` access.

## Context pack strategy

1. Start with [/docs/llms.txt](/docs/llms.txt) to understand the docs map and source-confidence policy.
2. Use one focused pack: core for positioning, operating for workflows, reference for objects, or recovery for symptoms.
3. Use [/api/docs/context](/api/docs/context) for query-scoped context when the task is narrow.
4. Load /docs/<slug>/docs/llms-full.txt only when a specific page needs full context.
5. Treat [/docs/llms-full.txt](/docs/llms-full.txt) as an intentional full-corpus dump for indexing or exhaustive review, not as the default context.

## MCP retrieval strategy

1. Call `search` with the user's question and an optional `kind` or product-area filter.
2. Read the returned search mode and build metadata. Semantic retrieval can fall back to lexical retrieval without making results invalid.
3. Use cited `blockId`, `pageId`, or `slug` with `fetch` before quoting exact guidance or applying an instruction.
4. Use `list` only for navigation or filtered inventory; it is not a substitute for page content.
5. Treat AI Overview text as a cited routing aid. The referenced blocks and fetched page remain the evidence boundary.

The MCP resources `teammately-docs://manifest`, `teammately-docs://docs/{slug}`, and `teammately-docs://blocks/{blockId}` provide the same active corpus at manifest, page, and block granularity.

## Agent answerability check

| Before answering, verify... | If not... |
| --- | --- |
| The cited page is stable and public. | Say the source boundary is not public rather than quoting draft files. |
| Source confidence matches the claim strength. | Downgrade the answer or ask for human confirmation. |
| The route answers the user's task without loading unrelated packs. | Use search or `/api/docs/context` before full-corpus context. |
| MCP overview claims resolve to returned block references. | Fetch the cited block or page before relying on exact wording. |
| The claim is not about API, auth, billing, compliance, retention, deployment, or provider handling unless a source-backed page says so. | State that the docs do not currently confirm the contract. |

## Available routes

- [/docs/<slug>.md](/docs/quickstart.md): page-level markdown export.
- [/docs/<slug>/docs/llms.txt](/docs/quickstart/llms.txt): compact page-local context.
- [/docs/<slug>/docs/llms-full.txt](/docs/quickstart/llms-full.txt): page-local full context.
- [/api/docs/manifest.json](/api/docs/manifest.json): stable public page metadata, source confidence, source refs, and related IDs.
- [/api/docs/page?slug=quickstart](/api/docs/page?slug=quickstart): exact public page retrieval.

## Allowed assumptions

- Stable public docs are the public source of truth for published guidance.
- Draft and removed pages are intentionally excluded from public routes and root context packs.
- Source confidence metadata tells the agent how strongly to treat a claim.
- Page-local routes are useful for exact wording; root packs are useful for routing and broad orientation.

## Forbidden assumptions

- Do not load draft or removed docs from repository files as public facts.
- Do not treat /docs/llms-full.txt as mandatory for every answer.
- Do not infer public API, auth, rate-limit, compliance, deployment, billing, or integration guarantees from internal evidence paths.
- Do not collapse doctrine-backed positioning into code-backed behavior, or code-backed product behavior into public external contracts.

## Related human docs

{% related-card-grid title="Related human docs" %}
- [What is Teammately?](/docs/introduction/what-is-teammately)
- [Task index](/docs/operating-manual/task-index)
- [Reference index](/docs/reference)
- [Troubleshooting](/docs/troubleshooting)
{% /related-card-grid %}

## Related reference docs

{% related-card-grid title="Related reference docs" %}
- [Agent instructions](/docs/agent-instructions)
- [Object model](/docs/object-model)
- [Permissions](/docs/reference/permissions)
{% /related-card-grid %}

## Safe operating boundaries

Agents should answer from stable public pages and cite the page URL. If a needed claim is only draft, inferred, or absent from the context packs, say the source boundary is unconfirmed and ask for human confirmation.

When a task needs exact behavior, prefer `/api/docs/page?slug=<slug>` or page-local markdown over a broad pack. When a task needs a route into the docs, prefer `/docs/llms.txt`, focused packs, search, and machine maps before loading full-corpus context.

## Source confidence

Docs-backed: this page describes routes and files implemented in the docs repository. The source_refs frontmatter lists the docs loaders, llms generators, and machine-readable route files.
</doc>

<doc id="agent-instructions" slug="agent-instructions" url="https://teammately.ai/docs/agent-instructions.md" title="Agent instructions" updated="2026-08-23" status="stable">
---
id: agent-instructions
title: Agent instructions
summary: Rules coding agents should follow when using Teammately public docs as source context.
kind: reference
product_area: reference
status: stable
updated: 2026-08-23
canonical: /docs/agent-instructions
---

# Agent instructions

Use this page as the behavioral policy for agents operating with Teammately docs. For route selection and context packaging, read [Agent context index](/docs/agent-context).

## Task intent

Answer Teammately product and docs questions safely without inventing unsupported product claims. The agent should preserve source confidence, cite stable pages, and ask for confirmation when a claim depends on draft, inferred, or missing evidence.

## Required context

- Read [/docs/llms.txt](/docs/llms.txt) first for the recommended context loading strategy.
- Use [Agent context index](/docs/agent-context) to choose the smallest relevant context pack.
- Use page-local markdown or llms routes for exact wording.
- Use the manifest or page API when source confidence, source refs, related IDs, or metadata matter.
- In an MCP client, search first and fetch the cited page or block before relying on exact wording.

## Allowed assumptions

- Code-backed pages can support object, state, and workflow claims when source_refs are present.
- Doctrine-backed pages can support positioning, lifecycle, category language, and public narrative.
- Docs-backed pages can support claims about routes, llms files, manifests, search, context APIs, and validation behavior.
- Stable public pages supersede older draft or removed pages.

## Forbidden assumptions

- Do not present draft schema pages as public schemas.
- Do not infer public APIs, SDKs, API keys, auth behavior, rate limits, billing, compliance, tenant isolation, deployment modes, support guarantees, customer names, model-provider integrations, or production monitoring behavior.
- Do not treat AI-assisted suggestions as approved policies, rubrics, or review context unless a stable page says a human approved them.
- Do not collapse Teammately into eval dashboards, observability, annotation, prompt testing, generic LLMOps, or a replacement for adjacent tools.
- Do not use internal source file names as public UI promises unless the public docs already state the behavior.

## How to answer safely

1. Identify whether the user is asking for positioning, operating steps, object behavior, recovery, or implementation context.
2. Load the smallest matching context pack or query-scoped context.
3. Check source confidence before making claims.
4. Prefer stable page citations over broad corpus summaries.
5. If search returns an AI Overview, verify its block references with `fetch`; treat the overview as routing assistance rather than independent authority.
6. State uncertainty when a claim is inferred, draft-only, or outside the docs.
7. Ask for human confirmation before advising changes that depend on permissions, compliance, deployment, billing, customer-facing APIs, or unsupported integrations.

## When to ask for human confirmation

- The user asks whether an inferred or draft schema is a public contract.
- The answer would require exact UI labels not present in stable docs or source refs.
- The user asks about admin, auth, security, compliance, deployment, billing, or support commitments.
- Related evidence conflicts across docs, product code, and doctrine.
- The requested action could change review context, approval state, or benchmark interpretation without accountable human review.

## Related human docs

{% related-card-grid title="Related human docs" %}
- [Product boundaries](/docs/introduction/product-boundaries)
- [Human approval boundaries](/docs/governance/human-approval-boundaries)
- [What AI Features Can and Cannot Do](/docs/governance/what-ai-features-can-and-cannot-do)
{% /related-card-grid %}

## Related reference docs

{% related-card-grid title="Related reference docs" %}
- [Agent context index](/docs/agent-context)
- [Reference index](/docs/reference)
- [Object model](/docs/object-model)
{% /related-card-grid %}

## Safe operating boundaries

Agents may help readers find pages, summarize stable docs, compare source-confidence labels, and draft operational next steps. Agents should not approve policies, approve rubrics, assign reviewers, declare a candidate ready for rollout, or convert draft/inferred material into public product commitments.

Search mode is diagnostic metadata, not a confidence label. Lexical fallback remains usable when semantic embeddings are unavailable; source confidence still comes from the fetched page metadata and prose.

## Source confidence

Docs-backed: this page is a behavior policy for using the docs system safely. The docs loaders, context routes, and MCP tools establish the available retrieval surfaces, cited block references, and read-only tool boundaries.
</doc>

<doc id="object-model.overview" slug="object-model" url="https://teammately.ai/docs/object-model.md" title="Object model" updated="2026-09-07" status="stable">
---
id: object-model.overview
title: Object model
summary: Understand how project foundations, benchmark artifacts, contributions, evaluations, and improvement sessions connect.
kind: reference
product_area: reference
status: stable
updated: 2026-09-07
canonical: /docs/object-model
---

# Object model

Use this reference when a workflow depends on artifact ownership, identity, version history, or provenance. Teammately keeps reusable project foundations separate from benchmark-scoped evidence so a later reader can reconstruct what the agent knew, what was evaluated, who supplied judgment, and why a candidate was retained.

> Preserve scope and version
>
> An artifact name alone is not sufficient evidence. Preserve its project or benchmark scope, version or snapshot identity, lifecycle state, and provenance whenever it affects evaluation or improvement.

## Definition

A **Project** owns reusable foundations: the Project Agent Brief, Reference blocks, policies, rubrics, coverage facets, Cases, Harnesses, Review Screen configuration, Comparison Directions, and Project Input Schema. These objects can support more than one benchmark.

A **Benchmark** owns a particular correctness boundary. Its workspace selects Cases into Dataset snapshots, organizes benchmark-scoped coverage work, requests Expert Contributions, and creates Benchmark versions. A Benchmark version is the fixed boundary against which a saved Harness version is evaluated.

An **Evaluation Run** records the response, Rubric outcomes, mapping, settings, and metadata produced by one saved Harness Version against one Benchmark Version. It does not currently expose execution trajectories. An **Improvement Session** pins target evidence through a Goal Contract, evaluates candidates, retains canonical receipts and safe narrated session activity, and updates a Current frontier. The frontier is evidence-backed session state, not an unnamed replacement for the saved Harness.

## Decision checkpoint

| Question | Object boundary to preserve | Common mistake |
| --- | --- | --- |
| What did the agent understand? | Project Agent Brief and Reference block generation | Treating the latest source file as the knowledge used by an earlier run |
| What behavior was evaluated? | Case, Dataset snapshot, Benchmark version, and saved Harness version | Describing only a prompt and score |
| What standard applied? | Policy, applicability, Rubric, and provenance | Letting a Rubric stand in for the Policy it checks |
| Who supplied judgment? | Contribution, Task, Checkpoint, expert, and Contributed artifact | Treating an unattributed comment as governed truth |
| Why was a candidate retained? | Improvement Session, Goal Contract, evaluation receipt, and Current frontier | Treating an unsaved draft as the evaluated candidate |

## Fields, states, or lifecycle rules

### Project foundations

- **Project Agent Brief:** Published project understanding used to orient agents.
- **Reference block:** Indexed knowledge with source and generation identity.
- **Policy and Rubric:** Governed meaning and executable judgment criteria, with applicability and provenance.
- **Coverage Facet:** Reusable Dimensions, Project Topics, and Case Construction Patterns that describe important behavior space.
- **Case:** Canonical `content.input`, optional `content.case_materials`, metadata, and optional executable world reference.
- **Harness:** An agent configuration with mutable Draft state and immutable saved versions used for evaluation.
- **Project Input Schema:** The project-level architecture that governs canonical Case input and materials.

### Benchmark artifacts

- **Dataset snapshot:** A reproducible selection and representation of benchmark Cases.
- **Coverage Story:** Benchmark-scoped intent that connects coverage structure to concrete case work.
- **Expert Contribution:** A benchmark-scoped request containing Tasks, context, statuses, and optional Checkpoints.
- **Contributed artifact:** A policy, Rubric, Case, or coverage observation supplied through a Contribution with attributable provenance.
- **Benchmark version:** The fixed evaluation boundary used by Runs and Improvement Sessions.
- **Evaluation Run:** One execution with candidate, benchmark, response, Rubric outcomes, settings, mapping, and metadata identity.
- **Improvement Session:** A goal-directed candidate exploration process with pinned evidence, receipts, trajectories, and frontier state.

{% artifact-map title="How correctness artifacts connect" %}
{% /artifact-map %}

## Static materials and executable worlds

Case materials and executable worlds are intentionally different. `content.case_materials` holds canonical material data or references that can accompany the input. A `world_instance_ref` identifies an executable or queryable environment with a separate capability and lifecycle boundary. Rendering either for inspection does not create another authoring source.

{% example-demo title="From contribution to frontier" %}
A benchmark Contribution asks a procurement specialist to resolve three ambiguous Cases. The expert confirms a Policy and binary Rubric at a Checkpoint. The artifacts are reconciled into Correctness Governance while retaining their Contribution provenance. The Cases enter a Dataset snapshot and the standard enters Benchmark version 6. An Evaluation Run tests Harness version 11 and exposes two failures. An Improvement Session pins those failures, evaluates versions 12 and 13, and retains version 13 in the Current frontier with canonical evaluation receipts.
{% /example-demo %}

## Source confidence

Code-backed: current navigation establishes project and benchmark scopes; canonical case-content code establishes the input and materials boundary; the active Improve session contract establishes Goal Contract, candidate, receipt, and frontier concepts. This page describes public object semantics, not a public API or export schema.

## Related task pages

{% related-card-grid title="Related task pages" %}
- [First correctness loop](/docs/operating-manual/first-correctness-loop)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Start an Improvement Session](/docs/improve/start-improvement-session)
{% /related-card-grid %}

## Related reference pages

{% related-card-grid title="Related reference pages" %}
- [Key objects and relationships](/docs/getting-oriented/key-objects-and-relationships)
- [Cases](/docs/assets/cases)
- [Harnesses](/docs/assets/harnesses)
- [Glossary](/docs/reference/glossary)
{% /related-card-grid %}
</doc>

<doc id="reference.index" slug="reference" url="https://teammately.ai/docs/reference.md" title="Reference library" updated="2026-09-07" status="stable">
---
id: reference.index
title: Reference library
summary: Look up Teammately objects, states, permissions, metadata, schemas, and source-confidence boundaries.
kind: reference
product_area: reference
status: stable
updated: 2026-09-07
canonical: /docs/reference
---

# Reference library

## Definition

The reference library is the lookup layer for object semantics, IDs, permissions, metadata, glossary terms, and source-confidence boundaries. Use it when a workflow depends on exact object meaning rather than the broader operating path.

This page is an index, not a schema contract. Use the stable references below for object meaning; draft schemas and internal implementation details do not become public contracts through this index.

## Fields, states, or lifecycle rules

- Object references explain identity, state, lifecycle, and relationship boundaries.
- Permission references explain user-facing access boundaries only where source-backed.
- Metadata and context references explain how records and cases remain reviewable.
- Source-confidence labels tell readers whether a claim is code-backed, doctrine-backed, docs-backed, or inferred.
- Draft schema pages are not public API or export contracts.

## Related objects

Use [Object model](/docs/object-model) for the main artifact graph, [Permissions](/docs/reference/permissions) for access boundaries, [IDs and keys](/docs/reference/ids) for identity references, and [Glossary](/docs/reference/glossary) for vocabulary.

{% example-demo title="Reference library boundary" %}
Question: A reader asks whether a benchmark run result can be treated as a public export schema.

Reference answer: The object references can explain benchmark, run, and result semantics. They do not create a public export contract unless a source-backed public schema page says so.

Next page: Use [Benchmarks](/docs/object-model/benchmarks), [Run metadata](/docs/benchmark-evaluations/run-metadata), or [Product boundaries](/docs/introduction/product-boundaries), depending on the claim.
{% /example-demo %}

## Source confidence

Docs-backed: the documentation manifest and taxonomy define the published reference groups and canonical page relationships. Each linked reference carries its own product-evidence boundary; this index does not raise a draft or internal schema to stable contract status.

## Related task pages

{% related-card-grid title="Related task pages" %}
- [Object model](/docs/object-model)
- [Permissions](/docs/reference/permissions)
- [Glossary](/docs/reference/glossary)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}
</doc>