Talk about AI agents in business systems has run well ahead of what companies actually do with them. In vendor presentations, an agent reads the inbox, updates the CRM, raises the purchase order, posts the invoice and closes the ticket, all before lunch. In the companies that really run ERP, CRM, IT service management and support platforms, the picture is more modest – and, I would argue, more interesting. Agents connected to those systems are already doing useful work, but it’s a particular kind of work, and the organizations getting value from them are the ones that have been honest about which kind.
By an agent, I mean software that uses a language model to interpret a situation, decide what should happen next, and then act through the tools it has been given – which, in a business setting, means the APIs of the systems of record. In this article, I’ll survey where such agents earn their keep today, where they don’t yet, what integration plumbing they depend on, and how to choose a first use case. I’ve deliberately left out the detailed design of guardrails, permissions and approval checkpoints, because we’ve written about that separately in AI agent guardrails. The question here comes earlier, and it’s more commercial: where should you point an agent in the first place?
The shape of work agents are good at
Before getting to specific use cases, it helps to name the pattern the successful ones have in common. Agents do well where the input is messy but the range of correct outcomes is small. A support ticket arrives in free text, written by an irritated customer, but it belongs in one of perhaps twenty queues. A supplier invoice arrives as a PDF in a layout nobody has seen before, but the fields that matter are the same fields every time. A reconciliation break looks baffling in a spreadsheet, but its cause is usually one of a handful of familiar explanations. In each case, the hard part for traditional automation was the interpretation, and interpretation is exactly what language models are good at.
Agents do badly – or, at any rate, dangerously – where the range of outcomes is large, where the action can’t be undone, or where the right answer depends on context that lives in someone’s head and in no system at all. They also struggle where nobody can tell whether they got it right, because an agent you can’t measure can’t earn more responsibility.
That distinction, between turning a messy input into a constrained decision and making an open-ended commitment on the company’s behalf, explains most of what follows.
Where agents earn their keep today
Triage
Triage is the most mature use case, and in most organizations it’s the right place to start. In an ITSM platform, an agent can read an incoming incident, classify it, set its priority against the documented criteria, identify the likely configuration item, link it to an existing major incident when the symptoms match, and route it to the right resolver group. In customer support, it can do the same for tickets, adding the customer’s account context from the CRM and the order or billing history from the ERP, so that whoever picks the ticket up starts with the facts instead of a search. Misroutes are cheap and easy to spot, the volume is high, and the historical ticket data gives you a ready-made set of labeled examples to evaluate against.
Exception handling
Most integration and transaction processes run cleanly most of the time, and then throw off a steady stream of exceptions that land in a queue for a person: orders that failed validation, invoices that didn’t match, sync records the target system rejected. Clearing those queues means repetitive investigation, followed by one of a small number of standard fixes. An agent can read the error, pull the related records from both systems, work out which of the known patterns applies, and either propose the fix or apply it, when it falls within an agreed category. In my experience, this is where agents are most underused, because the exception queue is rarely anybody’s favorite project.
Reconciliation investigation
Reconciliation itself should stay deterministic. A report that proves two systems agree has to be computed – inference has no place in it – and we’ve written about how to build one in Integration reconciliation reports. What an agent adds is the investigation that follows a break. When the CRM shows a contract value the billing system doesn’t, or a ledger total disagrees with a subledger, somebody has to trace the records, read the change history and work out what happened. An agent can do that tracing, put the evidence together and write a plain account of the probable cause, and leave it to a person to decide on the correction. The risk is low, because the agent only explains and changes nothing.
Document intake
Supplier invoices, purchase orders that come in by email, remittance advices, onboarding forms, certificates of insurance and shipping documents all arrive in formats nobody controls. Template-based extraction has always struggled with the long tail of layouts. An agent can extract the relevant fields, validate them against the master data in the ERP, flag whatever doesn’t match, and create a draft transaction for review. Draft is the important word there. The value is in getting rid of the keying and the first-pass checking, and the person who approves stays exactly where they are.
Data quality
Duplicate accounts in the CRM, inconsistent supplier names in the ERP, missing classification codes on items, contacts attached to the wrong company – every business system collects this kind of debris, and cleaning it up is tedious enough that it rarely happens. Agents are well suited to finding likely duplicates, proposing merges with the reasoning attached, normalizing free-text fields and filling gaps from reliable sources. Because changes to master data ripple through every downstream process, the proposals should go through a data steward, at least until the agent has a long record of being right.
Where they do not yet
The list of things agents shouldn’t do unsupervised doesn’t mean they can never do them. It’s a list of places where today’s combination of model reliability, evaluation practice and organizational trust doesn’t yet justify letting them act alone.
Unsupervised financial postings sit at the top of that list. Posting a journal, releasing a payment, issuing a credit note or changing a revenue schedule commits the company in ways that auditors will test, and that are expensive to unwind. An agent can prepare every one of these and present it with the evidence, which is valuable, but the posting itself should stay a human decision or a deterministic rule.
Commitments to customers and suppliers come next. Agreeing to a price, granting credit terms, accepting a return outside policy or promising a delivery date are all commercial decisions, and a model that is persuasive and occasionally wrong is a poor negotiator to put in front of a customer.
Bulk changes to master data – revising price books, restructuring the chart of accounts, reassigning territories – are high in consequence and low in frequency. There are too few examples to evaluate an agent against, and too much damage if it misreads the instruction.
Multi-system transactions without compensation are a subtler case. If an agent creates a customer in the CRM, a billing account in the subscription system and a ship-to in the ERP, and then fails halfway, something has to undo the partial work. Integration engineers design for this with idempotency keys and compensating steps. An agent that improvises its way through the same sequence, with none of that scaffolding underneath it, will sooner or later leave orphaned records across three systems.
Scoring the candidates
Treat the matrix below as a starting point for discussion, and argue with it as you see fit. Value reflects typical volume and labor cost, risk reflects what a wrong action would cost, and readiness reflects how well the use case can be evaluated and how much integration it needs. The scores use a simple high, medium and low scale.
| Use case | Value | Risk | Readiness | Typical posture |
|---|---|---|---|---|
| Ticket and incident triage | High | Low | High | Acts, with a sample reviewed |
| Integration exception handling | High | Medium | Medium | Proposes; acts on approved categories |
| Reconciliation break investigation | Medium | Low | High | Explains; a person corrects |
| Invoice and document intake | High | Medium | Medium | Creates drafts for approval |
| Duplicate and data quality cleanup | Medium | Medium | High | Proposes merges to a data steward |
| Drafting customer responses | Medium | Medium | High | Drafts; a person sends |
| Posting journals or payments | High | High | Low | Prepares the evidence only |
| Pricing or credit decisions | High | High | Low | Not yet |
| Bulk master data restructuring | Low | High | Low | Not yet |
The pattern holds all the way down. The rows worth starting with combine high value with low or contained risk, and the posture column shows that even the best candidates usually begin with the agent proposing, and only later acting.
The plumbing an agent needs
An agent is only as capable as the access it’s given, and in business systems, that access is integration work. The model is the smaller part of the project.
Access through APIs. An agent that drives a user interface the way a person would is fragile, and it’s hard to audit. It should read and write through the systems’ APIs, or through an integration layer that already exposes the right operations – ideally narrow ones, such as “create draft supplier invoice”, and never a general ability to write to any object.
Its own identity and permissions. Each agent should run under a dedicated service account whose permissions match its role exactly. If an agent should be able to draft a credit note but never post one, the system’s own access control should make posting impossible. This is the single most effective control you have, and it costs nothing beyond careful configuration.
Events to wake it up. Webhooks, platform events and message queues let an agent respond to the specific ticket, exception or document that needs it, without polling everything on a schedule, and the usual disciplines for duplicates and out-of-order delivery apply.
Context it can retrieve. An agent’s decisions get much better when it can look up the customer, the order, the contract and the history behind them. That means read access to the right records, with sensible limits on what personal or sensitive data it can see.
An audit trail that finance would accept. Every input, decision and action has to be recorded in a form that someone who wasn’t involved can query later. Without that, there’s no way to evaluate the agent, and it won’t survive its first audit question.
Somewhere safe to practice. A sandbox or a copy of production, filled with realistic data, lets you test the agent against historical cases before it touches live records.
How to choose a first use case
The first use case matters more than its own return, because it sets the organization’s expectations of what agents are for. A good first choice is frequent enough to produce evidence quickly, bounded enough that a wrong answer gets caught and corrected cheaply, and painful enough that the people doing the work today will welcome the help and won’t resist it. It should already have a clear definition of a correct outcome, ideally one you can see in historical records, so that the agent can be scored before it goes live. And it should need only the integration access you already have, or can grant narrowly.
In practice, that points most organizations toward triage or an exception queue, and away from the ambitious end-to-end process that tends to take over the first workshop. It’s wiser to start with the process most likely to work well, even if another would save more if it worked perfectly, because a visible, well-measured success is what earns you the trust to take on the harder candidates.
A client example. A regional business-services organization we worked with handled about 4,500 service desk tickets a month. Its ITSM platform routed them on a few keywords and the requester’s department, and roughly one ticket in four landed in the wrong assignment group. We introduced an agent as a controlled triage assistant. It read each ticket along with the affected service, the configuration item and recent incident history, and it was allowed to set the category and the assignment group and add a note explaining its reasoning. It had no permission to close tickets, raise a priority to critical, change access rights or carry out any remediation.
A deterministic gateway checked each proposed group against the assignment-group catalog, confirmed that the service and group belonged together, and applied a confidence threshold. Tickets touching security incidents, payroll, privileged access or unclear ownership went to the human triage queue. The most useful lesson came from the audit log. The model kept confusing application ownership with infrastructure ownership – a payroll application outage that mentioned a database timeout went to the database team, although the application support group owned first response. We added the service ownership matrix to the context it retrieved and built those borderline cases into the evaluation set. Over the six-week pilot, first-assignment accuracy rose from 74% to 91%, median triage delay fell from 42 minutes to 11, and about 18% of tickets still went to a person for review. We scored the agent on whether its first assignment went to the group that owned the ticket, since a changed field on its own proves nothing.
Related reading
- AI agent guardrails: scope, permissions and audit for AI workers
- Integration reconciliation reports: proving two systems agree
- Idempotent webhooks: duplicates, retries and out-of-order events
How we approach it at eProxim
eProxim has built integrations between business systems since 1997, and we treat AI agents as an extension of that work, with no separate discipline of their own. The agents we build act through the same APIs, middleware and event pipelines as any other integration, under their own scoped identities, with idempotent operations, audit trails, and human checkpoints set by the people who carry the risk. We would much prefer to help a client launch one well-measured agent on a triage or exception queue than a sweeping program nobody can evaluate.
There’s more about how we work on our AI automation page. If you have a process that produces a steady queue of exceptions, and you’d like an honest view of whether an agent belongs there, get in touch.