Agents in the back office: agentic AI use cases that actually run in 2026

What counts as an agent, and what does not

An AI agent is software that gets a goal instead of a script. It plans the steps, calls tools such as an ERP, a mailbox or a document store, checks the result and decides what to do next, within limits someone set in advance. That separates it from three things it is often confused with:

• Workflow automation and RPA follow fixed rules. They are predictable and cheap, and they break when an invoice arrives in a layout nobody planned for.
• Copilots suggest and draft, but a person performs every action.
• Chatbots answer questions. A chatbot that cannot change anything in a system is not an agent, whatever the label on the box says.

Most systems that work in production mix all three: rules for the predictable part, a model for messy inputs such as scanned invoices and free-text emails, and a person at the points where money moves or a signature is needed.

Where adoption actually is

McKinsey’s State of AI survey published on 25 August 2026 covers 1,719 respondents in 97 countries, with fieldwork in May and June 2026. Among organizations above one billion dollars in revenue, 40% report scaling at least one AI agent, up from 27% a year earlier. Among smaller organizations the figure is 22%, unchanged. The share reporting any EBIT impact from AI is 37%, essentially flat, and around 6% qualify as high performers, who are twice as likely to have redesigned workflows around AI and to measure impact with a defined process.

The forecasts around that are less flattering. Gartner predicted in August 2025 that 40% of enterprise applications would ship task-specific agents by the end of 2026, up from under 5%. Two months earlier it had predicted that over 40% of agentic AI projects would be canceled by the end of 2027, citing cost, unclear value and weak risk controls, and warned about agent washing, the relabeling of older chatbots and RPA as agents. It estimated that only about 130 of the thousands of self-described agentic vendors were genuine.

Finance shows the same plateau. In a Gartner survey of 183 CFOs and senior finance leaders, run in May and June 2025, 59% said they used AI in the finance function, against 58% a year earlier. Among those users the most common uses were knowledge management (49%), accounts payable automation (37%) and error and anomaly detection (34%), which is a fair map of where finance agents start.

Agentic AI use cases that run in the back office

These are the processes where agents hold up in production, in our own work and in the case studies vendors keep returning to. What they share is a high volume of similar cases, rules that already exist on paper, and a step where a person already signs off.

• Accounts payable. The agent reads the invoice whatever its layout, matches it against the purchase order and the goods receipt (the classic three-way match), proposes the cost account and routes only the exceptions: a price that does not match, a missing receipt, a new supplier. A person approves the payment run.
• Receivables and collections. Matching incoming payments to open invoices, sending reminders in a tone that fits the customer’s history, and preparing a short list of accounts that need a call. Write-offs and credit holds stay with a person.
• Order intake. Orders that arrive as emails, PDFs or spreadsheets become draft sales orders in the ERP, with mismatched prices, unknown product codes and unusual quantities flagged before anyone confirms them.
• Financial close. Reconciling bank lines and intercompany balances, and drafting the variance commentary for the controller, who still signs off the numbers.
• Offers and contracts. A draft from the approved template, filled in from the CRM, with every clause that departs from the standard marked for review. The signature stays human.
• HR administration. Onboarding documents, leave and policy questions, collecting certificates and keeping personnel records complete. Hiring, promotion and dismissal decisions are a different category: under the EU AI Act, AI used for them is high-risk, with obligations that now apply from 2 December 2027.
• Service desks. Classifying and routing IT and employee tickets, restoring access and collecting diagnostics before a person picks up the case.

Customer service: the best documented case, and its correction

Customer service is where the numbers are public. In February 2024 Klarna said its AI assistant had handled 2.3 million conversations in its first month, two-thirds of its customer service chats and the work of 700 full-time agents, with resolution time down from 11 minutes to under two and 25% fewer repeat inquiries. In May 2025 its chief executive told Bloomberg that Klarna was hiring people for customer service again: the AI-first approach had been cheaper but had produced lower quality, and customers should know there will always be a human if they want one.

Gartner still expects agentic AI to resolve 80% of common customer service issues without a person by 2029, cutting operating costs by 30%. Both can be true. The routine case can be automated, and the company still needs a reachable person for the case that is not routine, which is a design decision, not a failure of the model.

The plumbing became a standard

On 9 December 2025 Anthropic donated the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare and Bloomberg. The foundation’s other starting projects are Block’s goose agent framework and OpenAI’s AGENTS.md convention. At the time of the donation Anthropic reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript.

