Most owners who ask me about AI agents have read the definitions already. What they want is the job itself. What does the agent do on a Tuesday morning, which screens does it open, and who gets the call when it gets something wrong?
So here are seven agents that fit a company of 20 to 250 people. They are generic on purpose. I describe the shape of each one rather than a client story, because I have no client stories to tell yet and I won't make any up. Every example runs in the same order. First what the agent does, step by step, then the systems it touches, where a person approves and what goes wrong.
If you are still deciding whether you need an agent at all, read how an AI agent differs from a chatbot first. Everything below assumes the software changes something in one of your systems.
1. Shared inbox triage
An address like info@ or orders@ collects orders, complaints, delivery questions, job applications, supplier price letters and spam. Somebody reads all of it each morning and forwards it by hand.
What the agent does:
- Reads each new message and its attachments as they arrive.
- Sorts it into categories you define, for example order, complaint, invoice, delivery query, application and other.
- Looks the sender up in the CRM or ERP and adds the customer or supplier number.
- Files the message in the right queue or opens a ticket, with a one-line summary on top.
- Sends anything it is unsure about, and everything in "other", to a review queue.
Systems it touches. The mail server (read and move), the CRM or ERP (read only) and the ticket system (create).
Where a person approves. Routine routing needs no approval, because a misrouted email costs one forward. A person clears the review queue every day. In the first version, every reply to a customer still comes from a person.
What goes wrong. One email holds two topics, say a complaint tucked inside a reorder, and the second topic waits in the wrong queue. Customers who write from a private address don't match any CRM record. Categories also go stale. A new product line brings messages that fit nowhere, and the agent forces them into the nearest category unless "other" is an answer it is allowed to give.
2. Order entry from PDF purchase orders
Customers send orders as PDFs, each in their own layout, and someone in sales support types them into the ERP line by line.
What the agent does:
- Picks the PDF up from the orders mailbox.
- Reads customer, delivery address, requested date and every line with article number, quantity and price.
- Maps the customer's article numbers to yours through a cross-reference table and flags lines it can't map.
- Checks prices against that customer's price list and quantities against pack sizes and minimum order.
- Creates the sales order as a draft in the ERP, with every deviation listed at the top.
Systems it touches. The mailbox, the ERP (read master data, write draft orders) and the cross-reference table.
Where a person approves. Someone releases each draft. Once you have measured the error rate in shadow mode, clean orders from repeat customers can release on their own, and anything with a deviation keeps waiting.
What goes wrong. A customer changes their PDF template and the agent reads the unit price as the line total. "1.000" on a German order means one thousand, and a parser set up for English reads it as one. Handwritten corrections on a scanned order get lost. The defence is a check in code that the lines add up to the order total, with a hold on every order where they don't.
3. Supplier invoice matching
Invoices arrive as PDFs or e-invoice files and have to be matched against the purchase order and the goods receipt before anyone pays them.
What the agent does:
- Reads the invoice and pulls out supplier, invoice number, lines, tax and bank details.
- Finds the purchase order and the goods receipt in the ERP.
- Compares quantity and price within the tolerance you set.
- Queues a clean match for payment approval, or sends the invoice to the buyer with the exact mismatch named.
Systems it touches. The accounts payable mailbox, purchasing and receiving in the ERP, and the accounting system, where it writes drafts only.
Where a person approves. Payment approval stays with a person. So do new suppliers, invoices above your approval limit and any change of bank details. Those limits sit in the connector code, where the model can't talk its way past them. The piece on hard limits in code explains why a prompt is not enough.
What goes wrong. Partial deliveries, one invoice covering three orders and freight charges with no order line all need rules of their own. A forged letter announcing new bank details is the expensive one. I cover invoice matching in more depth as one step of the month-end close.
4. Month-end reconciliation prep
The close needs bank statements matched, open items explained and intercompany differences traced before anyone can sign.
What the agent does:
- Pulls the bank statements and the open items on the first working day.
- Proposes a match for each statement line and attaches the evidence.
- Lists the lines it could not place, with the closest candidates.
- Drafts an explanation for each intercompany difference, such as a timing gap or a different FX rate.
- Updates the status of each item on the close checklist.
Systems it touches. Bank statement files, the ledger (read only) and the folder where your working papers live.
Where a person approves. Every posting. The agent prepares, the accountant books.
What goes wrong. Matches that balance and are still wrong, such as a partial payment with a deduction or one transfer that covers six invoices. I have collected the patterns where automated matching breaks. The month-end article walks through each close step, so I keep this one short.
5. First-line support with escalation
Here the agent writes to customers. That makes it riskier than the others, and it is also where an agent differs most from a chatbot, because it acts on the ticket instead of only answering.
What the agent does:
- Reads each new ticket and looks up the order or contract behind it.
- Drafts a reply from your help articles and the order data.
- For a short list of request types, such as an invoice copy, a delivery status or a return label, it also does the work. It sends the copy, checks the carrier or creates the label.
- Hands everything else to a person, with its draft and the facts it found already attached.
Systems it touches. The ticket system, the ERP or shop backend (read), the carrier portal (create return labels) and the help centre.
Where a person approves. In the first version, a person reads and sends every reply. After a shadow period, only the listed request types go out unread. Refunds, credit notes and legal complaints always go to a person, and so does any customer writing about the same problem for the second time.
What goes wrong. The agent answers confidently from a help article that went out of date last spring. It misses the real question at the bottom of a long thread. It sends a cheerful template to someone who is plainly angry. How you design the queue where these cases land decides whether your team trusts the agent or works around it.
6. Lead qualification and CRM upkeep
Web form enquiries land in a mailbox, someone copies them into the CRM, and the good ones wait a day for a reply.
What the agent does:
- Reads each new enquiry from the form or the inbox.
- Checks the CRM for an existing contact or company, so it doesn't create a duplicate.
- Scores the enquiry against criteria you have written down, for example industry, company size, region and what they asked for.
- Creates or updates the CRM record and assigns it to the right salesperson.
- Drafts a first reply that proposes a call.
Systems it touches. The form or inbox, the CRM (read and write) and your booking link.
Where a person approves. The salesperson sends the first reply. The agent never changes a deal stage, merges records or deletes anything.
What goes wrong. The same company writes from two domains and ends up twice in the CRM. The scoring criteria were a guess two years ago and nobody has looked at them since, so the agent sorts leads by an old opinion. Enrichment is another trap. Keep the agent to what the lead sent you and what their own website says, and ask whoever handles data protection before you add anything else.
7. Document intake and chasing
Supplier onboarding, customer contracts and certifications all depend on documents that arrive late, in the wrong format or not at all. Someone keeps a spreadsheet of what is missing and writes reminder emails.
What the agent does:
- Keeps a checklist per supplier or customer of the documents you need and their expiry dates.
- Reads incoming documents, identifies the type and pulls out the key fields, such as the expiry date or certificate number.
- Files each document in the document store against the right record.
- Checks every week what is missing or expires within 30 days.
- Sends a reminder from an approved template and escalates to a person after the second one.
Systems it touches. The mailbox, the document store or shared drive, the supplier or customer master data (read) and outgoing email.
Where a person approves. A person approves each template once, then reminders go out on their own. Judging whether a document is good enough, say an insurance certificate with the right cover, stays with a person. The agent never updates bank details from a document.
What goes wrong. Last year's certificate gets accepted because the agent read the issue date as the expiry date. A supplier sent the file to their account manager instead of the shared inbox, and the agent chases them anyway. Check every intake channel before you let it send a reminder, or your suppliers will notice before you do.
What the seven have in common
Each one starts on an event or a schedule, not a chat window. Each works across two to four systems you already own. They write drafts or low-risk changes on their own and send anything costly or irreversible to a person. That line between the two is written in code, and every agent has a review queue that someone clears daily.
None of them replaces a department. Each takes over the copying and checking inside one workflow, and your people still make the decisions.
Which one to start with
Pick the example that matches work your team repeats every week and that someone could describe on two pages. Then count the hours it takes today, so you can tell later whether the agent paid off. If several candidates compete, rank them before you build anything.
The cost depends mostly on how many systems the agent touches and how many cases drop out as exceptions. What drives the price of an agent build goes through that in detail. Whatever you pick, run it in shadow mode next to the person who does the work today before it writes anything real.
If one of these seven looks like a job your team does every week, bring the PDFs, the inbox or the checklist to a scoping call. Our agent build service takes one workflow like that into production on the software you already run.