Skip to main content
The Board under AI → Board is where all AI work lives. Every unit of work is a ticket: agents pick tickets up, investigate, draft a plan, get it peer-reviewed, and wait for a person to approve before executing. You watch, intervene at the gates, and close the loop.

​
The ticket lifecycle

A ticket moves through these statuses, shown as columns in the Kanban view: Cancelled tickets leave the board. Resolutions on close are Fixed, No action needed, Duplicate, Won’t fix, or Escalated.

​
Where tickets come from

  • Proactive insights - findings from continuous cluster analysis are auto-filed at the severities you pick in the ticket desk settings. See AI Insights.
  • Alert remediation - when an alert fires and auto-remediation spawns, an incident ticket tracks it, and it closes itself when the alert clears. See Alerts.
  • Automations - a workflow that reaches an approval gate files a ticket directly into Awaiting approval. See AI Automations.
  • People and agents - the File a ticket button, or the file_ticket tool from a chat or MCP session.
  • Chat fixes - when the AI chat is about to apply a gated write on a cluster (a stack draft, a scale, a restart), an incident ticket labelled chat-fix tracks it: one per conversation and cluster, with every action it runs recorded as a change. See Changes and the bill of materials.
Each ticket carries a kind - Incident, Insight, Gap, Automation, Request, or Chore - and a priority from Urgent to Low.

​
How agents work a ticket

A dispatcher sweeps the board and assigns unowned triage tickets to the best available agent, preferring one scoped to the affected cluster. The agent gets a work brief and starts investigating; everything it does lands on the ticket’s timeline. Commenting on a ticket wakes the assignee, even while the ticket is parked at Awaiting approval - so a reply is how you steer an agent mid-flight. Run budgets come from your autonomy policy: a cap on runs per ticket and a cooldown between them.

​
Watching an agent work

While a run is in flight the ticket shows what the agent is doing right now, at the foot of the timeline just above the comment box: a spinner, the step it is on - the tool it is calling and what it is calling it on - and the last few steps behind it, updating as the run moves. A run that is queued, or parked waiting for a person, says so instead of claiming to be working. Open the agent’s session on that panel goes to the full transcript of the run working your ticket, where you can read every tool call and result, answer a question, decide an approval, or guide the agent. The same session is one click from three other places:
  • the is working chip at the top of the ticket, while a run is live
  • Open the agent’s session under the timeline entries that record a run - the note saying an agent started work, and the entry reporting how the run ended
  • the Agent run entry under Linked in the right rail
Every run has its own address, so a link to one can be pasted into a thread or a ticket and it opens the run it names rather than whatever that agent ran most recently. Runs older than the agent’s loaded history say so rather than quietly showing a different one.

​
Plans, review, and approval

The plan is the contract between the agent and you:
  1. The agent drafts a plan on the ticket.
  2. If a reviewer agent is configured (or peer review is required), it critiques the plan. Badges on the ticket row track the state: plan drafted, changes requested, peer approved.
  3. The ticket parks at Awaiting approval. The decision panel at the top of the ticket offers Approve, which releases it to Executing, and Reject, which asks for a reason and sends the ticket back to Planning - the agent reads your reason and revises the plan.
An agent can also park a ticket at Awaiting approval without a plan, when what it needs is a decision rather than a review - a capacity call, an alert threshold change. The same panel decides those: Approve lets the agent proceed, Reject with a reason sends it back to re-plan. An automation approval gate is decided on the run (Approve / Deny) from the same panel or the Inbox, and an agent parked on a risky action is decided on that action under Needs your approval.
Approving a plan does not widen what the agent may do. Actions beyond its autonomy level still ask for confirmation individually - those requests appear in the Inbox and on the ticket’s Needs your approval panel. Agents cannot approve plans on your behalf, and an assignee can never review its own plan.

​
Changes and the bill of materials

