The AI agent dashboard stayed green. The results got worse.

An AI agent dashboard, the console a team uses to oversee its agents, has to answer three questions for every agent: what may it decide, what did it actually do, and how do we know that was acceptable? Runs, errors and cost answer none of them, because an agent chooses its own steps. This piece covers the console that oversees agents over weeks, using a working concept you can try at the end. Designing a single delegated task is a separate question, covered in our agentic UX design principles, and the controls your enterprise customers' IT teams will ask for have their own governance checklist.

Reply Drafter, a fictional agent from a concept we designed, writes first drafts of replies to customer support tickets. It reads the ticket and the order, decides what to search the help centre for and which article to cite, and leaves a note instead of a draft when nothing fits. A support agent then edits the draft if needed and sends it. In one week it handled 5,112 tickets. Almost every run finished without an error, and its dashboard stayed green all week.

Before Thursday, support staff sent 81% of its drafts without rewriting them. In the days after, they sent 64%. Nothing had broken. A new version had gone live on Thursday afternoon with an updated help centre and shorter instructions, and nothing on the dashboard said the agent had become worse at its job.

The concept is an enterprise console that manages AI agents, and you can try the whole of it at the end of this piece. The pattern is real. In 2023, researchers at Stanford and Berkeley tested the same models, under the same names, three months apart and found substantial changes in behaviour, including in how closely GPT-4 followed instructions. In February 2024, a Canadian tribunal held Air Canada responsible for a fare policy its website chatbot had described wrongly, and dismissed the argument that the chatbot was responsible for its own words (Moffatt v. Air Canada, 2024 BCCRT 149).

Software that makes its own choices can get worse without anyone on your team changing it, and the company still answers for what it does. That changes what an operations console has to show.

Conventional software does what it is told. An agent decides.

Anthropic separates workflows, which follow predefined code paths, from agents, which direct their own process and choice of tools. Conventional software is close to its settings: read them and you know what it will do. It drifts too, through dependencies and data, but slowly. A single model call drifts further, and an agent compounds that, because it is given a goal, some authority and a set of tools, and chooses its own steps.

Engineering teams already have good tools for what follows. They version prompts, pin model versions, test changes against saved cases (past examples with an answer a person approved) and roll back when something regresses. Some, Braintrust among them, also serve product teams, with evaluations that score the quality of an agent's output.

The person accountable for an agent needs that, and more. For every agent, the console has to answer three questions:

1. What may it decide?
2. What did it actually do?
3. How do we know that was acceptable?

It is tempting to lead with runs, errors, usage and cost, because that is how conventional software is monitored.

AI agent permissions: what is enforced, and what is only an instruction

An agent's authority comes from two very different places. Some limits are enforced by the platform: a policy that stops any discount above 10% until a person approves it, or the plain absence of a payment tool. Others exist only as instructions, sentences the model is asked to follow. The first kind holds whenever the platform checks it, which is why it belongs in the system the agent acts on rather than in a gateway that a broad token can bypass. The second holds only when the model complies.

Security practice already insists on the difference. OWASP's guidance on excessive agency tells teams to enforce authorisation in downstream systems "rather than relying on an LLM to decide if an action is allowed or not". A settings page can still hide it, by putting enforced limits and instructions in one list, or by leaving the instructions in a text box few people reread.

So each agent in our concept has an operating contract: its goal, what it decides alone, what it must ask about, what it must never do, what it checks first, when it stops, and what success means. Every line says how it is held. It may be a platform rule, an instruction, or something the agent has no tool to do. Rules are read straight from the configuration. Instruction lines are matched against the current instructions, and a line that may no longer appear is flagged for a person to check.

For Reply Drafter, the contract would have flagged four lines missing from version 3.0's instructions, including "use only facts shown in the ticket" and "quote policy wording exactly for refunds, credits and delivery times". It would not have caught the other cause, the new help centre, because that changed what the agent knows. The contract also shows where an instruction ought to be a rule. Renewal Desk is only told to stop when usage data is more than 30 days old. Stale upstream data is one of the commonest causes of drift, so that check belongs with the platform.

What it did, and what it says it did

Some of the best-known advice says to show the agent's planning steps, including Anthropic's guide cited above. Shown on their own, those steps get read as evidence of why the agent acted. Research on how models explain themselves says they should not be: explanations "can systematically misrepresent the true reason for a model's prediction", and Anthropic reports the same of its own reasoning models.

Our concept keeps three things apart for the person who reviews a decision. Raw tool results and policy checks are labelled as observed, each linked to the step that produced it. The agent's interpretation of those results is labelled as its reading. The options it says it weighed and the doubts it records are labelled as its claim. Readings and claims stay that way until a separate check confirms them.

Records like this also show an agent adapting. In the concept, when the fictional Ops Orchestrator could not get payment data because its finance system was rejecting sign-ins, it chose a fallback it is allowed to use, marked the result as partial, and asked its owner to sign off early. A fixed workflow would have failed or carried on regardless. Its record shows the decision, and which parts of it were permitted.

How to tell an agent is getting worse, and roll it back

Because an agent can change without an edit from you, each version has to store everything that shapes it: instructions, the exact model version, a copy of its knowledge, its rules and its tools. Restoring an earlier version then brings back the setup. Whether the behaviour comes back has to be measured, because the data an agent reads keeps moving and its output varies from run to run.

