Coming from Anthropic's API

Code that follows Anthropic’s Managed Agents quickstart runs on your Context deployment with these changes:

1. Point the SDK at your deployment’s host and authenticate with a Context Task API key, either a personal key or a service account key. Choose a key explains which one to use.
2. Don’t create an environment. Pass env_default as the session’s environment.
3. Create the agent with a personal key that has the agents:write capability, or pick an existing agent with List agents.
4. Stop reading the stream only when session.status_idle has a stop_reason.type of end_turn or retries_exhausted. Answer requires_action with user.tool_confirmation.
5. Turn off SDK retries, because sending events isn’t idempotent (see SDKs).

You can’t configure an environment through the API, so there are no per-environment packages or network allowlists. On a self-hosted (KOTS) deployment, the network allowlist is one setting for the whole deployment, in the KOTS Admin Console (see Network access).

Other calls differ. See What’s stubbed or ignored, Not supported and Behavior that differs.

To find these changes in an existing codebase, install the Context Managed Agents skill in your AI coding agent, such as Claude Code. It flags every call Context refuses and rewrites what it can. See Build with an AI coding agent.

Anthropic’s quickstart on Context

Anthropic’s step	On Context
Create an agent	Works with a personal key that has the agents:write capability. Set model to default or to a model your deployment runs. In tools, include only the built-in toolset. To use an agent built in the app, call List agents instead.
Create an environment	Returns 400 for the body Anthropic’s quickstart sends, which sets limited networking and package managers. For network access on Context, see Network access. Use env_default (see Environments).
Create a session	Works unchanged. Pass the agent ID from the first step and env_default.
Stream, then send a message	Works, with one change to your loop. Stop on a session.status_idle whose stop_reason.type is end_turn or retries_exhausted, not on any idle. An agent with a tool that needs approval (the Ask setting in the Context app) goes idle with requires_action first. Answer it with user.tool_confirmation, as shown in Send events.

Headers

anthropic-workspace-id is served: it names the Context workspace the request runs in, and the key’s owner must work there. For the headers Context ignores or refuses, see What’s stubbed or ignored.

What’s stubbed or ignored

Some calls and inputs that Anthropic’s SDKs send get a normal response from Context, but Context doesn’t do what Anthropic’s API does with them. This table lists each one, along with the related calls that return an error.

Anthropic call or input	What Context returns or does
environments.create with no config, or a cloud config with unrestricted networking and no packages	Returns env_default. It creates nothing, and every call returns the same environment. name, description and metadata are ignored.
environments.create with packages, limited networking, self_hosted, scope or any other config	Returns 400.
environments.update, environments.delete and environments.archive	Return 404, because Context doesn’t serve these paths.
env_default’s config and timestamps	config always reports unrestricted networking and empty packages, even when a self-hosted deployment restricts sandbox network access. The environment’s description, created_at and updated_at never change.
include_archived on environments.list	Context ignores it. No environment is ever archived.
The anthropic-version and anthropic-beta headers, and the beta=true query parameter the SDKs add	Context ignores them, so the headers can hold any value.
The Idempotency-Key header	The SDKs send this header only when you pass an idempotency key as a request option. Requests with Idempotency-Key return 400, so don’t pass one. Context doesn’t deduplicate requests, so a retried request runs again.
anthropic-workspace-id on files, environments and skills requests	Context checks that the key’s owner works in that workspace, then ignores the header. If the owner doesn’t work there, the request returns 404. Files and skills belong to the key’s owner, not to a workspace.
web_search in an agent’s tools	In the built-in toolset, web_search always reads back with enabled: false, and it never runs. Agents search the web with Context’s own search tool. You can leave it out or send it with enabled: false. Naming it without enabled: false, or with enabled: true, returns 400.
execution_identity on an agent	Only {type: "service_account"} is accepted, and it changes nothing. Every agent reads back that value. Any other value returns 400.
Agent fields Context doesn’t use	Every agent reads back version: 1, archived_at: null, metadata: {}, mcp_servers: [] and multiagent: null.
expires_in_seconds on files.upload	Context checks the value against Anthropic’s range of 3,600 to 7,776,000 seconds (1 hour to 90 days), then ignores it. A value outside the range returns 400. Files never expire and have no expires_at.
metadata, vault_ids and budget on sessions.create	An empty metadata, an empty vault_ids and a null budget are ignored. Any other value returns 400.
Session fields Context doesn’t use	Every session reads back metadata: {}, vault_ids: [], budget: null, outcome_evaluations: [] and stats: {}.
The rescheduling status in the statuses filter on sessions.list	Context accepts it, but it matches nothing, because no session is ever rescheduling.
Usage on session.usage events and on the session	session.usage events have no list_cost. On the session, list_cost is null until billing settles. Every cache write counts as a 5-minute write, so ephemeral_1h_input_tokens is always 0. server_tool_use is never sent.

Not supported

