After 120,000 Emails, Which Step Should Enterprise AI Take First?

When an inbound customer email arrives, the job is rarely as simple as "write a reply."

First, someone has to identify what type of request it is. Next, they verify whether all necessary information is present. Then, they decide which system or team should receive it, and whether it requires human escalation. This unglamorous triage step determines whether downstream automation functions or breaks down entirely.

On October 1, Barclays disclosed that its Global Markets business is using Claude to classify client emails, extract missing fields, and determine routing paths across roughly 120,000 emails per day. Barclays did not market this initiative as an "AI replacement for operations teams." Instead, they placed the model on a tightly defined task: helping operational staff see what needs attention, what data is missing, and who needs to step in next.

For any company planning to deploy AI agents, this entry point provides a practical blueprint.

Start With Finite Choices for the Next Step

Many teams begin their AI initiatives by asking: "Can an agent handle our customer support, sales, or operations workflows end-to-end?" That question immediately pushes the project toward its most complex failure modes.

A far more actionable question is: Which decision in this workflow can be reduced to a finite set of options?

For example: - Request missing documentation - Route to a product specialist - Flag for manual compliance review - Close as a duplicate request

Each outcome has a known destination, an assigned owner, and an SLA.

OpenAI's Decisions API, released on September 29, formalizes this exact boundary: developers define the question and candidate answers, and the model classifies, routes, or selects an agent's next action based on text or image context. The lesson here is not that frontier models can only handle basic work. It is about implementation order: stabilize verifiable choices first, then systematically widen the scope of autonomous execution.

The first metric to scale in enterprise AI is not "how many answers the model generated," but whether each triage step accurately connects the right person, the right data, and the next action.

Triage Is an Operational Contract, Not a Model Feature

To make automated routing dependable, organizations need three operational artifacts in place:

1. The Option Sheet: Clearly define permitted routing destinations and explicit human takeover triggers. "Unassigned" or "Other" should never become an unmonitored queue.
2. The Evidence Sheet: Capture why the model reached its conclusion, which email passages it cited, and which required fields remain empty.
3. The Feedback Loop: Ensure cases rerouted by humans, rejected by downstream teams, or delayed by timeouts flow back into your central rules and knowledge bases, rather than disappearing into individual inboxes.

Connecting an API takes hours; operating it sustainably takes discipline. In an analysis on scaling agentic AI, AWS noted that large enterprises inevitably end up managing multiple models, frameworks, and service providers. Under those conditions, the rarest asset is rarely tool unification. It is cross-functional alignment around task classification, handoff policies, and governance rules. Without shared contracts, independent agents simply create decentralized bottlenecks.

Start With a Routing Card, Not a Systems Overhaul

Pick a high-volume request type with a limited set of outcomes and an existing paper trail of human handoffs. Document it with a single routing card: - What is the raw input? - What are the approved destinations (keep them under five)? - What is the minimum required information for each path? - Who signs off on the receiving end, and within what SLA? - How does the system escalate when model confidence is low? - How are human rerouting decisions logged?

Once deployed, move beyond vanity metrics like "clicks saved." Track misroute rates, missing-data rates, human intervention frequencies, and end-to-end turnaround times.

The Barclays rollout highlights another reality: an enterprise can simultaneously deploy AI for internal knowledge search, legacy code transformation, and operational email triage, but these workloads should not operate with the same autonomy levels. A pattern that works for internal Q&A will fail at automated routing, and an automated routing agent should not make external contractual commitments. Define the next step clearly before expanding the scope of automation.

The Starbox View: Turn Every Routing Decision Into Reusable Knowledge

In the Starbox three-tier structure—Organization, BOX, and Agent—triage logic does not belong in an isolated prompt string:

• The Organization Tier: Sets customer commitments, allowed escalation pathways, and operational sign-off rules.
• The BOX Tier: Stores classification standards, historical edge cases, field definitions, and verified rerouting logs.
• The Agent Tier: Extracts required data, recommends the next step, or executes authorized handoffs strictly within the routing card's boundaries.

Connecting this setup to the DDABC loop ensures continuous refinement: - Deploy: Put routing cards into live business workflows. - Analyze: Monitor manual overrides, dropped context, and resolution timeouts. - Benchmark: Compare different routing rules and prompt versions against ground-truth handoffs. - Calibrate: Turn high-frequency operational exceptions into updated standards for the next deployment.

Managed this way, 120,000 emails per day stop being an overwhelming volume metric. They become a live training dataset that continuously sharpens your organization's operational judgment.

When deploying enterprise AI, stop asking, "How much of our headcount can this replace?" Ask instead: "Where should this specific request go next, and who owns the outcome?" When that decision is explainable, verifiable, and tied to a feedback loop, AI agents become a dependable part of your workflow.