All briefings and guides

AI news · ShepBuild · Published

Barclays is expanding Claude across operations. The useful lesson is in the workflows.

Briefing for

Anthropic’s Barclays announcement describes knowledge assistance, email routing, and a developer adoption target. Here is how to learn from those patterns without treating reported outcomes as a promise.

Claude laptop with two separate workflows: approved-document knowledge search with sources, and incoming email classification into team and review queues.

What Anthropic says Barclays is doing

Anthropic’s October 1, 2026 announcement says Barclays is expanding Claude use across its operations. It describes a knowledge assistant that has been live since 2025 to help UK colleagues find information for customer service. Anthropic reports more than 16,000 colleagues have adopted it and that it has handled over one million searches. These are company-reported activity figures, not an independent assessment of service quality.

The announcement also describes a Global Markets workflow that uses Claude to classify and route incoming client emails, reporting a volume of approximately 120,000 emails a day. Barclays separately expects Claude Code to reach 50% of its developer population by the end of 2026 and a majority in 2027. Those are stated plans, not achieved outcomes or a forecast for a smaller organization.

Notice the shape of the work before the scale

The knowledge assistant addresses a common operational friction: staff need to find the right information while serving someone. A useful implementation depends on the quality and permissions of the source material, how current it is, and whether a staff member can see why an answer was returned. The important design question is not whether a business needs an assistant. It is whether employees repeatedly search a defined body of approved information and can verify the answer before relying on it.

The email example is a different workflow. The model helps classify, add context, and route incoming messages so operations staff can act. That is an intake and prioritization problem, not simply a chatbot problem. A safe design keeps a person responsible for the actual decision, especially when a message is incomplete, ambiguous, urgent, or outside the normal categories. Routing should make work easier to find without silently turning a suggested category into a final business outcome.

Build around the work your team can actually support

A large bank can invest in governance, specialized teams, and organization-wide rollout. A smaller company should borrow the workflow discipline, not copy the scale. Choose one recurring task where inputs are reasonably consistent and where a person can check the result. Write down the sources the system may use, the teams allowed to see the output, and what happens when the model is uncertain or cannot find enough evidence.

For knowledge lookup, test whether the answer points to an approved source and whether the source supports the response. Include out-of-date, conflicting, and missing information in the test set. For email triage, test unusual messages, multiple requests in one message, sensitive data, and cases that need immediate human attention. Make the system’s suggestion visible as a suggestion, and preserve an easy way for staff to correct the category or route.

Measure service quality without borrowing another company’s numbers

The Barclays announcement offers measures of adoption and volume, but those figures do not establish how much time your team would save or whether your own customers would receive better service. Define local measures before a pilot: for example, how often a message reaches the right person on the first attempt, how long staff spend searching for a policy, and how often they must correct an AI-generated summary. Collect a baseline from the current process before comparing it with a new one.

Pair speed measures with quality checks. Faster routing is not useful if important messages are missed. More searches handled is not proof that staff found correct information. Have a reviewer sample outputs, record errors, and check whether the system changes who sees or acts on a request. Decide in advance what level of error requires a pause and who has authority to switch back to the previous process.

Choose a bounded pilot and assign the handoff

A practical pilot could focus on one mailbox, one team, or one approved knowledge collection. Keep the first version read-only or advisory when possible. Name the person who owns the process, the person who maintains the integration, and the person who handles exceptions. Document how staff can report a wrong answer, correct a route, and continue work if the AI service is unavailable.

Write down the conditions that would cause the pilot to pause, such as repeated misrouting, an untraceable answer, or a failure that leaves work unattended. Review a sample of outputs with the people who do the job. Expand only after the team can explain what improved, what still needs human judgment, and who will maintain the workflow. A large organization’s deployment scale does not remove these local decisions.

Build on the foundations

References

Related guides