VUX: The Verification User Experience for AI Agent Teams

Managing AI agent teams isn't just about tracking whether work gets done. The harder problem is whether the work that's done is correct. Every era of work management created a new interface shaped by the bottleneck of the time. AI agent orchestration has done the same. The bottleneck has flipped from generation to verification, and the experience of navigating that, the tools, the cognitive load, the approval queues, the judgment calls, needs a name. I'm calling it Verification User Experience.

Every bottleneck gets its own interface

Think about the interfaces that have defined project delivery across software eras. Not the screens themselves, but what they asked the person in charge to worry about.

Era	Bottleneck	Interface	Key question
Waterfall	Change	Gantt charts, milestone docs	Is the plan holding?
Agile	Prioritisation	Sprint boards, standups	Is the focus on the right things?
Kanban	Throughput	WIP boards, pull queues	Is the flow moving?
DevOps / CI	Integration	Pipeline dashboards	Is the system stable?
Agent orchestration	Verification	Approval queues, quality gates	Is the output correct?

Winston Royce's 1970 paper gave us the waterfall model, despite Royce himself arguing against a pure sequential read and proposing five iterative modifications. The sequential reading stuck. Gantt charts followed, and the manager's job became tracking the plan.

The Agile Manifesto shifted the bottleneck from change control to prioritisation. Sprint boards replaced Gantt charts, and the manager stopped tracking a plan and started facilitating a team. Taiichi Ohno's kanban system, developed at Toyota through the 1950s drawing on observations of American supermarket restocking, moved into software through David Anderson's adaptation at Corbis in 2007. Work-in-progress (WIP) columns took over, and throughput became the metric that mattered. Fowler and Foemmel's work on Continuous Integration in 2001 moved the bottleneck again, to integration, and Continuous Integration (CI) dashboards became the new control surface. Patrick Debois coined "DevOps" at DevOpsDays Ghent in October 2009, and the interface shifted from tracking integration to watching the whole delivery pipeline.

Each era, the interface changed because the question changed.

From generation to verification

Addy Osmani, engineering leader at Google, put it plainly in his O'Reilly AI CodeCon piece on the code agent orchestra: "The bottleneck is no longer generation. It's verification." In an earlier post, "The 70% Problem: Hard Truths About AI-Assisted Coding", he laid out the pattern that gives the problem its name: AI agents get you most of the way there, and the remaining slice still requires human expertise. That slice used to be the production problem. Now it's the judgement problem.

Lusser's Law, from post-war rocketry, tells us that system reliability is the product of its component reliabilities. Applied to agent chains: near-reliable steps stop being near-reliable by the end. Each agent's output is the next agent's input, and small errors stack. Zartis documented this compounding errors problem as the structural failure mode in multi-agent systems, and Gartner's projection that over 40% of agentic projects get cancelled by 2027 cites inadequate risk controls as a key cause.

Every workflow tool built for previous eras, Jira, Monday, Linear, kanban boards, was designed to answer one question: is it done? VUX requires tools that answer a fundamentally different question: is it right? Different question, different interface.

VUX is the experience of the person whose primary role has shifted from coordinating production to verifying output. The tools, interfaces, cognitive load, and decision patterns involved in determining whether AI-generated work is correct, complete, and safe to ship.

Managing agent teams UX

I didn't jump straight to multi-agent orchestration. Each stage brought challenges and taught me something different about designing and building Human-centred AI systems.

Stage one: single agent, single terminal. One conversation, one task, full context. Verification is easy because you're already in the loop by default. What it doesn't do is scale. Every agent waits on you to move to the next prompt.

Stage two: tmux and the multi-terminal experiment. When one terminal isn't enough, simply add more! Tile Claude Code sessions using tmux or cmux, run parallel agents, alt-tab between them routing instructions. Output goes up, but so does the cognitive load. There's no routing logic, and no priority queue, you become a manual orchestrator.

Stages three and four: kanban, then filtered list. The natural next step was to impose some visual structure. I've always loved kanbans, so naturally, kanban boards for agents. In my case it collapsed almost immediately, evident in all that wasted screen real estate in the User Interface (screenshot below). Work completes faster than you can move cards. By the time you've marked something "Ready", unless it's a significant sized task it quickly gets completed and moved to "Review". The board becomes a lagging indicator of a reality that's already moved on.

Stripping the kanban back to a flat filtered list helped better utilise screen real estate. But when lists reach hundreds of items (or more), filters become the interface, and you spend your time tuning queries instead of reading output. Both the kanban and the list however were asking the wrong question, "what's in the queue?", yes the kanban has a review column and filtered lists priority tags, but the main focus and question that actually mattered was "what needs my judgement next?", what's a better way to do this?

Stage five: orchestration and VUX. You stop asking "where is this task?" and start asking "what needs my judgement right now?" The screen changes from a progress board to a verification queue. An orchestrator prioritises and assigns verification tasks, provides the User with overall context and visibility of the process, and then the required verification action to complete. Quality gates create natural approval points, whether that be humans or other agents. The question isn't whether work is moving, it's whether it's correct.

This is VUX in practice. The job of the person in charge becomes, genuinely, a verification role. The tools that serve it look nothing like what came before.

Orchestration patterns and the verification load

The Anthropic documentation on building effective agents describes a spectrum of orchestration patterns. The right choice depends on how much verification load you're prepared to carry. I still primarily work out of cmux with multiple concurrent projects.