Every write an agent or the chat applies on a ticket’s behalf is a change on the ticket, listed under Changes like a commit log. Each entry names the tool that ran, who approved it (a person, an autonomy policy, an approved plan step), its risk level and reversibility, the cluster and stack it touched with the namespaces involved, when it was proposed and when it settled, and the operation it created on the cluster’s operations ledger with its step outcome - 6/6 steps succeeded, or the failing step and its error. The verdict follows the operation, not the tool’s reply: a change whose apply is still running reads applying, one whose apply failed afterwards reads failed, and one parked for confirmation reads awaiting approval. Expanding an entry shows what changed - the same bill of materials the approver reviewed before the action ran: the addons added, updated or removed with their chart and version, the manifests with their kind and namespace, and the value and content diffs behind them. An action that parked without a preview says so outright rather than listing nothing. The Bill of materials panel in the ticket’s rail folds every change into one view of the ticket’s blast radius: the clusters and stacks (linked to their pages), the namespaces, each addon with its chart version, each manifest with its kind, and the executions on the operations ledger. A rejected or expired change contributes nothing to it. The same ledger is available on the API at /api/v1/org/ai-tickets/{ticket_id}/changes.

​
When a person is needed

A ticket needs a human when it is Awaiting approval, Blocked, or Awaiting review with a peer-approved plan. The Needs a human view collects exactly those, and the AI sidebar badge counts them. If a ticket goes stale - untouched for a day while unfinished - or becomes blocked, Ankra raises an AI ticket needs a human notification and records the escalation on the timeline. A plan arriving at Awaiting approval raises Plan awaits your approval. Both deep-link to the ticket.

​
Answering a choice

When what blocks the ticket is a choice - the agent found more than one way forward and needs you to pick - the ticket page opens on the agent’s question with the options it offered: each with a one-line title and a summary of what it involves, and the one the agent recommends marked. Pick one, add a note for the agent if you want, or choose Something else and say what should happen in your own words. Nothing is pre-selected. Send decision records your answer on the timeline as a comment starting with Decision: and hands the ticket back to the agent, which resumes from your answer without asking again. A ticket that leaves Blocked for any other reason drops the question. The same choice is offered everywhere the ticket reaches you:
  • AI chat and MCP - ticket_get shows the pending question under decision_request, and the ticket_decide tool records your answer (“go with option A on T-8”, or “tell T-8 to publish to both for a week”). The assistant only decides when you have.
  • CLI - ankra tickets get T-8 prints the options with their keys and the recommendation; ankra tickets decide T-8 --option a picks one, --answer "..." answers with something else, and both together record the option with your note. ankra tickets list shows which tickets wait on your decision.
  • Slack and Teams - the thread reply that announces the block carries the options as buttons (the recommended one highlighted), and so does the escalation card while the ticket still waits. Clicking an option records it as your decision. Something else asks you to reply in the thread starting with Decision: - that reply is recorded as the answer rather than as a plain comment.
  • API - POST /api/v1/org/ai-tickets/{ticket_id}/decision with option_key (one of the offered keys) and/or answer (required when no option is chosen). A ticket that is not waiting on a choice answers 409.

​
Slack and Teams threads

Bind a tickets channel in the ticket desk settings and every ticket gets its own thread: timeline events post as replies, and replies in the thread land back on the ticket’s timeline, waking the assignee. An escalation carries Assign to me and, while a plan awaits a verdict, Approve plan / Request changes; a ticket blocked on a choice carries its options as buttons and Something else (see Answering a choice). Plan approval itself otherwise happens in the product. Configuration lives under AI → Settings → Autonomy; see AI Autonomy.

​
Mirroring tickets into your own tracker

A sync connection mirrors board tickets outbound to a Jira project, a Linear team, or your own webhook endpoint: the external issue is created once per ticket, and timeline events follow as comments. Filters decide which kinds and priorities travel. Set them up under AI → Settings → Connections; see Sync board tickets to Jira, Linear, or a webhook.

​
Views and navigation

The left rail has saved views - All open, Needs a human, In flight, Gaps, Shipped, My tickets, plus one per agent with open tickets. Toggle between List and Kanban; a Live pill shows while the board is streaming updates. From the keyboard: j/k to move, enter to open, s for status, a to assign, / to search.

​
Availability

The board is rolling out per organisation as part of the AI section. If you do not see AI in the sidebar, ask your Ankra contact to enable it.