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.
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 and 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.