Agents and capabilities
Understand the platform-level relationship between agents, capabilities, tools, permissions, execution stages, and current evidence limits.
Agents and capabilities
This page defines agents at the platform level so readers can discuss goals, capabilities, tools, permissions, and boundaries without prematurely documenting the later Agents runtime. Use it when a task involves more than a direct model response or may require review before action. Batch 01 confirms the control vocabulary and shell concepts, but not a complete agent lifecycle, automatic tool use, role model, or production availability for every agent surface.
What an agent is
An agent is a bounded actor that uses model reasoning and available context to pursue a defined goal. The word bounded is essential: an agent should be understood through what it can read, what it may propose, which tools or integrations are configured, which actions require approval, and what evidence is preserved.
A direct model request and an agent task are not identical. A model request asks a selected model for an output. An agent task may coordinate multiple decisions, tools, or stages around a goal. The model can contribute reasoning, but the agent boundary includes configuration and control outside the model itself.
At platform level, describe an agent with six questions:
| Question | Purpose |
|---|---|
| What is the goal? | Defines the desired outcome and stopping condition |
| What context is available? | Limits the information the agent can use |
| Which capabilities are relevant? | Identifies the kinds of work needed |
| Which tools or integrations are configured? | Establishes possible external operations |
| Which permissions and approvals apply? | Separates ability from authorization |
| What evidence will be retained? | Makes review and verification possible |
Do not infer the answers from an agent name or interface label.
At the platform level, an agent is a pattern for completing work that may combine model reasoning, visible planning, permitted capabilities, tools, and review boundaries.
This batch does not define one universal agent runtime. Do not infer autonomy, durability, background execution, or external side effects from the word agent.
Capabilities
A capability is a category of work an agent or model can support. For models, the verified catalog families include text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown. For agents, capabilities can be discussed more broadly as reading context, analyzing information, drafting a proposal, selecting a model, preparing a workflow, or using a configured tool.
Capability is not availability. A model can be classified for code and still be catalog-only. An agent can be designed to use a tool while the integration is unconfigured. A workflow can include an approval step without proving that a live approval control exists on the current surface.
A capability statement should identify its owner. “The model supports image work” refers to a model record. “The agent can call an image tool” refers to an agent configuration. “The product can generate an image” requires evidence from the product route and runtime.
A capability is the class of work a surface can support, such as reading context, producing an artifact, searching, or preparing a tool action.
The current product surfaces do not provide a canonical capability registry or per-role matrix. Describe capabilities only at a high level and verify the active surface before claiming that a specific capability is available.
Tools
Tools extend an agent beyond model output by exposing callable operations. A tool might retrieve information, transform data, or interact with another system, but Batch 01 does not define specific tool contracts or connector coverage.
Before treating a tool as usable, verify:
- its exact name and owning product;
- supported inputs and outputs;
- credential or provider requirements;
- whether the operation is read-only or state-changing;
- the approval boundary;
- timeout, failure, and retry behavior;
- evidence recorded for the call.
A tool description is not execution evidence. The result should be identifiable through a tool output, receipt, artifact, log, or verification note where the product supports those records.
A tool is a concrete operation that an agent or workflow may be able to call. It is narrower than a capability and should have an explicit contract in product-specific documentation.
The inspected Batch 01 sources do not define tool names, schemas, credentials, retries, or side effects. Those contracts belong in the later agent, workflow, and integration pages.
Permissions
Permissions determine whether an actor may use a capability, context source, tool, integration, credential, or execution path. The current Batch 01 sources do not define agent permission objects, workspace roles, inheritance, or least-privilege enforcement.
Separate four ideas:
- Capability: the kind of work can be represented.
- Configuration: the required model, provider, tool, or credential is connected.
- Permission: the actor is allowed to use it.
- Approval: a specific sensitive action has been authorized.
A system can satisfy the first two and still block the action on permission or approval. Conversely, an approval cannot make an unsupported modality or missing credential work.
When permissions are not visible, keep the agent in read or propose stages. Do not document a successful external action without direct runtime evidence.
Permissions determine whether a person or agent may access context or attempt an action. No complete permission model is supplied here.
Do not convert documentation audiences into roles. Do not infer authorization from UI visibility. Sensitive actions should remain behind the approved proposal and approval boundary when the implementation supports execution.
Execution lifecycle
A conservative agent lifecycle follows the platform control model:
- Define the goal. State the outcome, scope, and stopping condition.
- Assemble context. Provide only the permitted information needed.
- Select resources. Choose models, providers, tools, or integrations using current status.
- Read. Inspect the context or current external state.
- Propose. Produce a plan, draft, route, or candidate action.
- Review and approve. Evaluate the proposal and authorize sensitive work through the supported product control.
- Execute. Perform the action only if runtime, permission, and configuration allow it.
- Verify. Inspect the result and preserve receipts, artifacts, logs, outputs, or notes.
This lifecycle is a documentation framework. Detailed run states, scheduling, retries, concurrency, cancellation, and recovery belong to later truth packs.
A safe platform-level lifecycle is Read → Propose → Approve → Execute. The model or agent can read authorized inputs and produce visible work before any supported state-changing action is approved.
The sources do not establish run-state enums, queues, timeouts, retries, cancellation, or recovery. Those details must come from the agent runtime batch.
A bounded agent brief
Before implementation, write an agent brief that can be reviewed without code or interface assumptions:
- Goal: one measurable outcome.
- Allowed context: the exact sources the agent may inspect.
- Model requirements: capability, context, status, and provider constraints.
- Proposed tools: names and purposes, pending contract verification.
- Read operations: information the agent may gather without changing state.
- Proposed actions: outputs that require review.
- Approval boundary: the condition that must be satisfied before execution.
- Verification: evidence required to call the result complete.
- Stop conditions: missing configuration, unsupported modality, denied approval, or unresolved target state.
This brief keeps later product work aligned with the platform control model. It also reveals where a requirement depends on a runtime detail that Batch 01 cannot support.
Capability composition
Complex work often combines several capabilities. A research agent may need long-context reading, reasoning, and reranking. A coding workflow may need code generation plus a verified tool for tests. A voice workflow may involve transcription, reasoning, and speech output. The existence of each model family does not prove that one agent can combine them.
For every composition, verify the handoff between stages. Identify the artifact passed forward, its format, the next model or tool, and the evidence that the handoff succeeded. If one stage changes provider or product surface, recheck data handling, status, and approval.
Evaluating an agent proposal
Review the proposal at the boundary it reaches. For a read-only research agent, judge source use and reasoning. For a tool-assisted proposal, inspect the target, inputs, expected effect, and failure handling. For an execution claim, require evidence from the tool or target system.
Do not reward an agent for sounding decisive when it should remain uncertain. A correct stop caused by missing credentials or absent approval is preferable to an invented success. The quality of the boundary is part of the quality of the agent.
Boundaries
An agent boundary is where a stronger claim requires new evidence. Important boundaries include:
Context boundary. The agent should not be assumed to see every workspace item or prior session.
Model boundary. Model capability and context limits constrain the reasoning path, even when the agent has a broader goal.
Provider boundary. A model may require configuration or credentials that are absent.
Tool boundary. The tool contract determines what can be read or changed.
Approval boundary. A proposed action remains a proposal until the supported control authorizes it.
Verification boundary. A success message is weaker than evidence from the target system or an inspectable receipt.
Product boundary. A platform-level agent concept does not establish behavior in Workflow Agent, Sentinel, Studio, Voice, or another dedicated surface.
Use these boundaries to write accurate requirements now and defer implementation claims to the later Agents and Workflows documentation. This page remains a draft because the available sources support the mental model, not a complete runtime specification.
Agent boundaries include available context, permitted capabilities, tool scope, approval requirements, product maturity, and the difference between a draft, simulation, dry run, and live execution.
Keep each boundary visible to the reader. If a surface is preview, mock, or setup-required, do not describe its proposed actions as completed external work.
Stop conditions
An agent specification should define when the system must stop rather than improvise. Examples include absent context, a catalog-only model, missing credentials, unsupported modality, an undefined tool contract, denied approval, or missing target verification. A stop should produce a reviewable explanation and preserve the proposal where useful.
Stop conditions protect against the common failure of converting uncertainty into action. They also give later product tests a concrete expected outcome: the agent should refuse to cross a boundary that its configuration and evidence cannot support.