Autopilot: engineering an agentic quality loop for support automation

Support automation at Coinbase is now a fleet of agentic AI systems: bots that look up account state, take bounded actions, and escalate to a human when higher judgment is needed.

A “procedure” is the versioned playbook an AI agent follows to solve a specific customer problem, for example checking a transfer, explaining a hold, or resolving an account restriction. Each procedure is a decision tree with data lookups, branch conditions, and terminal outcomes.

Keeping that fleet correct is harder than any single prompt, as procedures change, models drift, partner runtimes evolve, and malicious actors probe for seams.

This post is about Autopilot, our approach to closing that loop. Autopilot is a standardized pipeline where agentic systems author, test, red-team, score, and analyze support procedures the way production software is shipped: with contracts, fixtures, CI gates, and humans in the loop on writes.

In this post, "Autopilot" is a system metaphor. It is software that reduces the manual touch required to keep automation healthy. It does not replace judgment, it makes it cheaper and more repeatable.

A procedure change can introduce risk in several ways:

For a long time, validation looked like this: an engineer or conversation designer opened a Help Center chat widget, logged in as a test user, typed through a happy path, maybe tried a couple of adversarial prompts, and called it “done.” That works for a handful of flows. It fails when you have dozens of procedures, support bots (our in-house chatbot and third-party vendor bots), frequent launches, and financially sensitive topics.

Manual UAT was also slow. A single procedure cycle could take days of mock setup, conversation driving, and result collation. We needed something closer to continuous delivery for conversational systems.

Autopilot turns support procedure work into a closed quality loop:

The goal is simple: fix the flows that fail customers most, and prove each fix works before it ships. We pick what to fix from where automation is measurably weakest, not from a gut feeling.

The temptation with LLMs is to route everything through one clever agent. That is usually the wrong architecture for production quality systems. Autopilot uses agents where language and exploration help, and deterministic services where reproducibility matters.

That split is deliberate. An agent can explore the long tail of confused-user and bad-actor behavior better than a static checklist. A deterministic harness is what makes the same procedure comparable across bots and across days.

Agentic automation collapses without shared contracts. Three standards matter most.

A procedure is an internal playbook, not customer-facing copy. What makes it testable is that we author it in a constrained procedure format, a small DSL of steps, branches, data lookups, and terminal outcomes, rather than free-form prose. Autopilot expects procedures and tests to share that same structured contract:

Once that contract exists, one test plan can run across our in-house bot and partner bots. Results become comparable because the input and grading schema are the same.

If every bot invents its own labels for the same customer goal, you cannot prioritize what to automate next, diagnose CSAT drops, or compare runtimes honestly. "No Intent", procedure names, and routing artifacts are not customer goals.

We have a canonical intent taxonomy across Help Center, chat, and voice. Procedure Autopilot uses it directly. Intent is what routes a conversation to the right procedure. It also drives discovery: we rank flows by intent volume against their resolution and CSAT, so the weakest high-traffic intents get automated or fixed first. And because intent describes the customer goal rather than the runtime, we can put two bots on the same intent and compare them fairly. The design choice that made this usable is separation of concerns.

Read together, these route a contact to an owner: the canonical intent says what the customer wanted, the product theme says which product area it belongs to, and that theme maps to the team responsible for reducing that contact volume.

Those answer different questions. Conflate them and you get dashboards that look clean but measure the wrong thing. Preserving raw labels while adding a canonical layer lets us improve reporting without rewriting history or erasing runtime specifics.

The same discipline applies to conversation summarization. Today, handoff and evaluation paths already carry structured fields such as a short summary plus an intent signal. Autopilot needs that to become an explicit contract shared by discovery, judges, and post-contact analysis: customer goal, actions attempted, unresolved issues, escalation reason, and safety flags. Without a shared schema, every stage invents its own narrative of the conversation, and the loop cannot learn.

Canonical intent plus a shared summary contract is what turns transcripts into operable signals for Autopilot. This is a foundation we are hardening, not a finished platform feature.

The first Autopilot pillar is procedure conformance testing.

Instead of driving a browser, a headless runner:

Agents help generate test plans and realistic utterance variants, while the runner provides repeatable execution. Agents can draft the test plan and utterance variants. The runner itself is a service: schedulable, replayable, and usable by engineers and non-engineers alike.

In practice the shift is large. A full UAT pass of roughly 90 cases used to take one to two weeks of manual setup and execution; automated, it finishes in about 30 to 45 minutes. A single procedure that once needed days of mock setup and conversation driving now gets a graded result in tens of minutes. That is the difference between hoping a procedure is fine and having a graded artifact before go-live.

We evaluated several productionization paths (workflow tools, IDE agents, CI-only, hybrid service). We shipped a hybrid:

CI alone is too engineering-centric. Browser agents alone are too brittle. The hybrid keeps one execution path for ad-hoc and scheduled runs so the results stay comparable.

Happy-path conformance is necessary and insufficient. Support bots are socially engineerable systems. Customers (and malicious actors) can:

Autopilot's adversarial suite generates cases across categories such as bad actor, confused user, edge case, prompt injection, data exfiltration, policy bypass, and trust exploitation. Many cases are multi-turn on purpose. Single-turn safety checks miss boiling-frog patterns.

Each conversation is judged twice:

An LLM does the scoring. It is applied the same way on every run, so two passes over the same procedure are comparable. The model can still be wrong, so a score feeds the human reviewer and the release gate. It does not decide on its own. The operational win is coverage and consistency: the same procedure gets the same red-team pressure every time it changes.

An important lesson from early runs: guardrails that only sit at intent detection are not enough. Output-layer controls matter, because social framing can bypass upstream filters. Multi-bot comparison also matters. The same adversarial suite against multiple runtimes surfaces different failure modes and  lets us hold every runtime and bot to the same bar.

We do not publish detailed exploit recipes or internal incident identifiers here. The engineering point is architectural: adversarial simulation belongs in CI for agentic support systems, just as fuzzing and abuse testing belong in other security-sensitive services.

End to end, Autopilot looks like this:

Two properties keep this from becoming an autonomous write-everything agent:

We treat these agents like any other software service: versioned and observable, with a kill switch when we need it.

Contracts over one-off prompts. Shared intent, summary, and test schemas create short-term taxonomy work and long-term leverage.

Hybrid ownership over pure CI or pure UI. Non-engineers need self-service. Release trains need gates. One service should satisfy both.

LLM judges with oversight. Automated scoring scales review. It can also be wrong. Critical and high findings still get human attention.

Canonical intent without erasing raw lineage. Standardization fails if you overwrite what the bot actually emitted. Preserve raw labels, add canonical fields.

Closed loop, not fully closed yet. Discovery, authoring, testing, and analysis exist. Full autonomous orchestration from metric gap to promoted procedure is still being hardened. Naming that gap is part of operating honestly.

If you are building agentic customer support, the portable lessons are:

Autopilot is our framework for treating support automation quality as an engineering systems problem.
Models do the language work. The standards make their output comparable and reviewable, a deterministic harness enforces those standards on every run, and the human gates keep a bad write from reaching a customer.

The future we are building toward is not a chatbot that never needs review. What we are building keeps surfacing the weakest customer flows and running them through rewrite, red-team, and promotion with far less manual glue than before. That is how agentic AI turns into real operational automation.