This matters commercially rather than technically. A protocol owned by a foundation is one a procurement department can accept, and it means the connector you build for one assistant is not wasted when you change vendor.

What the July 2026 spec rewrite changed

The 2026-07-28 revision of MCP is the largest since launch, and it reads like a protocol growing up for production:

• Stateless core. The initialize handshake and session header are gone. Every request carries its own protocol version, client identity and capabilities, so any request can hit any server instance behind a load balancer. An optional discovery call replaces the handshake for clients that want capabilities up front.
• Header-based routing. Streamable HTTP requests must carry the method and tool name in headers, so gateways can route and rate limit without parsing the body.
• Multi Round-Trip Requests. A server can answer with input_required, and the client retries with the answers. This single mechanism replaces server-initiated elicitation and sampling, and it is how a tool asks a human to confirm something mid-call.
• Extensions. Optional capabilities, including long-running tasks, moved out of the core and are versioned separately, so a server can adopt them without waiting for the next spec.
• Authorization hardening. Issuer validation per RFC 9207, client credentials bound to the issuing server, and a formal move from dynamic client registration to client ID metadata documents.
• Deprecation with an offramp. The legacy transport, roots, sampling and logging are deprecated but supported for at least twelve months, with implementations labeled modern, legacy or dual-era.

Human approval is now part of the protocol

The important design change for back-office work is that asking a person is no longer a hack bolted onto a tool call. With Multi Round-Trip Requests, a server can stop halfway through and demand input: confirm the cost of this action, confirm this query deletes data, approve this amount. Supabase’s published example is exactly that.

The pattern we would insist on anyway is now cheap to implement: an agent may read anything, prepare anything and decide nothing that costs money or carries a signature. Our own back office runs this way, and the honest accounting is that the agents save time on preparation, not on judgment. People still approve, in one click, with the reasoning in front of them.

What an agent should never do alone

Three actions come up in every serious finance discussion, and we would keep all three behind a person permanently, not only during a pilot:

• Releasing payments. The agent can assemble the payment run and explain every line. A person sends it.
• Posting material journal entries. Drafting the entry and attaching the evidence is fine. Posting it changes books that someone has to defend in an audit.
• Changing supplier bank details. This is the classic fraud route. The FBI’s Internet Crime Complaint Center recorded $3.05 billion in reported losses from business email compromise in 2025, from 24,768 complaints, a scam built on persuading a business to wire money to an account the fraudster controls. An agent that reads email and can edit supplier records is exactly what that scam is looking for.

The same test works on any vendor demo. Ask what the agent can do without a person, which systems it can write to, and which actions need a sign-off before they take effect. A narrow scope, mandatory gates on anything financial and a complete log of every action is a sound design. Broad write access with gates that can be switched off for the demo is the profile to walk away from.

It is also the honest answer to which finance jobs agents leave alone. The work that moves is preparation, matching and chasing. The work that stays is judgment, approval and accountability: the controller who signs the close and the treasurer who releases the payments.

Where projects die

Across the sources, the failure modes repeat. Cost is becoming a constraint for about one in five organizations in the McKinsey data. Gartner’s cancellation forecast points at projects with no measurable business value attached at the start. And the McKinsey high performers are separated from everyone else mainly by workflow redesign and measurement, not by model choice.

The practical reading: an agent that automates an existing broken process produces a faster broken process. The projects that survive are the ones where someone owns the number that is supposed to move, whether that is days to invoice, cases closed without a person or hours a month handed back to a team.

What this means in practice

If you are starting now, pick one process with a clear owner, a measurable number and an approval gate that already exists in the organization, then build the agent around that gate rather than around the model. Keep the connectors on a standard, because the assistant layer will change again. Instrument everything, because without a baseline you will not be able to tell whether it worked. A good first use case passes all of these checks:

• Hundreds of similar cases a month, not a handful.
• Rules that exist in writing, even if the exceptions are handled from memory.
• An approval step that already exists, so the agent can work in front of it.
• Data the agent can reach through an API or a standard connector, not only through a screen.
• Mistakes that are cheap to catch and reverse before they leave the building.

That is the shape of agentic automation in Firecrux: offers, contracts, invoices, payments and HR records prepared end to end, with people approving the steps that carry money or a signature. If you want to know whether one of your processes fits, the fastest answer is a proof of concept in two weeks on real data.