Agent execution always follows the service account, tenant policy, and operator roles. Configuring a capability never grants access that the execution principal does not already have.
What the Agents workspace makes visible
The workspace separates the conversational Threads surface from the managed Agents, Plugins, and Memory surfaces. An Agent detail then brings together its run history, inbox, configuration, workspace files, and activity evidence. Treat those as different operational questions: a thread is a collaboration context; an Agent is a durable definition with an execution principal and trigger policy.Agent definition
An Agent definition has three practical layers:
The service account is the runtime identity. The Agent can only read or change what that principal and the current platform policy permit. The owner controls visibility and management; ownership does not silently add runtime privileges.
Status
- Active accepts and executes new work.
- Paused temporarily stops new work while preserving the definition and history.
- Disabled retires or hard-stops the Agent until an operator changes its status.
Create an Agent
1
Define the responsibility
Give the Agent a narrow mission, clear success criteria, and explicit exclusions. Prefer one durable responsibility over a broad “do everything” description.
2
Choose the principal and owner
Select a service-account user with least privilege. Assign the Agent to the appropriate user or group owner.
3
Configure runtime behavior
Choose the model, reasoning effort, execution mode, planning policy, and persistent Agent instructions. Set concurrency and run limits for the expected workload.
4
Select capabilities
Enable the platform tools and attach only the plugins required by the mission. Define default and per-tool permission policies.
5
Review the workspace
Use the managed workspace created with the Agent or link an existing authorized folder. The workspace root becomes the durable file boundary for runs.
6
Start with a bounded run
Submit one direct instruction, inspect the trace and outputs, then add inbox, schedule, or event delivery after the behavior is proven.
How work reaches an Agent
Inbox items support a priority, an optional future availability time, an opaque task payload, and a per-Agent de-duplication key for non-terminal work.
Runs and sessions
An Agent run moves through durable states:CREATED → PENDING → PROCESSING → FINISHED
A run can instead become ACTION_REQUIRED, ERROR, or CANCELLED. Capacity-limited or delayed work remains pending with an observable reason rather than disappearing.
A session links follow-up root runs into one durable continuation. Continuing a terminal run creates a successor; it does not rewrite the original run. This preserves history while allowing instructions such as “compare the result with last month.”
Operators can resume, retry, continue, or cancel a run. Ordered run events provide evidence across root, child, and handoff work.
Delegation
For suitable background or automation work, an Agent can split a plan into bounded child runs and merge their results. Configuration limits both the total number of child runs and the number that can run concurrently. A failure policy decides whether one child failure stops the parent or whether partial results may still be merged. Delegation is intentionally bounded. It is not an unrestricted process graph, and it does not expand a child Agent’s identity or permissions.Operate from the Agents workspace
The Agent detail view provides:- Overview — status, responsibility, current activity, task outcomes, model usage, and token trends;
- Runs — durable runs and operator controls;
- Inbox — queued instructions and claim state;
- Storage — files and folders inside the Agent workspace;
- Config — general, identity, runtime, and tool settings;
- Activity history and trace — definition history and ordered execution evidence.
Production checklist
- Use a least-privilege service account.
- Keep the responsibility and success criteria measurable.
- Start with
defaultpermissions and explicit approval routing. - Bound active root runs, child runs, concurrent children, and the execution budget.
- Add de-duplication keys for recurring or externally retried inbox deliveries.
- Require durable files only when the task genuinely needs a file deliverable.
- Inspect failed and blocked runs before enabling a wider trigger surface.
- Pause an Agent before changing behavior that could affect in-flight work.
Agent configuration
Configure identity, runtime, permissions, plugins, memory, workspace, and limits.
Operate Agents
Connect triggers, inspect runs, recover failures, and scale proven workloads.
Tools and skills
Understand the capabilities available to Assistant and Agent execution.
Memory and workspaces
Place durable knowledge and files in the correct store.