Context and capabilities

Context and capabilities solve different problems. Context affects what the agent reasons from; capabilities determine which actions it can attempt.

Context is what the agent can know

Several layers contribute context, from broadest to most specific:

1. The active agent contract explains the d5s environment and tool semantics.
2. The work mode adds chat, automation, dashboard, or persistent-agent behavior.
3. Project instructions, memory, skill summaries, and project files supply durable context.
4. Conversation history and session files supply work-specific context.
5. The current message and its attachments state the immediate task.

The active agent contract also supplies the current UTC date and identifies UTC as the prompt timezone. This gives the agent a stable reference for requests such as “next week” or “in September”; an exact scheduled wakeup still stores an absolute instant derived from the timezone selected for that wakeup.

Project memory is backend-managed semantic knowledge accessed through the memory tool. It is not a folder in the sandbox. Likewise, project skills are app-managed capability packs, not arbitrary files copied into /workspace.

The sandbox is execution state. Agents may clone repositories, install packages, and create scratch files there, but only surfaced artifacts and explicitly stored project knowledge should be treated as durable product context.

Capabilities are what the agent can do

• Platform tools cover execution, files, artifacts, memory, skills, tasks, research, and d5s-native proposals.
• Skills provide versioned operating instructions selected for the project.
• Connectors provide governed access to external services through a workspace credential.
• Model and reasoning controls determine the model used for a run within workspace policy.

Capabilities can still be narrowed per run. A chat may disable specific tools, a sub-agent profile may expose a smaller tool set, and a connector tool can be allowed, approval-gated, or denied.

A provider can expose more than one connector method. For example, one method may authorize a remote MCP server while another uses a restricted API credential; the chosen method determines the external operations available to the run.

Ordinary web access is provider-neutral at the agent boundary. The agent can make up to three search attempts and five page-read attempts in one run. A read accepts only a URL written in the newest user message or a source returned by a successful search in that run. Repeated normalized queries, repeated URLs, and unauthorized read attempts consume the same budget, so retry loops and parallel calls cannot bypass the limits. Disabling web search for a message also removes page reading. Each read resolves and validates every redirect, rejects private network addresses, pins the connection to the validated address, and bounds both the fetched body and the text returned to the model. Returned page text is explicitly marked as untrusted evidence.

When deep research is enabled, one user turn can start at most one research pipeline. The agent should use one comprehensive query and synthesize any further analysis from the returned evidence; additional deep-research calls in the same turn are not run.

Availability is not activation

A capability moves through distinct states:

1. It exists in the platform or workspace catalog.
2. A workspace administrator installs a skill or connects a credential.
3. A project activates a specific skill version or connector credential.
4. The run's profile and tool settings include it.
5. Runtime policy allows the exact action, asks a person, or denies it.

An agent uses the activations on its home project. An automation or dashboard uses the activations on the project selected for future runs. Changing an activation affects later runs; it does not rewrite the event history of earlier executions.