An agent that only talks is easy to judge. An agent connected to your CRM, mailbox and shared documents can change real records and send real messages. Many teams connect all three in the first week because the demo looked good. When the first wrong customer note appears, nobody knows which connection caused it.
This article is about the agent side of integration: in what order to connect, what to test at each step and how to step back. If you are designing the data flow between the systems themselves, see how to integrate CRM, email, docs and chat without breaking work.
Why one at a time
Each new connection adds its own failure types: wrong permissions, stale data, duplicate records, messages sent to the wrong person. With one connection at a time you learn how the agent behaves with that system alone. If something goes wrong in week three, you know which of the three systems it touched.
It also keeps the review small. The owner of the CRM signs off on the CRM step, the owner of the mailbox on the mailbox step. Nobody has to judge three systems at once.
Choose the order
Order the systems by how easily a mistake can be undone, not by how exciting they are.
- Documents first. Reading company documents is low risk, and a wrong answer is visible to the reader. Prepare the sources first, as described in preparing company documents for an AI agent.
- CRM second. Records can usually be restored if you keep a copy of the earlier value, but a wrong update spreads into reports and follow-ups.
- Email last. A sent message cannot be recalled. Start with drafts that a person sends, and move to sending only if the process justifies it.
Your own order may differ. If the CRM is clean and the document library is chaos, start with the CRM. The rule is the same: first the system where a mistake costs least.
The steps for each system
Repeat these five steps for every system before you start the next one.
1. Name the owner and the purpose
One person owns the connection. Write one sentence on what the agent should do in this system and what it must not do, for example "reads open deals and drafts a follow-up note; never changes a deal stage".
2. Give the agent its own account
Do not reuse an employee's login. Create a separate account for the agent with the smallest rights that fit the purpose, so its actions can be told apart in logs and removed in one step. Our article on least-privilege access for AI agents covers read and write rights and credential reviews.
3. Connect read-only
Let the agent read first. Check what it actually sees: whether it can reach records or folders it should not, and whether it reads old and new data correctly. Fix the account rights before going further.
4. Run the written test
Write 10 to 20 realistic cases before the test, including awkward ones: a duplicate contact, an empty field, a document that contradicts another, a message from an unknown sender. Write down what a good result is for each. Run them and record the result. If you need a method, see evaluating AI agent reliability before production. Do not accept "it looked fine"; accept a list of cases with a result each.
5. Add write access in a small step
Allow one narrow write action, such as adding a note to a CRM record or saving a draft. Keep a person approving each action at first, as described in human approval and audit trail. Widen the permission only after a period of clean results that you agreed in advance.
Plan the way back before go-live
For each system, write down two things before the write step is switched on.
- How to switch it off. Who can disable the agent's account and how fast. Test it once, not only on paper. The ideas in kill switches and incident response apply here.
- How to undo changes. For the CRM: keep the previous value of every field the agent changes, so it can be restored. For documents: use version history and have the agent write to a separate folder or draft area. For email: drafts only until you trust the process, because sent mail cannot be undone.
Also decide how you will notice a problem. The daily check in a daily health check for your AI agent is a good start for the first weeks.
Worked example (invented numbers, for illustration only). A team plans three connections and gives each a trial of two weeks of working days: 10 days per system. With one system at a time that is 3 x 10 = 30 working days, about six weeks, before all three are live. Doing all three at once would save about four weeks on paper. But suppose in the combined trial 6 of 60 test cases fail, a 10% failure rate. The team cannot tell whether those six come from the document source, the CRM fields or the mailbox rules, so it must retest all three. In the one-at-a-time plan the same six failures would appear in a single system, and only 20 cases would need rerunning. The slower plan is often the faster one once something goes wrong.
Common mistakes
- Connecting everything for the demo. The demo needs one clean path, not three live systems.
- Using a person's login. You cannot tell who did what, and the agent inherits rights it does not need.
- Skipping read-only. The first wrong write is then also the first time you see what the agent can reach.
- No tested way back. A rollback plan that was never tried is a hope.
- Moving on without the owner's sign-off. Each step needs a named person who says it works.
Where to start this week
Pick the system where mistakes are cheapest to undo. Name its owner, create a separate agent account with read-only rights and write 10 to 20 test cases with the expected result for each. Run them, record the outcome and decide with the owner whether to add one narrow write action. Do not open the second system until the first has a clean record and a rollback you have tried once.
Sources
- Your own system rights, test cases, logs and rollback tests, as collected in the routine described; all figures in the worked example are invented for illustration.
- Our related articles linked above.