# Project Context
Generated: 2026-09-13T04:40:55.237Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: agent-setup.project-context
title: Project Context
summary: Maintain the Project Agent Brief that gives Teammately agents stable, project-wide understanding.
kind: reference
product_area: agent_setup
status: stable
updated: 2026-08-22
canonical: /docs/agent-setup/project-context
---
# Project Context
## Definition
Project Context is the Agent Setup surface that edits the **Project Agent Brief**. The brief gives Teammately agents stable project-wide understanding: what the specialist AI is for, which behavior matters, important constraints, terminology, and other context that should carry across coverage, contribution preparation, case construction, and improvement work.
The Project Agent Brief is different from the Project Memo in General settings. The memo is administrative project text and explicitly is not used as prompt or agent context. Put agent-relevant project understanding in Project Context.
## Fields, states, or lifecycle rules
- The brief is scoped to the project and reused across benchmark workspaces.
- Editing the brief changes future agent context; it does not rewrite completed Contributions, Runs, or Improvement Session history.
- The brief provides orientation and constraints, not governed correctness authority. Policies and rubrics remain in Correctness Governance.
- Controlling source material belongs in Reference Materials. Summarize stable project intent in the brief and keep source-backed detail in the indexed material.
- The brief should state product-specific meaning directly. Avoid copying transient benchmark goals, one expert's unconfirmed opinion, or a temporary candidate hypothesis into permanent project context.
## Writing a useful brief
Describe the specialist AI's purpose, users, important domain vocabulary, expected interaction shape, and constraints that affect many workflows. Include explicit boundaries where agents might otherwise make unsafe assumptions. Name controlling authorities without duplicating entire manuals.
Review the brief when the product purpose, domain, input architecture, or correctness boundary changes materially. If only one benchmark needs a special objective, put it in that benchmark's setup or Contribution. If only one Improvement Session needs a constraint, put it in the Goal Contract.
{% example-demo title="Example: project context boundary" %}
The brief states that a procurement assistant supports internal buyers, must distinguish current agreements from expired ones, and should expose uncertainty rather than invent an exception. The current agreements themselves remain indexed Reference Materials. The exact evaluation target for expired-agreement cases belongs to the benchmark and Improvement Session, not the brief.
{% /example-demo %}
## Source confidence
Code-backed: the active Agent Setup Project Context route renders the Project Agent Brief editor. The distinction from General settings is supported by the current project settings UI.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Product quickstart](/docs/quickstart)
- [Use Reference Materials](/docs/agent-setup/reference-materials)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}
---
id: agent-setup.overview
title: Agent Setup
summary: Configure Project Context and Reference Materials so Teammately agents have reusable project understanding before contribution work.
kind: concept
product_area: agent_setup
status: stable
updated: 2026-09-07
canonical: /docs/agent-setup
---
# Agent Setup
Agent Setup is the project-level workspace for configuring reusable project understanding before Teammately agents prepare or conduct expert contribution work. Expert-facing presentation and contribution-specific behavior are configured through Assets and the Contribution workflow.
## Definition
Agent Setup contains one project-understanding group:
- **Project Understanding:** Project Context and Reference Materials.
These settings are reusable project foundations rather than settings for one benchmark or one expert. Review Screens and Comparison Directions are project Assets, not Agent Setup tabs.
Project Context contains the Project Agent Brief. Reference Materials uses the Materials and Indexed Reference tabs to organize project knowledge for agents. A Contribution selects its benchmark-specific objective, components, and agent behavior; Review Screens control reusable expert-facing presentation from Assets.
## Decision checkpoint
| Need | Open | Keep distinct from... |
| --- | --- | --- |
| Explain the project, target behavior, and stable operating context | Project Context | Project name or memo in General settings |
| Supply manuals, sites, repositories, or files to agents | Reference Materials | Governed policies, rubrics, and case materials |
| Set benchmark-specific agent behavior | Expert Contribution | Project-wide context and screen configuration |
| Guide meaningful response variation | Assets → Comparison Directions | Coverage facets, generated cases, or approved standards |
| Configure what an expert sees while reviewing | Assets → Review Screens | Contribution objectives and selected cases |
## Project and benchmark scope
Agent Setup belongs to the project because the same project context may support many benchmarks. A benchmark-specific Contribution still selects its own objective, expert, cases, attachments, contribution components, and agent behavior. Review Screens and Comparison Directions are authored under Assets and selected when the Contribution needs them. Agent Setup provides the reusable understanding foundation; it does not create or schedule contribution work by itself.
Changes can affect future agent preparation. Before making broad edits, inspect active benchmark work and confirm whether the new context should apply across the project. A narrow contribution-specific request belongs in the Contribution rather than in permanent Agent Setup.
## Authority boundaries
Reference Materials can inform agents but does not automatically create policies or rubrics. Review Screens change presentation and requested inputs, not the meaning of the underlying case or standard. Contribution configuration guides agent behavior but cannot supply human approval.
These boundaries make contribution evidence interpretable. Another operator can distinguish what the project told the agent, what evidence the contribution supplied, what the agent proposed, and what the expert decided.
{% example-demo title="Policy-review preparation" %}
Project Context explains that the assistant must prioritize the current procurement agreement. Reference Materials indexes the agreement repository. A Review Screen shows the controlling document and relevant case-material fields. The benchmark Contribution then asks an expert to decide which behavior should become policy.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Product quickstart](/docs/quickstart)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Configure Project Input Schema](/docs/project-settings/input-schema)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Project Context](/docs/agent-setup/project-context)
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Comparison Directions](/docs/assets/comparison-directions)
- [Review Screens](/docs/assets/review-screens)
{% /related-card-grid %}
## Source confidence
Code-backed: the active Agent Setup layout and project navigation define these groups, labels, and routes.
---
id: agent-setup.reference-materials
title: Reference Materials
summary: Connect project knowledge, inspect indexing state, and verify the blocks available to Teammately agents.
kind: reference
product_area: agent_setup
status: stable
updated: 2026-09-07
canonical: /docs/agent-setup/reference-materials
---
# Reference Materials
## Definition
Reference Materials is the Agent Setup workspace for project knowledge that Teammately agents may use. **Materials** is the unified inventory for websites, Git repositories, and uploaded files. **Indexed Reference** shows the published reference blocks available after extraction and indexing.
Reference Materials is project understanding, not governed correctness. A manual can support an agent's reasoning or an expert Contribution without automatically becoming a policy, rubric, case, or approved statement.
## Fields, states, or lifecycle rules
- A Material identifies a source and its ingestion or freshness state.
- Websites, Git repositories, and files follow source-specific discovery and processing paths in the unified Materials inventory.
- Indexed Reference presents published blocks rather than a second editable copy of the source.
- Publication is atomic: agents should see a coherent published generation rather than a partially updated index.
- Reconnecting, refreshing, or processing a source can create a newer indexed generation. Completed Runs and Contributions keep their own recorded evidence boundaries.
- Removing a Material or source does not imply that previously materialized policies, rubrics, cases, or contribution records should be silently deleted.
- File upload acceptance depends on file type, size, content verification, and the active source-processing path.
## Materials and Indexed Reference
Use Materials to answer: which sources are present, when were they processed, and does a source need attention? Use Indexed Reference to answer: what text or blocks can agents actually retrieve now? A material can be present without the expected controlling content appearing in Indexed Reference.
When sources conflict, retain the conflict in the indexed material and resolve correctness through an expert contribution or governed policy. Do not rewrite Project Context to hide source disagreement.
{% example-demo title="Example: reference publication check" %}
A team adds a policy website and a Git repository containing operational rules. After processing, the operator opens Indexed Reference and searches for the current exception clause. The website block is current, while the repository still contains an older rule. The operator keeps both materials visible and requests an expert Contribution to establish the controlling policy.
{% /example-demo %}
## Source confidence
Code-backed: the active Agent Setup routes expose Materials and Indexed Reference, and the backend publication service supports coherent indexed-reference publication. Exact connector availability may depend on the current product configuration.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Product quickstart](/docs/quickstart)
- [Maintain Project Context](/docs/agent-setup/project-context)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}
---
id: project-settings.input-schema
title: Project Input Schema
summary: Define the canonical input architecture, case-material fields, and accepted artifact formats for project cases.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/input-schema
---
# Project Input Schema
## Definition
Project Input Schema is the project-managed contract for future cases. It declares the primary input architecture, optional structured-input schema, named case-material fields, and artifact families or file extensions the project accepts.
The active architectures are **plain text**, **chat**, and **structured**. The schema is a project singleton rather than a versioned benchmark object. When no setting exists, the default accepts one plain-text user message and no case materials or artifacts.
## Fields, states, or lifecycle rules
- `architecture` is `plain_text`, `chat`, or `structured`.
- Structured architecture requires a bounded `structuredInputSchema`.
- `caseMaterialSchema` is a closed, flat object. Each material key has a label, optional description, required flag, type, and any accepted artifact rules.
- Material keys use lowercase letters, digits, and underscores, start with a letter, and remain flat.
- `acceptedArtifacts` declares project-level artifact families. Supported families are image, document, tabular, presentation, source text, and audio.
- A case-material artifact rule must be a subset of the artifact families admitted at the project root.
- Saving a new schema governs future case validation. Operators should inspect existing cases before making a change that would make current content invalid.
## Canonical case content
The primary case payload is `content.input`. Optional supporting values and artifacts live in `content.case_materials`. The product renders `record_content.case_view` so people and execution adapters can inspect the canonical content consistently; that view is a projection rather than an alternate authoring contract.
Static support passed to a Harness uses `case_material_refs`. An executable or queryable environment uses an optional `world_instance_ref`. Do not collapse static documents, images, or values into the world boundary merely because a candidate consumes them during a Run.
{% example-demo title="Example: structured support case" %}
A project selects structured input with `question` and `customer_tier` properties. It declares a required `policy_document` case material that accepts PDF documents and an optional `account_history` tabular material. A case is valid only when its structured input matches the schema and the required document is present in the accepted format.
{% /example-demo %}
## Source confidence
Code-backed: the active settings route and backend validator define the input architectures, closed case-material schema, artifact families, defaults, and canonical case paths. This page explains the product contract without presenting internal handlers as a public API.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Project Settings](/docs/project-settings)
- [Product quickstart](/docs/quickstart)
- [Work with cases](/docs/assets/cases)
- [Design Review Screen](/docs/assets/review-screens)
{% /related-card-grid %}