AI Board

The shared board where every unit of AI work is a ticket - statuses, plans, peer review, human approval, escalations, and Slack or Teams threads.

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:

Status	What it means	Who acts
Triage	Filed, not yet assigned	The dispatcher, or you
Investigating	An agent is gathering context	Agent
Planning	The agent is drafting a plan	Agent
Awaiting review	A plan is drafted and waiting for critique	Reviewer agent
Awaiting approval	A plan waits for a person to sign off	You
Executing	The approved plan is being carried out	Agent
Verifying	The agent is checking the fix took	Agent
Blocked	The assignee needs a human to unblock it	You
Done	Resolved, with a resolution recorded	-

Cancelled tickets leave the board. A ticket closes with one of these resolutions:

Resolution	Meaning
Fixed	The problem was corrected, with evidence recorded on the close - a probe that passed, a run’s verification steps, an observation of live state, a link, or a person’s word
No action needed	Nothing had to change
Duplicate	Folded into another ticket
Won’t fix	Declined
Escalated	Handed to a person outside the board
Unverifiable	Fixes were applied and reported success, but nothing confirmed them against live state
Cleared	The alert stopped firing after a remediation, without anything confirming the resource is healthy
Expired	The ticket waited at a human gate until it timed out. Nothing was executed

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.
• Known Ankra issues - when an alert comes from a problem in Ankra itself rather than your cluster (an Ankra service failing, Ankra’s registry erroring, the cluster agent’s credential refused by Ankra), Ankra engineering gets the problem and your board gets a ticket titled Known Ankra issue: ..., labelled known-issue and platform-owned. It is parked at Blocked, no agent works it, nothing on the cluster is changed and no question is asked of you. It closes itself as No action needed when the alert clears, and reopens if the problem returns.
• 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, including your own agent.
• Chat fixes - when a person applies a gated write on a cluster through the AI chat or an MCP client (a stack draft, a scale, a restart), Ankra records it on a receipt ticket labelled chat-fix, one per conversation, with every action recorded as a change. See Changes and the bill of materials. Receipts are an audit trail of your own actions, so they stay off the board: its views, its counts and ticket_list leave them out. A receipt keeps its number and timeline and opens from a link, and the ticket list API returns receipts when asked with include_receipts=true.

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 an agent designated as a board worker, preferring one scoped to the affected cluster. Only designated agents are staffed: designate them under AI → Settings → Autonomy → Board staffing. With no eligible board worker, a ticket is escalated to a person instead of waiting silently. 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. Only a person’s comment does this: a comment a model writes - from the AI chat or an MCP client - is recorded on the timeline but does not wake the agent. 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 in the ticket desk settings, it critiques the plan. Requiring peer review has an effect only while a reviewer is configured. 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”). Ankra records the answer as relayed by you and does not check that a person chose it, so ask the assistant to relay your decision rather than to pick one.
• 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. Sync is one-way - status changes arrive as comments, and nothing done in the tracker comes back to the board. Set them up under AI → Settings → Connections; see Sync board tickets to Jira, Linear, or a webhook.

Working the board from your own tools

The board is not tied to the portal. Every surface works the same tickets with the same gates:

• CLI - ankra tickets lists, reads, comments on, moves and decides tickets from a terminal.
• Your own agent - Claude Code, Cursor, Codex or an agent you wrote can pick up tickets over MCP, investigate, draft a plan and carry it out once you approve it. See Work the AI board with your own agent.
• Slack and Teams - the ticket’s thread, described above.

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.