# Context

---

## What it is

The **Context** page describes itself as "The context your agents work from — how your organization builds, ships, and operates — gathered in one place so every session and task starts grounded in your real setup instead of rediscovering it each run." Under it, "Last built: <date>" says when it was last built.

## What a build gathers

A build gathers:

- **Repositories** — the repositories reachable through your GitHub, GitLab and Bitbucket installations. For GitHub repositories it also reads the deploy configuration in them — Dockerfile, Procfile, compose files, serverless, Helm, Kubernetes manifests and GitHub Actions workflows — to tell which repository a service runs.
- **Services** — the services Deployment.io deploys for you.
- **Live infrastructure** — scanned by your runner in its own AWS account and region. Today that is Amazon ECS clusters and services: each service's image, ports and the names of its environment variables. Other AWS services aren't scanned yet. Deployment.io's own runner clusters are skipped.

## Building it

With no context yet, the page shows "No context built yet" and "Connect your integrations, then build context so every session and task starts grounded." Click **Build context** to build it.

Afterwards, the header has **Refresh**. It shows "Building…" while a build runs.

Scanning your live infrastructure needs a running runner. Without one, the page shows "Install and start a runner to include your live infrastructure in context."

### When it refreshes on its own

When a Task or an Assistant session starts and the context is more than a day old, it is refreshed first. It is not rebuilt on a schedule or after a deploy.

## The summary cards

The page has four summary cards: **Repositories**, **Services**, **Clusters** and **Drift**.

**Drift** means the repository found from a running service's image disagrees with the repository whose deploy configuration names it, and nobody has confirmed which is right. Services Deployment.io deploys never show drift.

The page lists what needs attention:

- "<n> service(s) report(s) drift — the running image disagrees with the deploy config." with **Review**
- "<n> service(s) without a repository — connect them so agents (and future adoption) know where the code lives." with **Connect**

To confirm or correct a service's repository, see [Services](/docs/resources/services/).

## What the agent gets

At the start of a Task or session, the context is written to /work/context as files:

- an index
- a services map, with one entry per service: its repository, where that came from (managed, answered, observed or derived), how confident that is, and drift. For services Deployment.io deploys, it also has their environment, type, ports, health check and the names of their variables, build arguments and env files.
- the files behind it

The Review and QA stages get a read-only copy. See [Review](/docs/tasks/review/) and [Previews](/docs/tasks/previews/).

## No secret values

The context holds names and structure only. The scan reads only the names of a container's environment variables and secrets, never their values.

Any value whose key looks like a password, secret, token, API key, access key, private key, credential, connection string or authorization header is replaced with "[redacted]" before it leaves your runner.

## Who can use it

Anyone in the organization can build context and set a service's repository.

---

Source: https://deployment.io/docs/resources/context/