AI Agents in CRM: Automate Preparation, Keep Decisions with Staff

Why an agent needs a “review” button

In a typical support workflow, an employee opens a ticket, checks the customer history in the CRM, consults a policy, drafts a reply, and changes the ticket status. A model can read the context, find an instruction, and prepare a draft. But if it can also send email, promise compensation, and change records, one error can become an external business outcome.

A useful first version for a small or midsize business is not an “unrestricted digital employee.” It is an executor with a narrow set of tools: read permitted data, prepare a proposal, wait for approval when an error would matter, and perform only the specific approved action.

This is a boundary between probabilistic decision preparation and deterministic execution in a CRM, email, accounting system, or order service. It does not depend on where the model runs.

Classify actions by their consequences

Before development, divide operations into three groups.

• **Suitable for direct automation in a pilot:** classify a ticket, extract an order number, summarize a case, draft a reply, suggest a category, or assign a task under a fixed rule. These steps do not send a message or change money or access rights.
• **Require explicit approval:** send an external email, promise a deadline or discount, change an owner in a way that affects an SLA, issue a refund or write-off, publish content, or close a case with significant consequences.
• **Do not expose as tools:** arbitrary SQL, bulk deletion, permission changes, money transfers, and operations reserved for a separate company process or dual control.

This is not a universal legal classification. The right control depends on consequences, reversibility, and existing authority. A draft can be recreated; a promise already sent to a customer is much harder to undo.

The pattern: propose, review, execute

Build the workflow as explicit states rather than one long prompt.

1. **Get the task and context.** The integration layer checks user permissions and fetches only the CRM fields that are needed. For company policies, add RAG so the agent receives relevant excerpts with their source and date, not the entire archive.
2. **Prepare a structured proposal.** Return fields such as `action`, `customer_id`, `draft_text`, `reason`, `source_ids`, and action parameters. Free-form text must not become a CRM command directly.
3. **Validate with ordinary code.** Check the schema, customer, allowed fields, discount limit, ticket status, and whether the record is still current. An unknown action or failed condition means rejection or clarification.
4. **Pause for review.** The person sees what will happen, to whom, based on which data, and what will change. They can approve, edit, or reject the proposal.
5. **Recheck after approval.** The server verifies that the reviewer is authenticated and authorized. It then checks the business rules again: the record may have changed while approval was pending.
6. **Execute a narrow command.** Prefer separate operations such as `save_reply_draft`, `send_approved_reply`, and `set_ticket_category` over a universal `update_record(any JSON)`. The executor gets minimal permissions and only parameters from the approved version.
7. **Record and recover safely.** Store the ticket ID, reviewer, approved parameters, CRM result, and timestamp. On failure, do not blindly repeat the action: inspect the prior attempt, use an idempotency key, or request manual reconciliation.

The OpenAI Agents SDK documents a similar cycle: a sensitive tool call can pause and resume after a decision with saved state. LangGraph provides `interrupt` and persistence for pausing, checkpointing, and resuming. These are implementation examples, not required stack choices.

The approval card is part of the control

If the employee sees only “The agent requests approval,” it is hard to spot an error. Show:

• the customer and record to be changed;
• the message text or exact field changes;
• a brief reason and the sources used;
• the applicable policy version and date;
• consequences such as the external recipient, refund amount, SLA, or new status;
• expiry time and a warning if the record changed after preparation.

Approval applies to one action and its parameters. If the model can change the text, amount, or recipient after approval, that is a different action. A material edit should return for review.

A minimum architecture

A pilot can often start with a CRM connector, an orchestrator with a model and limited tools, storage for pending approvals, and a small approval panel or bot. Add a search index for company rules if needed. For sensitive data, some processing can run in a local or protected environment.

A local model and action control solve different problems. Running the model inside the company may reduce external data transfer, but does not limit its CRM permissions. A cloud model can prepare a draft without being able to send it if tools and server-side authorization are separated.

Use a separate technical account with minimum permissions. Enforce authorization in the integration service and target system; do not ask the model to decide who may do what. OWASP recommends reducing agent-extension functionality and privileges, validating requests in downstream systems, logging activity, and applying rate limits.

Where RAG helps—and where it does not

RAG helps with current instructions: refund rules, service descriptions, delivery windows, and escalation criteria. Keep the source, version, and effective date for every excerpt. If documents conflict, route the case to an employee instead of letting the model choose a convenient answer.

Retrieval does not replace system checks. A customer email or attachment may contain instructions intended to manipulate the agent. Treat them as content to analyze, not as authority. Even a policy excerpt allowing a discount must be checked in code against the user role, limit, and current order state.

Fine-tuning is usually not the first step. Start with data quality, retrieval from current documents, output structure, and straightforward tool rules. If an answer cannot be verified against a source or required field, the action should stop.

Risks and protection against duplicate actions

A pause reduces risk, but does not provide complete security by itself. Add server-side controls:

• a short-lived approval ID bound to the employee, object, and exact parameters;
• a permission check at execution time, not only when the card is displayed;
• protection against double-clicks and repeated event delivery;
• an expiry time after which the proposal must be generated again;
• an audit log without unnecessary personal data and a quick way to disable the tool;
• action limits and a safe fallback if the model, CRM, or approval panel is unavailable.

If approval takes too much attention, employees may start clicking by habit. Automate low-risk, reversible steps and reserve manual review for external or financial consequences. Periodically review a sample of actions and the reasons for rejection.

How to evaluate a pilot

Do not begin by promising a particular automation rate. Choose one ticket type and record a baseline: time to first response, employee handling time, share of drafts edited, categorization errors, and repeat contacts. Compare the same workflow with the agent.

Track review and approval minutes, proposals changed or rejected, data that became stale while waiting, operations that needed correction, and model, integration, and support cost per ticket.

If preparation gets faster but the approval queue grows, the bottleneck has moved. If speed is unchanged but staff repeat fewer searches and miss fewer fields, the result may still be useful—measure process quality, not only speed.

A first implementation plan

• Choose one process with clear rules and a measurable outcome.
• Start with read access and draft preparation, without write permissions.
• Test anonymized or otherwise permitted examples, including conflicting and incomplete requests.
• Add one narrow command for an approved action and server-side permission checks.
• Pilot on part of the workflow while keeping the current process as a fallback.
• Decide whether to expand autonomy, change the rules, or keep the agent as a preparation assistant.

The management takeaway

Do not start with “Can the model answer customers on its own?” Define what it may only propose, what an employee must approve, and where a separate control is required. Then give the agent one small part of the workflow with a measurable outcome and an audit trail.