Automating the back office with AI agents: a practical guide

Back-office automation pays off when you split the work in two: the parts that need reading and judgement, which suit an AI agent with a human approval step, and the parts that follow stable rules, which suit plain deterministic automation. Invoice handling, enquiry intake, first-draft reporting and CRM hygiene each contain both. The engineering job is drawing that line honestly, then building the approval design, audit trail and permission model that let the automated half run without a supervisor.

Start with the queue, not the model

Plenty of disappointing automation projects start with a tool and go looking for work. The better order is to pick a queue that already has a name inside your organisation: the accounts payable inbox, the contact form, the Monday morning report, the duplicate records nobody has time to merge. Write down what actually happens to an item in that queue today, step by step, including the steps people perform badly or skip.

Then mark each step with what it needs. Reading an unstructured document, deciding which of several categories an ambiguous enquiry belongs to, summarising a week of tickets in prose: those need language understanding. Looking up a supplier record, checking a purchase order number against a total, moving a record between stages, sending a templated acknowledgement: those need an integration and a rule. The steps in the first group are where an agent earns its keep. The steps in the second group are where an agent adds latency, cost and a new failure mode for no gain.

Four back-office jobs that suit this split

Invoice handling

Extraction is the agent's part: pulling supplier, dates, line items, tax and totals out of a PDF, a scan or an email body that no two suppliers format the same way. Matching, arithmetic and approval routing are not. Once the fields are extracted with a confidence signal attached, a deterministic pipeline should do the three-way match against the purchase order and receipt, apply the approval thresholds finance already set, and push clean records to the ledger. Anything below the confidence threshold or outside tolerance goes to a person with the document and the extracted fields side by side.

Enquiry intake and triage

Enquiries arrive as free text and rarely announce themselves cleanly. An agent can read the message, classify it, detect language, pull the sender's history and draft a first reply. What it should not do unsupervised is commit your business to anything: quoting, promising a timeline, or answering a question it half understands. The practical pattern is agent drafts, rules route, human sends. That still removes the slowest part of the job, which is a person reading every message in the inbox to find the few that matter.

Report drafting

Recurring reports are two tasks wearing one hat. Gathering the numbers is a query, and it should stay a query: same source, same joins, same definitions every month, checked into version control like any other code. Writing the narrative around those numbers is a language task, and an agent given the query output plus last month's report can produce a competent first draft. Never let the agent produce the figures themselves. If it can invent a number, sooner or later it will, and one wrong figure in a board pack undoes whatever the drafting saved.

CRM hygiene

Duplicate contacts, stale stages, missing industries and free-text company names that should be entity references are the classic backlog. Exact and near-exact duplicate detection is deterministic work that belongs in your data layer. Deciding whether two similar-but-not-identical records are the same organisation, or normalising a job title into your taxonomy, is judgement. Have the agent propose merges and enrichments as a reviewable batch, not as live writes, and keep a reversal path for every change it makes.

When plain automation beats an agent

More often than an agent-first pitch tends to suggest. If the input format is stable, the rule set fits on a page, and the same input must always produce the same output, a rule engine or an integration usually wins on the axes that matter: cost per item, latency, testability and the ability to explain a result to an auditor. Reach for an agent when variability in the input is the actual problem you are solving.

Designing the approval step

Approval is a design decision, not a checkbox at the end. Sort every action the agent can take into three tiers. Tier one is reversible and low consequence: adding a tag, drafting text into a field nobody has seen, writing to a staging table. Let it run. Tier two is consequential but bounded: posting an invoice under a threshold, merging records, updating a deal stage. Require confirmation, but make confirming cheap by showing the evidence beside the proposal. Tier three touches money leaving the business, external communication or anything covered by a contract or a licence. A person decides, always, and the agent's role is to prepare the decision.

An agent you cannot explain to your auditor is an agent you will eventually turn off.

Two failure modes deserve attention. The first is approval fatigue: if every item needs a click and the interface makes review slow, people start rubber-stamping and you have automated nothing but the appearance of oversight. Batch approvals, sort by confidence, and show the source document next to the extracted values. The second is the silent downgrade, where an item that should have gone to tier three gets classified into tier one. Set tier by the action's effect, not by the agent's own assessment of its confidence.

Audit trails and scoped permissions

Every automated run should leave a record you can read without the engineer who built it. That means the raw input, the model and prompt version, the tools called with their arguments, the proposed action, the confidence or reasoning summary, who approved it and when, and the identifier of the resulting record. Store it where your retention policy already applies. This is unglamorous work, and it is the difference between an automation you can keep after a change of staff and one that quietly gets switched off during the next review.

Permissions follow the same discipline. Give each agent its own service identity, scoped to the specific operations its job requires, with read and write separated. An intake agent reads the mailbox and writes to a triage table. An invoice agent reads documents and writes proposals, never ledger entries. Rotate credentials, keep secrets out of prompts, and assume that any text arriving from outside your organisation may try to instruct the agent: content in a document is data, never a command. If you handle personal or financial records, work through the security and compliance requirements before the pilot, not after it.

Running a pilot that tells you something

Choose one queue with enough volume that a week produces a real sample. Keep the manual process running in parallel for the first stretch, so you have a baseline to compare against rather than an impression. Track four things: how many items completed without human intervention, how many were corrected at approval, how many were wrong and got through, and how long the whole loop took end to end. The third number is the one that matters. A high correction rate is a tuning problem. Errors that pass review are a design problem, and they usually mean the approval interface is not showing enough evidence.

Expand when the numbers stop being interesting. Add the next queue, reuse the audit and permission scaffolding, and resist the temptation to give one agent more scope because it is working. Several narrow agents with tight permissions are easier to reason about, easier to test and easier to retire than one that has quietly become load-bearing across four departments.

How OlDevs helps

OlDevs is a full-stack technology studio in Vancouver, British Columbia, working since 2014 with one accountable team and a working demo every week. Our AI development practice covers exactly this kind of work: mapping the queue, deciding which steps deserve an agent and which deserve a rule, building the integrations underneath, and putting an approval interface in front of people that they will still be using six months later. We build to WCAG 2.2 AA, work in English and French, and reply to every enquiry within one business day. You own all code, designs, accounts and IP from the first commit, which matters more than usual with automation: the workflow that runs your back office should not be something you rent.

If you have a queue in mind and want a straight answer about whether it needs an agent or a rule, request a quote and tell us what happens to an item in that queue today.