How agents work

An agent is a configured identity in a workspace. It has instructions, skills, policies, grants, and optional ambient triggers. You can use the same agent from the dashboard, API, or an automated signal. The important distinction is between the long-lived agent configuration and the work it performs.

​

Dashboard-native guidance

In the dashboard, an agent is more than a text box. It can behave like an interactive guide for deployment and operations work:

• Ask clarifying questions when a request is ambiguous.
• Render approval prompts before sensitive actions.
• Show deployment progress, status cards, documentation cards, and code blocks inline.
• Link or navigate to the right dashboard page when a visual workflow is better than chat.
• Adjust its language to the user’s experience level.

This lets a user describe intent, such as “deploy my app”, while the agent turns that intent into structured platform actions and reviewable decisions.

​

Core resources

Sessions are cheap to keep open. Runtime environments are only used when a task needs files, a shell, a browser, git, package managers, or long-running command execution.

​

Agents are not tied to one runner

The API describes what an agent is allowed to do, not which internal runner executes it. A read-only triage agent might only call platform tools. A coding agent might use a retained workspace with repository access, command execution, package managers, and test tooling. This keeps the public contract stable as the runtime improves. For platform operations, agents should prefer fast structured API work. For tasks that need files, repositories, scripts, package managers, browsers, or state between turns, they can use a retained runtime. Users see one conversation either way.

​

Repository change requests are the review surface

When an agent needs to change repository-backed installation source or configuration, the default path is a repository change request. The agent reads existing change requests in the workspace, checks whether work is already in progress, and creates a new request only when needed. This prevents duplicate work and keeps production changes reviewable. Repository change request access is controlled by grants, and accepting a change can require a separate approval request. Read access does not imply permission to accept a change.

​

Sessions produce events

Every turn emits events that the dashboard and API can display:

• Messages from the user, system, or assistant.
• Progress updates for platform, git, shell, browser, or repository work.
• Interactive UI outputs such as approval cards, status cards, forms, or documentation cards.
• Runtime start, stop, and resume events.
• Artifacts such as repository change requests, diffs, summaries, logs, or files.
• Handoff summaries and cancellation events.

The event stream is the source for chat replay, audit views, and external integrations.

​

Related topics