What an agent operation center actually contains: an engineering tour

Last updated: July 2026

McKinsey named the surface in its late-2025 tech services paper. Most vendor demos have not shown one. An agent operation center is where an enterprise's human and agentic workforces are managed on the same screen — where the SVP sees the joint output of both, where the on-call engineer replays a failed agent decision, where the compliance officer answers a regulator's question about what happened last Tuesday. This post is the engineering tour: five sections that go inside the surface, the data models behind each, and the case study patterns we build them from. It's a cluster child of our pillar on agentic AI workflow services and it operationalises the five engineering surfaces from our governance reference.

Key takeaways

• The agent operation center is one screen with five sections. Live agent activity, human review queue, approval chains, agent registry, and governance dashboard. Every enterprise agent deployment eventually converges on this shape.
• 65% of high-performing AI adopters have defined human-in-the-loop validation, versus 23% of others (McKinsey State of AI 2025). The operation center is where that validation actually happens — a queue, not a policy document.
• The joint dashboard is the point. Human and agentic workforce results appear together. The business manager, VP, and SVP evaluate the combined performance of both. Splitting them into two screens loses the value.
• Low-risk autonomous, high-impact approved. The approval-chain configuration is the operating model, not the ML model. It is where the enterprise's risk tolerance is encoded.
• The center is not an off-the-shelf product. It is a set of surfaces built on top of your agent stack's telemetry, wired into your existing identity, ticketing, and BI systems. Shipping it is a Product Engineering deliverable, not a vendor licence.

