Skip to main content

Documentation Index

Fetch the complete documentation index at: https://akua-1dce587a.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Ambient agents are agents that can start work from workspace signals instead of waiting for a chat message. They are useful for operations teams, sellers managing customer deployments, and customers who want faster incident context. Ambient means “always available”, not “always spending compute”. Most ambient agents run as lightweight policies until a configured condition matches.

​
What they watch

Ambient triggers can watch signals such as:
  • Failed or degraded installations.
  • Cluster health changes.
  • Security findings.
  • Quota pressure.
  • Cost or usage anomalies.
  • Customer-defined operational events.
When a trigger matches, Akua creates or updates an agent session with a system-origin turn. The result appears in the same dashboard and API views as user-created sessions. Every visible ambient run should leave a compact handoff. When you open the session later, you should see what triggered the run, what the agent inspected or changed, its current conclusion, and the recommended next action. If the agent drafted a repository change request or needs approval, the session can show that as a card instead of making you search through logs.

​
Typical patterns

PatternRuntimeOutcome
Read-only triageNo retained filesystemSummarize likely cause and evidence.
Operator reviewStarts read-only, may request moreDraft a runbook or repository change request and ask for approval.
Coding changeRetained filesystemClone a repository, edit files, run checks, and create a change request.
Guarded remediationPolicy-controlledApply a low-risk predefined fix with audit trail.

​
Policy first

Each ambient agent should have clear boundaries:
  • Which signals can trigger it.
  • How often it can run.
  • How repeated events are deduplicated.
  • Which workspace, seller, or customer relationship scope it can observe.
  • Which severity levels should wake the agent.
  • Which models it can use and how much budget it can spend.
  • Which resources it can read.
  • Which actions require approval.
  • How long sessions and filesystems are retained.
This keeps proactive automation useful without giving agents blanket access. Ambient sessions do not need to expose every internal step to be useful. Detailed logs and artifacts can stay attached for audit and debugging, while the main session stays readable for review, approval, and handoff.

​
Seller-managed operations

Sellers can use ambient agents to watch customer deployments they manage. A seller support agent can notice a failed customer install, inspect the deployment, compare it to existing change requests, and draft a fix for review. The customer still owns the workspace. The agent’s access follows the workspace grants and policies configured for that relationship.

Configure an agent

Add ambient triggers to a reusable agent identity.

Permissions and security

Keep proactive work constrained and reviewable.