> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent dashboard
> Configure ambient agents and interpret agent-generated widgets in the Akua dashboard
The dashboard is the primary managed experience for hosted agents. It gives users a chat surface, approval inbox, event history, and resource-aware widgets without requiring local agent setup.
The managed dashboard experience is rolling out in phases. API resources and generated reference docs are available while some dashboard controls may appear only for enabled workspaces.
## Configure ambient agents
Ambient agents start from workspace signals instead of a chat message. Configure them when you want Akua to investigate operational signals proactively.
Start from a platform template such as failed-install triage, or create a workspace agent with the skills and grants it needs.
Turn on ambient operation for the agent and choose the signals it can receive.
Pick trigger types such as install failure, degraded cluster, security finding, quota pressure, or cost anomaly. Set a minimum severity and cooldown so repeated signals do not create noisy duplicate work.
Prefer read-only triage by default. Allow retained runtimes only when the agent may need repository edits, tests, or package-manager work.
Give read grants for resources the agent needs to inspect. Keep mutation grants specific, and require approval for sensitive actions such as accepting repository change requests or accessing secrets.
An ambient run should always leave a reviewable summary in its session. The summary explains the trigger, inspected resources, conclusion, next action, and links to related resources.
## Interpret widgets
Agents can emit typed widgets into the dashboard event stream. Widgets are not separate state stores; they are views over canonical resources such as approval requests, repository change requests, installs, renders, operations, snippets, and documentation links.
| Widget | What it means |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Approval card | The agent is waiting for a runtime-gated action, such as running a command or accepting a change. |
| Choice card | The agent needs a structured decision before it continues. |
| Status card | The agent is summarizing resource state, progress, or a completed investigation. |
| Navigation hint | The agent found a relevant dashboard area and can take you there. |
| Repository change request review | A fork-backed source/config change is ready to inspect, accept, reject, or withdraw. |
| Secret input | The agent needs a credential reference and should route you through the secret flow instead of seeing raw secret values. |
Widgets may combine multiple resources. For example, a failed-install widget can show the install, recent render, existing repository change request, and prepared next actions in one place.
## Reactive state
Widgets should stay current from canonical resource state. If a repository change request moves from `READY` to `ACCEPTING`, the widget updates from that resource state instead of relying on stale assistant text.
When a widget includes an action, the action calls the underlying resource API. Examples:
* Resolve an approval request.
* Start a new agent turn with a prepared reply.
* Create or accept a repository change request.
* Run an attributed snippet action.
* Navigate to an install, render, operation, cluster, or repository.
This keeps dashboard behavior, API behavior, and agent behavior aligned.
## Related topics
Understand ambient trigger concepts and policy boundaries.
Use the same resources from the API.