CRM and workflow automation with AI agents means connecting a reasoning system to the tools a business already runs — CRM, calendar, database, helpdesk, internal APIs — so it can read context, decide what to do, and write results back. Agents suit variable, judgement-shaped steps; deterministic automation remains better for fixed sequences.
There is a version of an AI project that is mostly about models, and it is the version that stays in a demo environment. The projects that reach production are mostly integration: getting the agent read access to what is true, write access to what matters, and permission to do neither more nor less than intended.
Agents and deterministic automation are not rivals
A well-built system uses both, and knowing which is which is most of the design work. The mistake in both directions is common: teams write a hundred brittle rules to handle unstructured input, or they hand a model a job a cron and a webhook would have done perfectly.
| The step | Use | Why |
|---|---|---|
| Form submitted, create a record | Deterministic | Fixed input, fixed output, no judgement |
| Read an inbound email and decide what it is about | Agent | Unstructured input, variable intent |
| Move a deal stage when a contract is signed | Deterministic | The trigger is unambiguous |
| Decide whether this lead is worth a rep's time | Agent | The criteria are patterns, not thresholds |
| Send the confirmation email | Deterministic | Reliability matters more than flexibility |
| Summarise a call and write the next step | Agent | Requires reading and compressing meaning |
The pattern that holds up: deterministic on the rails, agent at the junctions. The agent decides, the plumbing executes — which also means a model outage degrades the interesting parts rather than stopping the business.
Tools are an API design problem
A tool is the interface between the agent and a real system, and it deserves the care of any other API. In practice, poor tool design causes more agent failures than poor prompting does, because a model given an ambiguous tool will use it ambiguously.
- One clear job per tool. Not a general update record tool with fourteen optional fields, but book_meeting, update_lead_stage, issue_refund.
- Descriptions written for the caller. The tool description is a prompt; a vague one produces a vague call.
- Validation at the boundary. Reject a malformed call with a message the agent can act on rather than accepting it and failing downstream.
- Idempotency. A retried call should not create a second meeting. Assume retries, because there will be retries.
- Errors that explain. Insufficient permission and no availability that day should be different messages, because they lead to different next steps.
- The narrowest scope that works. A read tool that returns one customer, not a query tool that can return the table.
export const bookMeeting = {
name: "book_meeting",
description:
"Book a sales call on the owning rep's calendar. Use only after the lead has" +
" confirmed a specific slot returned by list_availability.",
input: {
leadId: "string — CRM record id, never an email address",
slotId: "string — must come from a list_availability result",
agenda: "string — one sentence, in the lead's own words",
},
returns: {
ok: "{ meetingId, startsAt }",
slot_taken: "Someone booked it first. Call list_availability again.",
lead_not_found: "Wrong id. Do not create a lead from this tool.",
outside_hours: "Rep is unavailable then. Offer another slot.",
},
} as const;Writing to a CRM without corrupting it
A CRM is a shared source of truth that a lot of people's work depends on, and its failure mode under automation is quiet: not an outage, but a slow accumulation of near-right records until the reps stop believing the pipeline. The rules below are the same ones an AI sales agent has to follow, for the same reason.
- Deduplicate before you create. Match on email, domain and phone, and merge rather than adding another copy.
- Never silently overwrite a human edit — append and flag instead.
- Write only to a defined schema with permitted values. Unmappable information goes in notes.
- Mark provenance on every agent-written field, with source and timestamp, so a bad batch is findable.
- Follow the CRM's own ownership and routing rules rather than reimplementing them.
- Keep deletion out of scope entirely.
The systems that will slow you down
Every integration project meets the same three obstacles, and none of them are about AI.
- The legacy system with no usable API. Options are a database read replica, a nightly export, or a human in the loop for that step. Screen automation is a last resort and it will break.
- Permissions. Getting scoped credentials approved often takes longer than the build. Start that conversation in week one, not week five.
- Two systems that disagree about the customer. Someone has to decide which one wins, and that decision belongs to the business rather than to the agent.
None of these are reasons not to do the project. They are reasons to sequence it honestly, and to be suspicious of any plan where integration is a single line item near the end.
Observability is not optional
An agent acting on your systems without traces is an unauditable process with write access. At minimum: every run recorded with its inputs, every tool call with arguments and result, every decision point with what was chosen, and the ability to replay a run to see what it would do now.
This is also what makes improvement possible. The interesting cases — the escalations, the retries, the ones a human corrected — are the specification for the next iteration, and they only exist if you logged them. Where a step needs to read your own documents rather than your systems, the layer it reaches for is described in RAG and knowledge systems.