Your default AI team
The defaults are deliberately conservative: they never run on a schedule, they only propose changes (every mutation waits for your approval), and they cost nothing until you talk to them or press Run now. Delete any you don’t want — they stay deleted, and you can re-hire them individually from the agent catalog at any time. When a new role joins the default team, every organisation is offered it once, the next time anyone opens the roster; a default you deleted earlier is never brought back by that.
The DevSecOps agent
The DevSecOps agent turns a cluster’s security report into fixes. Open it from a cluster’s chat (the report is per cluster) and ask it to clear the critical and high findings, or file a board ticket scoped to the cluster and let the dispatcher hand it over. It works in a fixed order:- Reads the security report for the cluster — the same Trivy Operator findings the Security Center shows — filtered to critical and high, and quotes the CVEs, their fixed versions, and the workloads each one runs in.
- Maps each vulnerable image to what deployed it: a connected application deployed to that cluster, matched by namespace and image repository, or the add-on the report attributes the image to.
- Fixes applications at the source. It reads the Dockerfile and dependency manifests in the application’s repository, bumps the base image to a patched tag or the vulnerable package to its fixed version, and opens one pull request per application listing every CVE it clears with the installed and fixed versions and the workloads affected. The pull request is the review gate; it never commits to the default branch.
- Proposes add-on upgrades for images that belong to a Helm add-on — the chart version that ships the fix, with the current version as the rollback — and hands the rollout to the DevOps agent.
- Verifies once the pull request has merged and the image has been rebuilt, by re-reading the report and quoting the before-and-after counts.
Fleet status at a glance
The Agents page is a triage surface: every row shows what its agent’s latest run is doing, and what — if anything — it needs from you.
Picking a run in the Runs rail puts that run in the page address, so the view you are looking at is the view you can share, and a link from a ticket, from the run history, or from a teammate opens the run it names rather than the agent’s most recent one.
Each row also swaps its goal prompt for the latest run’s outcome summary once one exists, so the list reads as “what happened last”, not “what was asked months ago”.
Agents that need a person sort to the top of their section, and a summary strip above the list counts them — need input, blocked, and failed chips filter the list to just those agents. Finished one-off missions fold away under Completed missions, keeping old dispatches out of the way without deleting their history. In the sidebar, the AI Agents item carries a badge with the number of agents currently waiting on your input — the same way the Board badges tickets that need a human.
Chat with an agent
Every agent has a Chat action — on the roster, on the agent list, and on its detail page. It opens the AI chat scoped to that agent: the conversation carries the agent’s persona, so the SRE talks incidents and evidence while the Database Admin double-checks backups before anything else. The persona only ever narrows what an agent may do; the platform’s normal approval rules for mutating actions apply unchanged. The chat URL carries the scope (/organisation/ai/chat?agent=…), so a refresh — or a bookmarked link — keeps you talking to the same teammate.
Create your own with the AI wizard
New agent on the Agents page starts a short interview instead of a form. The wizard asks for a role, drafts a name (shuffle it if you disagree), lets you pick focus areas, a cluster scope, a communication style, and guardrails — then writes the agent’s persona for you. Review and edit the persona before hiring; the result is a real agent that behaves exactly like the preloaded team. Prefer the classic form? The wizard’s footer switches to Manual setup at any point.Creating, deleting, and running agents requires an organisation admin role. Chatting with an agent is open to every member.
Autonomy and budgets
Each agent carries an autonomy level — Observe (read-only), Propose (suggests, you approve), or Autonomous (executes low-risk reversible actions itself) — and hard budgets for tool calls, turns, and runtime. Budgets are the hard stop for autonomous work; the defaults ship with Propose and modest budgets.Model
Each agent can be pinned to a model from your organisation’s catalog: Quick (the fast, low-cost rung), Think, Expert, or any custom catalog entry. Auto leaves the choice to the router on every turn, which is how every agent behaved before the setting existed. The pin applies to the agent’s scheduled and run-now dispatches, its board tickets, its mission continuations, and persona chats with it alike. Edit it from the agent’s Edit dialog. Every agent Ankra ships - the six default roles and the catalog agents - is pinned to Quick: an idle team routed per turn lands on the expensive rungs often enough to cost real money, and most of this work is reading state and editing manifests rather than deep reasoning. Raise one agent to Think or Expert when its work needs it; the choice is per agent and yours to make.Daily token limit
Each agent can carry its own daily token limit: every token the model processes on the agent’s behalf in one UTC calendar day, across runs and persona chats, cached prompt reads included. When an agent reaches its limit:- the scheduler stops dispatching it for the rest of the day — schedules, Run now, board tickets, and mission continuations all wait;
- a turn already in flight finishes with one wrap-up iteration instead of being cut mid-thought;
- a notification goes out once for the day — in the inbox, and through your notification routes to Slack or Teams — naming the agent, the tokens used, and how to raise the limit.