In the concept, the console traces Reply Drafter's drop to version 3.0. It compares 3.0 with 2.4 on the same 40 saved cases, with a grading model scoring each draft against the approved reply using a written rubric, and a person spot-checking its grades. Version 2.4 matches 33; version 3.0 matches 26. Forty cases is a small set, and every approved reply in it was written under 2.4, which favours the older version. A set built only from replies approved unchanged also leans towards easy tickets, so it needs an owner who adds hard cases as they appear, and the grading model is pinned and versioned like any agent. The result is enough to restore and watch, and too thin to settle the question. Restoring copies 2.4's setup into a new version, 3.1, and runs that finished on 3.0 keep 3.0 in their record. A restore is a hypothesis, not a fix. So the watch has an owner, a pass mark set in advance, and a date by which someone decides. Restoring is also not always the best move: it brings back the old help centre, which lacks four new articles on customs rules. The better version may be 3.0 with its four missing lines put back.

The design work is in making this readable to the owner who has to decide, and in an audit trail that explains how 3.0 slipped through. It had been published as a content update, so its saved cases were never run. A change to an agent's knowledge is a change to the agent.

Not every agent has a measure as convenient as an edited draft. Nobody rewrites a refund or an access grant, so the signal has to come from elsewhere: reversals, complaints, a reviewer's weekly sample. Where there is no signal at all, the console says the results are not measured.

Permissions and approvals while an agent is running

Agents run for minutes or hours, and things change while they work. Four rules keep the console honest about that. None is new to security engineers; the design work is in making them visible to the person deciding.

• A run is pinned to its version, but checked against current access. It finishes on the instructions and model it started with. Every new tool call is checked against what the agent is allowed to do now, so switching a tool off stops running work from using it. A call already in flight finishes, and the console shows which runs were interrupted.
• A run that stops halfway leaves a list. What it finished, which of those steps reached outside the platform, what can be undone and what cannot, and who owns the clean-up. The work does not end when the run stops.
• An approval belongs to its run. Stop the run and its pending approvals are withdrawn, so nobody can approve work that no longer exists.
• Restricting is immediate; widening is reviewed. Switching a tool on, granting a new one or loosening a limit widens what the agent may do. Each becomes a draft that a security reviewer must approve, and the person who asked for it cannot approve it themselves.

Asking people has a cost that is easy to underestimate. Research on automation has shown for decades that people stop checking automated systems when other work competes for their attention, and that experts are not immune. A long queue of approvals trains people to click approve. The review step itself is covered in our human-in-the-loop UX patterns; the console's job is to keep the queue honest. So each approval in our concept covers one action, states exactly what it covers and why it was raised, and goes to a role with a named backup rather than one person. It has a due time, passes to the backup if it lapses, and expires to the safe outcome, which is that nothing happens. Each agent also has an approval budget. When one raises more requests than its owner can genuinely review, the rule needs changing, not the reviewers.

What our first versions got wrong

Our first version of this console treated agents like workflows with better charts. A later version looked right until we stress-tested it. A refund still waiting for approval appeared in its run record as paid. Some limits carried a "platform rule" label that no policy backed. Giving an agent a new tool took one click.

That stress test was carried out by AI agents, each briefed for a role and given only the screens or the draft: an architect of agent platforms, a product leader, an engineer who builds evaluation tools. They are not a substitute for people who run agents in production, and we would rather hear from those people next. Each fix removed a place where a screen claimed more than the platform could show.

What a platform has to record

None of these screens can be built on a platform that does not keep the evidence. Most of this list will be familiar to engineers. The screens only work if the record reaches the person deciding. Before designing them, check that your platform records:

• The exact version each run used, including its model version and knowledge
• Every tool call and policy check, linked to its run
• Which limits the platform enforces, kept separate from the agent's instructions
• Saved cases with the outcome a person approved, refreshed as the product changes
• The run each approval belongs to
• Who changed what, and whether the change widened or narrowed the agent's authority
• What each approver was shown at the moment they decided
• The text the agent actually retrieved, not just the name of the source
• How long each record is kept, and proof that it has not been edited since

We designed for a fleet of dozens of agents. A fleet of thousands will need more grouping and summarising than this concept shows, and we have not tested the screens at that scale.

Choosing who designs it

A console like this is needed once agents are in production inside a workflow product. If you bring in outside design help at that point, the useful test is whether a partner can do this work in your product, with your data. A polished portfolio of dashboards tells you little about that.

• They start from what your platform records. Every label on these screens depends on evidence the platform keeps. Begin with the logs, policies and version history, and the screens can only claim what is true.
• They design and build together. States such as "waiting for approval", "interrupted" and "restored, now being watched" are hard to judge as static mockups. They need to be clicked through in code, with realistic data, before engineering time is committed.
• They have shipped approval and permission flows. Underneath, an agent console is roles, approvals, hand-offs and audit, the same ground as any complex B2B product. Ask to see one of those flows they shipped, and who used it.
• They test with the people who will answer for the agents. Your operators and your customers' admins should work through the screens before anything is built.
• They can tell you when not to use an agent. Some tasks are better as fixed workflows, and a good partner says so before designing oversight for them.

This is the work we want more of: B2B software where AI acts for people, designed so that whoever answers for it can see what it may do and what it did. We have shipped AI product work we can walk you through under NDA. If what you need is a monitoring view for engineers alone, the engineering tools for versioning and testing mentioned earlier already cover much of it, and you may not need a design partner at all.

Try the console

The concept runs 32 agents at a fictional freight company, with three roles to switch between and four guided tours. Everything in it is sample data.

Open the console and start with the tour "Catch a behaviour change", about two minutes with Reply Drafter. The other three tours resolve an approval as the agent's owner, trace a failure as a platform admin, and watch agents hand work to each other.

A dashboard for conventional software tells you whether the machine ran. A console for agents has to show the person who answers for it whether the machine behaved.