The problem
The agent can talk, but the work lives in the ERP, the CRM, the phone system, and the payment processor, and it cannot touch any of them. So it drafts and suggests while a person still does the typing.
What goes wrong
- The connector is a script someone wrote in a week. It works on the demo account and breaks the first time a field is renamed or a rate limit hits, and nobody owns it.
- The agent gets an admin key because that was fastest. One bad write can now touch payroll or delete a customer.
- Writes go out with no gate. The agent posts a credit or changes a dispatch, and the person who would have caught it hears about it from the customer.
The approach
- Write down every action the agent takes in each system, and mark the ones that need a person: money, customer contact, anything that changes a live shipment.
- Give each system its own service account with least privilege, in accounts you own, so your team can cut off our access in one step.
- Use webhooks where the system supports them and scheduled polling where it does not, with a history backfill so the agent has context from day one.
- Ship every connector with integration tests against the real API and log every action with what ran, why, and who approved it.
When it works
When your systems have APIs or exports, someone on your side can grant access and explain how the data is really used, and you pick one workflow first: quoting, dispatch updates, or collections, not all three.
Why the integration is the product
An agent that can talk but cannot write to your systems is a demo. In a logistics business the work lives in the TMS or ERP, the CRM, the phone system, and the payment processor. If the agent cannot read a load from the ERP, update the customer record, answer a call on your number, and post a payment, it is a chat window beside the real work. The model is the easy part. The connections are what make it real.
What the agent needs from each system
ERP and TMS
Read orders, loads, inventory, and status. Write status changes and new records under a named service account. Pull a history so the agent knows what normal looks like before it acts on today.
CRM
Read the customer, the contacts, and the open deals. Write notes, tasks, and stage changes, tagged as agent actions so your team can filter them.
Telephony
Answer calls on your existing numbers. Log the recording and transcript to the record it belongs to. Transfer to a person with a summary attached, not a cold handoff.
Payments
Read invoice and payment status. Create a payment link or a draft invoice. Never move money without an approval from a named person.
After launch
The connectors stay owned. They are part of the monthly operate routine: monitoring, error triage, and a written report. The integration tests run against the real API before any change goes to production, so when a vendor renames a field, the test fails before the agent does. Actions that need no approval run on their own and land in the same log as the ones that did. The log is yours, and so is the code.
When it does not work
It does not work when the system of record is a spreadsheet that three people keep differently. Fix that first, or let the pod fix it as the first sprint. And it does not work when nobody reviews the approval queue. The gate only helps if someone opens it.
Where to start
An FDE Pod does this work inside your business on a monthly fee on a 12-month term, with a checkpoint at day 90 for a small pod or a day-120 checkpoint for a large pod. What a forward-deployed engineer does all week shows the week from the inside, and a week in a pod has its rhythm. AI integration with your ERP and CRM covers the full build. If you are not sure which system to connect first, ask Roo, Webaroo's AI: Which of our systems should an AI agent connect to first?
Book 15 minutes with Connor