> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thecontextcompany.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What The Context Company captures

> The production data The Context Company records for every agent run, from prompts and responses to tool calls, errors, tokens, and cost.

For every production interaction, The Context Company records the complete execution alongside the transcript. That data is what powers patterns, failure detection, Insight Search, Recaps, and MCP.

## Captured for every run

| Data                     | Captured | Notes                                                                                 |
| ------------------------ | -------- | ------------------------------------------------------------------------------------- |
| User prompt              | Yes      | The initial input to the agent.                                                       |
| Agent response           | Yes      | The final output returned to the user.                                                |
| Multi-turn conversations | Yes      | Grouped as a [session](/concepts#sessions) when you set `tcc.sessionId`.              |
| Runs                     | Yes      | One end-to-end agent execution. See [runs](/concepts#runs).                           |
| Model calls (steps)      | Yes      | Each LLM request and response inside a run. See [steps](/concepts#steps).             |
| Tool calls               | Yes      | Every tool invocation triggered by the model.                                         |
| Tool arguments           | Yes      | The full arguments passed to each tool.                                               |
| Tool results             | Yes      | The result returned by each tool.                                                     |
| Errors                   | Yes      | Exceptions, error classes, and status messages at the run, step, and tool-call level. |
| Latency                  | Yes      | Duration per run, step, and tool call.                                                |
| Token usage              | Yes      | Prompt and completion tokens per model call.                                          |
| Model cost               | Yes      | Cost per model call, aggregated per run.                                              |
| Sessions                 | Yes      | Set `tcc.sessionId` to group runs into a conversation.                                |
| Conversational marker    | Yes      | Set `tcc.conversational` to enable behavioral analysis on real-user runs.             |
| Agent identifier         | Yes      | Set `tcc.agent` to promote runs to a first-class [agent](/concepts#agents).           |
| User identity            | Yes      | Set `tcc.userId` (and optionally `tcc.userName`) to segment by end user.              |
| Organization identity    | Yes      | Set `tcc.orgId` (and optionally `tcc.orgName`) to segment by account or tenant.       |
| User feedback            | Yes      | Thumbs up / thumbs down and up to 2,000 characters of free text per run.              |
| Custom metadata          | Yes      | Arbitrary key/value fields attached to a run for filtering and analysis.              |

## Why execution-level data matters

Conversation-only analytics can only see what was said. Execution-aware analytics can see what actually happened. That difference matters because agents can produce plausible-looking transcripts on top of broken executions.

Concrete examples that execution data makes visible:

* A support agent tells the user "your refund has been processed" but the `issueRefund` tool returned an error the model ignored.
* A retrieval agent generates a confident answer even though the retrieval tool returned an empty result.
* An agent retries the same tool with the same arguments five times in a loop, burning tokens without progress.
* A tool call succeeds technically (200 OK) but writes the wrong record to a downstream system.
* The agent calls the wrong tool for the user's intent and produces a fluent but incorrect answer.

Because tool arguments, results, and errors are stored per run, these failures show up in [patterns](/analyze/patterns), the [failures view](/analyze/failures), and [Insight Search](/analyze/insight-search) even when the transcript looks fine and the user never complained.

## The data hierarchy

Everything The Context Company captures rolls up through the same structure:

```text theme={null}
Organization (your customer / tenant)
  └── User (end user of your agent)
       └── Session (conversation, if grouped)
            └── Run (one end-to-end agent execution)
                 ├── Model step (LLM request + response)
                 │    └── Tool call (name, arguments, result, error, latency)
                 ├── Feedback (thumbs, text)
                 └── Metadata (custom + reserved tcc.*)
```

Read the [Concepts](/concepts) page for the full definition of each level and the exact metadata keys used to populate them.

## How to attach identity and context

Reserved [`tcc.*` metadata keys](/concepts#tcc-metadata-keys) promote fields into first-class dimensions:

* `tcc.sessionId`, `tcc.conversational`, `tcc.agent`
* `tcc.userId`, `tcc.userName`
* `tcc.orgId`, `tcc.orgName`

Everything else you attach becomes custom metadata that can be filtered in the dashboard, API, and MCP.

Framework-specific syntax is documented on each [integration page](/frameworks/vercel-ai-sdk/index).

## Related

<CardGroup cols={2}>
  <Card title="Concepts" icon="cubes" href="/concepts">
    Runs, steps, tool calls, sessions, users, and organizations.
  </Card>

  <Card title="Traces" icon="diagram-project" href="/investigate/traces">
    How captured data renders as a full trace.
  </Card>

  <Card title="Data collection" icon="shield-halved" href="/security/data-collection">
    What is stored, where, and for how long.
  </Card>

  <Card title="PII redaction" icon="user-shield" href="/security/pii-redaction">
    Redact sensitive fields at ingest.
  </Card>
</CardGroup>