Most business AI fails at the same point. It can hold a conversation, and it cannot tell you whether the item is in stock, where the order got to, or what this customer is actually owed. The interesting work is not the conversation. It is reaching into the system that holds the answer, doing something there, and writing the result back where the business can see it.
Stated plainly, because an integration roadmap sold as finished is how these projects go wrong.
Ten published lookups across stock, pricing, orders, deliveries and invoices, plus quotations, sales orders and credit requests once the customer is verified. On-premise service, outbound-only connection, nothing inbound opened at your site.
Order status, fulfilment and tracking, returns and refunds. The highest-volume question in any online store, answered from the store rather than from a mailbox somebody checks on Monday.
If it has an authenticated API, an agent can use it under exactly the same permission model and the same audit trail. Nothing bespoke is exempt from the rules that govern the packaged connectors.
Named because customers have asked for them, not because they are finished. If one of these is the difference for you, that moves it up the list.
Invoice status, statements on request, and the follow-up on what is overdue — the ledger side of the debtor work the recipes already do against Business One.
Stock across locations, click-and-collect status, and the retail questions that currently interrupt whoever is serving.
Not a connector but the same argument: another place customers already are, answered by the same agent reading the same systems under the same rules.
It is not a general-purpose bridge that lets an agent do whatever it can talk itself into. Every connector exposes a fixed, published list of operations, written in advance. The agent chooses one and supplies parameters; it cannot compose a query of its own, so the entire class of problem where an agent improvises something damaging does not exist. Each operation carries a risk class, from read-only through the write tiers. Two levels of permission — the policy for your company, then the subset a particular agent holds — are evaluated at the moment the operation runs, not cached from setup. Every request is recorded with its outcome, approved or refused, and refusals are recorded with the reason, so an attempt to reach something out of scope is visible to you rather than silent.
A single lookup is useful. A job that reads one system, decides, acts in another and reports back is what actually removes work.
The store takes an order the warehouse cannot complete. Availability is checked, the shortfall found before picking, the customer given real options and the outcome written back — while it is still a choice rather than an apology.
The invoice is overdue in one system and the next order is sitting on credit hold in another. Today those are two people noticing two things on two reports. It is one conversation.
The return is authorised against the original order, the credit raised against the right document, and the customer told what happens next and when — without a person rekeying it into a second system.
A scheduled pass across the systems at six in the morning, finding what does not fit the pattern, investigating the cause and leaving a short brief before anyone sits down.
Your own software calls the API and hands the job to an agent. The agent runs the play, acts under the same permissions, and returns the result to whatever asked for it.
Accounts that used to order monthly and have not for a quarter. Found by a scheduled pass over the sales history, contacted, and the response recorded against the account.