Skills (single agent, scoped task). One agent, one task, pass or fail. Verification load is as low as it gets. The challenge I've experienced is moving into multi-agent patterns before a single scoped agent is fully reliable. It can be beneficial to quickly test how it 'works with others', but then inevitably requires a lot of re-work, e.g., standardising usage tracking across all agents. Build the individual agent as best you can first.

Hub-spoke (coordinator plus specialists). A coordinator takes the brief, routes work to specialists, and pulls the results together. Your focus shifts to reading the aggregation and asking whether it actually answers what you asked, or just technically responds to it. Holding the original intent while evaluating a synthesised result that may have drifted is harder than binary pass/fail. LangGraph was built for this kind of stateful coordination, with checkpointing and time-travel debugging so you can trace what happened at any handoff.

Agent teams (peer-to-peer, shared task list). Multiple agents, direct messaging between them, an orchestrator overseeing everything. Output volume increases, but so too the mess when something goes wrong. Agents can review each other's work, which cuts queue volume, but if one agent has a systematic misread of the brief, that bias travels through the team before any human sees it. Several agents can build on a flawed foundation before it surfaces. The Google Agent Development Kit, released April 2025, ships with native Agent-to-Agent (A2A) protocol support and hierarchical agent trees partly for this reason: peer-to-peer teams are hard to audit after the fact without structural oversight baked in from the start.

The screenshot below shows where my VUX thinking is at: a human-friendly view of the workflow, dynamically generated by my Chief of Staff (CoS) orchestration agent, with verification steps introduced at handoff points.

Start with skills. Move to hub-spoke when you genuinely need an orchestrator routing work between specialists. Step up to agent teams when the governance is in place to verify phase-gate outputs properly. Skipping stages can result in compounding issues and wasted tokens.

How to design a VUX that builds human confidence

Spec quality is VUX design. Osmani's observation that "vague thinking multiplies" through agent chains is the right frame. When I review output from an agent run, the first question is whether it actually answers the brief or just responds to it. That distinction is largely determined by how well the spec was written. The brief is the highest-leverage artefact in the system.

Approval queues over status boards. My kanban experiment confirmed this. Status boards answer the wrong question. what's needed is a prioritised queue of outputs requiring human judgement: what passed automated checks, what needs human review and feedback, and in what order. Not "where is the work?" but "what needs me right now?"

Human-centred AI framework. An AI orchestrator priorities and assigns verification work to a person. That person may be jumping across multiple projects and tasks so providing an overall view of the process and their role is important to provide context before the double-click on the outputs to review and approve, or return with feedback.

The human bottleneck is a feature, not a bug. Removing human friction to increase throughput is how you end up shipping unverified output at scale. McKinsey's 2025 State of AI found 88% of organisations use AI in at least one business function, with "inaccuracy [being] the AI-related risk that respondents most often say their organizations have experienced". That gap isn't a technology problem. It's a verification problem.

Agent-to-agent verification cuts VUX load without removing oversight. One agent checks another's output against the original spec before anything reaches the human queue. AG2, a community-maintained fork of Microsoft's AutoGen created in November 2024 by AutoGen's founding team, is built around conversation-driven coordination that includes this kind of structured peer review. The constraint: the verifying agent needs to be genuinely independent. A shared prompt template between both agents won't catch the errors that template produces.

What does VUX mean for practitioners managing AI agent teams?

MarketsandMarkets puts the AI agent market at $47.1 billion by 2030, up from $5.1 billion in 2024. Forrester's 2026 Predictions have half of enterprise ERP vendors launching autonomous governance modules, explainable AI, and real-time compliance monitoring this year. Verification infrastructure, and designing for verification, is critical.

The Gartner failure projection isn't inevitable. It's a forecast for teams that conflated "agents producing output" with "agents producing correct output." Teams that design for VUX now won't be in that group.

Review your current agent workflows and ask: what is this interface asking me to worry about? If the answer is still "is it done?", you're using the wrong tool. The job is verification. The Human-centred AI experience needs to be designed around that.

Frequently Asked Questions

What is VUX (Verification User Experience)?

VUX are the design activities for interfacing with and managing AI agent teams, where the human role has shifted from tracking whether work is in progress to verifying whether completed output is actually correct. It covers the interfaces, approval queues, cognitive load, and judgment calls involved in checking high-volume agent output before anything ships.

What's the difference between hub-spoke and agent team orchestration?

In hub-spoke, an orchestrator routes tasks to one specialist at a time and you verify what comes back at the end. It's linear, contained, easier to reason about when something drifts. Agent teams are multiple specialists running in parallel across phases, with agents checking each other's outputs before those outputs reach you.

Why do kanban boards fail when applied to AI agent workflows?

Kanban boards are built around one question: is it done? That's the wrong question for agents. Work completes faster than you can move cards, so the status columns become fiction within hours. My board hit 390 backlog cards before I gave up on it. What you actually need to track is whether the output is correct. That's a different interface entirely.

How do I reduce verification load without losing oversight?

Input quality is the lever most people ignore. A vague brief compounds with every step, so by step four you're reviewing an agent's interpretation of your intention, not your intention. Tightening the brief reduces unnecessary review cycles. The other lever is agent-to-agent peer review: one agent checks another's output before it surfaces to you.

Which orchestration pattern should I start with?

Start with a single scoped skill: one agent doing one clear task, with a pass/fail condition you can evaluate in seconds. Verification stays cheap and failure modes don't compound. I still run most of my work out of cmux with individual agents for that reason. Move to hub-spoke or agent teams when multiple agents are needed, multi-step processes are required, or the throughput needs to be scaled.