• Agents:
  • Versioning and archiving an agent return 404. Every agent has one version, 1, and an update has no conflict check.
  • tools takes only the built-in toolset. Custom tools, MCP servers, the auto permission policy and the web tools’ domain and location options return 400. You can’t turn on web_search (see What’s stubbed or ignored). Because mcp_servers returns 400, so does GitHub’s MCP server.
  • multiagent and a model’s effort, inference_geo or speed return 400. Without multiagent there are no workflow runs, so workflow_run.* events are never sent.
  • On list, include_archived=true and the created_at filters return 400.
  • On create, metadata takes only workspace_id. Any metadata on an update returns 400.
• Environments: You can’t create a custom environment or use limited networking. For what each environment call returns, see What’s stubbed or ignored.
  • The environment work endpoints, which Anthropic’s self-hosted environment worker polls, aren’t served. Their paths return 404.
• Sessions:
  • Agent overrides, a non-empty metadata, vault_ids and budget return 400. For the values Context accepts, see What’s stubbed or ignored. If the agent object includes a version, it must be 1.
  • initial_events takes at most one user.message. More than one returns 400.
  • Only file resources work. The session resources endpoints aren’t served. Their paths return 404. A github_repository resource returns 400.
  • An update takes only title. agent, vault_ids, budget and a non-empty metadata return 400.
  • The session threads endpoints aren’t served. Their paths return 404.
  • On list, order=asc and the agent_version, deployment_id and memory_store_id filters return 400.
• Events:
  • event_deltas and session_thread_id return 400, because event deltas and threads aren’t supported.
  • Sending user.tool_result, user.custom_tool_result, user.define_outcome or system.message returns 400.
  • A user.message takes only text blocks. Any other block, such as an image, returns 400, and so does cache_control on a text block.
  • Only 11 event types are sent. For the list, see Events.
  • session.error uses five error types. MCP, credential and repository error types are never sent, and retry_status.type is never terminal.
• Files: On List files, ids and a limit over 100 return 400. You can’t delete a session’s output files on their own, or attach them to another session. Deleting the session removes them.
• Skills: A skill on an agent takes only latest as a version. Deleting a skill version returns 400. The built-in skills include no pdf skill. Writing to a built-in skill returns 400.
• Other resources: Vaults, memory stores, MCP configuration, webhooks, outcomes, budgets, deployments, deployment runs, dreams, tunnels and user profiles aren’t served. Their paths return 404.
• CLI: Anthropic’s ant CLI isn’t supported.

Behavior that differs

• Deleting a session: The key needs the sessions:delete capability, which is off by default. You can turn it on only when you create the key (see Keys). While a turn is running, the request returns 409. Send user.interrupt, then delete the session once it’s idle. The response lists what was removed and what is kept.
• Archiving a session: You can archive a running session, which Anthropic’s API refuses. The current turn isn’t cut short, so send user.interrupt first to stop it.
• Keeping data: Nothing expires or is deleted on a schedule. Your deployment keeps sessions, files and skills until you delete them. See How long data is kept.
• Mounting files: mount_path takes a path under /workspace/ or /mnt/session/uploads/. Any other absolute path is placed under /mnt/session/uploads/, so /data.csv becomes /mnt/session/uploads/data.csv. A file sent without mount_path isn’t copied to the agent’s disk. It stays in the session’s inputs/ folder. On Anthropic’s API, such a file is mounted at /mnt/session/uploads/<file_id>.
• Session outputs: The agent writes them to /mnt/session/outputs/, as on Anthropic’s API. List them by setting scope_id to the session ID on List files. They stay listed after the session is archived.
• Agent instructions: The system field reads null unless the calling key’s owner created the agent.
• Skills: A skill belongs to the key’s owner, not to a workspace. Skill requests ignore the workspace anthropic-workspace-id names (see What’s stubbed or ignored). Creating a skill needs the skills:write capability, which only a personal key can have. display_name must match the name in SKILL.md. Each deployment has its own built-in skills. List skills returns them, and each one is identified by its slug.

Limits and values that differ

What	Context	Anthropic
Session title	Up to 280 characters	Up to 500 characters
Files per session	50	500
File size	Up to 5 GiB by default, set per deployment	Up to 500 MB
List limit	Up to 100 (events: 1,000, skills: 200)	Up to 1,000
Rate limits	If your deployment enforces rate limits: 7,500 requests a minute per personal key, or 2,500 per service account key	Per organization: 300 creates and 1,200 reads a minute
error.type on 409	invalid_request_error, so check the status code instead	conflict_error
ID returned when you send an event	sevt_receipt_<uuid>	The event’s ID

A session request with more than 50 files returns 500 instead of a named 400. This is a known defect.

Sending an event returns a receipt ID, not the event’s ID. The stored event gets its own ID, which appears on the stream and in the session’s history.

Context extensions

Anthropic’s API has none of these:

• The stream takes a Last-Event-ID header to resume after a disconnect.
• List files takes after_id and before_id and returns has_more, first_id and last_id.
• On POST /v1/sessions only, a service account key can send x-context-owner-user-id or x-context-owner-user-email (one, not both) with a member’s user ID or email, to create a session that member owns.
• To create an agent in a workspace, send metadata.workspace_id.