What an agent operation center is (and isn't)

The agent operation center is the enterprise operating surface for a fleet of AI agents. It shows what agents are doing, what they need from humans, how they are performing, and what the compliance and cost picture looks like — all on the same screen and all queryable across the same identity model as the rest of the enterprise's operational tooling.

It is not an observability platform. Observability platforms like Langfuse or Arize show engineers the traces behind agent decisions. The operation center consumes those traces but presents them to the operator — the business manager, the compliance officer, the on-call reviewer — in a shape that fits their workflow. Observability is engineering-facing. The operation center is enterprise-facing.

It is not an AI chat sidebar. The operation center is where the humans running the workflow are, not where the humans consuming the agent's output are. A customer-service agent's supervisor sits in the operation center; the customer sits in the chat.

Section 1: Live agent activity

The top of the operation center is a real-time view of what the agent fleet is doing. Each agent, each in-flight task, each recent completion, each failure. Filterable by owner team, by agent type, by user (or upstream agent) on behalf of whom the action ran, by cost, by latency.

Under the hood, this section reads from the observability trace store. Each trace event carries the agent identity that names which agent produced it and which team owns it. Aggregations happen on the read side — one query gives you "everything the invoice automation agents did in the last hour, grouped by outcome." Drilling into a specific event opens the full trace: planning steps, tool calls, retrievals, outputs, cost in tokens and dollars.

This section becomes load-bearing the moment the fleet includes more than one agent. Multi-agent handoffs are opaque without a joint activity view — an operator watching agent A cannot tell whether agent B is upstream, downstream, or blocked. Making the joint pipeline legible is the section's real job.

Section 2: Human review queue

The queue is where agent outputs that fail confidence thresholds land for human decision. Each item in the queue carries the agent's proposed action, the confidence signal that triggered the review, the input that produced it, the model version and prompt that ran, and the reviewer's action buttons: approve, reject, edit-and-approve, escalate.

The threshold is configurable per agent and per output type. A tool call that would refund a customer gets a lower autonomy threshold than one that formats a response. A well-tuned queue typically sees single-digit percentages of agent outputs — the long tail of low-confidence cases, cases where output schema validation failed, or cases where an extracted entity did not match a known value. The reviewing team clears the queue as part of their daily workflow, and the reviewed cases feed back into the golden dataset that trains the next iteration of the eval pipeline.

Two design notes matter. First, the queue is time-bounded. Items expire if not reviewed within a configured window — the agent then either falls back to a default action or blocks the workflow, depending on the policy. Second, the queue emits the same trace events as any other agent decision, so the audit surface captures the human review as a first-class event, not as a Slack-thread annotation.

Section 3: Approval chains and escalations

Some agent actions never run autonomously, regardless of confidence. Outbound customer communications above a size threshold, database writes to systems flagged as regulated, spend decisions above a dollar amount — these require a named human to approve before the agent proceeds. The approval-chain section is where those requests queue.

The design pattern is a rules engine attached to the tool allowlist. Each tool declaration includes an autonomy scope: "auto" for actions the agent can take without approval, "approve" for actions that need a named reviewer, "escalate" for actions that need an out-of-band decision. When the agent proposes an "approve" action, the request appears in the section with the reviewer(s) named. When the request is approved, the agent proceeds; when denied, the agent takes the fallback action defined in the tool declaration.

This is where the enterprise's risk tolerance actually lives. Not in a policy PDF — in the autonomy-scope configuration on the tools the agent can call. Changing "auto" to "approve" on a tool is the enterprise deciding it needs more oversight on that action. Making the change in the operation center means the change is auditable, versioned, and rollback-safe.

Section 4: Agent registry

The registry is a queryable inventory of every agent running in the environment. For each agent: a unique ID, the team that owns it, the tools it is allowed to call, the data sources it can read, the model versions it has run on, the prompt versions it has used, the current status.

The registry is where the compliance officer answers questions. "Which agents are touching customer PII?" is a filter. "Which agents were running on model version X when incident Y happened?" is a filter and a time range. "Which agents does team Z own, and who is on call for them?" is two filters and a link to the on-call rotation.

Every entry in the registry is a resource in the same identity model as the rest of the enterprise's infrastructure. Agents inherit access grants from their owning team, and the audit surface attributes every action to the specific agent and to the identity on behalf of whom it ran. The registry is the connective tissue between the agent fleet and the enterprise's existing governance tooling.

Section 5: Governance dashboard

The last section is where the enterprise sees whether the agent fleet is meeting its quality, cost, and compliance targets. Quality: golden-dataset pass rate, online LLM-as-a-judge score trend, human-review override rate. Cost: token spend per agent, per team, per task; trend against budget. Compliance: EU AI Act obligation coverage, SOC 2 control status, incidents open and closed.

The governance dashboard is not built for the engineering team. It is built for the SVP asking "are we on track?" and the compliance officer preparing for a review. Numbers matter more than traces. Trends matter more than snapshots. A quality regression that lasted an hour and self-corrected is a trace event; a persistent trend down over three days is a dashboard event, and this is where it shows up first.

This section is also where the joint view — human and agentic workforce performance on the same screen — matters most. The dashboard rolls up the outputs of both. The invoice team's throughput includes the human-reviewed invoices and the auto-approved ones. The customer-support team's SLA includes the tickets the agent closed and the ones the humans handled. Splitting the view into "human team" and "agent team" hides the interaction. Combining it makes the interaction visible.

What the operation center is not: an observability tool

Observability platforms — Langfuse, Arize, AWS Bedrock AgentCore, Datadog LLM observability — are the layer under the operation center. They store the traces, run the eval pipelines, and provide the raw query surface engineers use to debug. The operation center consumes those traces and presents them to non-engineering users in a shape their workflow fits.

The distinction matters at build time because it changes what the buyer is asking for. "We want to see what our agents are doing" is a request for the operation center. "We want to debug why our agent is failing" is a request for observability. Most enterprise engagements need both, and the operation center's job is to sit above the observability tool as the presentation layer for the business and compliance stakeholders.

Three shapes we build the operation center in

The operation center is not one architecture. It is a set of five sections that can be assembled in three deployment shapes depending on what the enterprise already runs.

Isolated. A standalone operation center built as its own application, with its own data model, identity, and UI. The five sections are first-class pages. This shape fits enterprises that do not yet have an observability platform in place and want the operation center to be the trace store as well as the presentation layer. It is the heaviest lift, and the shape with the most flexibility over what data the operation center sees.

On the side, alongside existing telemetry. The operation center runs as its own application but reads from an existing observability platform — Langfuse, Arize, AWS Bedrock AgentCore, Datadog LLM observability — as the trace source. Engineering keeps its debugging tool. Business, compliance, and operations get their own surface. The two applications share identity and a data pipeline, and the operation center's job is to translate engineering-facing traces into operator-facing sections.

On top of Langfuse (or another telemetry tool). The operation center runs inside the observability platform's extension surface, as custom dashboards, custom pages, and custom review queues built on the platform's own primitives. This is the lightest shape when the enterprise has already standardised on a specific observability tool and wants the operation center to be part of the same product experience. Langfuse's dashboarding and evaluation surfaces are flexible enough to host the five sections directly.

Which shape fits is a Phase 1 conversation, not a launch decision. The isolated shape suits enterprises whose observability tooling is not yet mature. The on-the-side shape suits enterprises with an established platform that engineers want to keep as-is. The on-top shape suits enterprises that have already invested in the observability platform and want a single pane of glass. All three ship the same five sections; the difference is where the sections live.

The operation center is where trust becomes measurable

Every enterprise agent deployment eventually needs its operation center. Teams that plan for it in Phase 1 ship it as part of the MVP, and their operating teams get to see the agent working from day one. Teams that plan for it later ship it as an ops emergency six months in, when the compliance officer or the SVP asks a question the engineering team cannot answer from a Slack thread.

McKinsey's naming of the surface has helped enterprises put a word on the thing they were already trying to build. What the word points at is a set of five sections that live above the agent stack's telemetry and connect to the enterprise's identity and BI systems. Building it takes the same Product Engineering craft that builds any operational tool. It is not exotic. It is not an off-the-shelf licence. It is the operating surface that makes the agent fleet legible to the humans responsible for it — and that legibility is where trust becomes measurable.