A useful agent needs a defined business contract
Connecting an agent to a CRM does not establish what it should do there. Begin with a business contract: the task, the user, permitted information, allowed actions, and evidence required to call the result successful. A sales assistant might read an account and prepare a follow-up draft. That scope is different from changing account ownership or sending a message to a customer.
Represent each capability as a bounded tool with a typed input and a predictable result. A tool called findOrder should require a valid identifier and return only the fields needed for the task. A broadly privileged tool that accepts arbitrary queries or destinations is much harder to govern. Narrow contracts help developers test the integration and help business owners understand the agent's actual authority.
Separate retrieval from operational action
Knowledge retrieval and system mutation have different risks. Retrieval can provide policies, product documentation, or an account's current state. An operational action changes that state: creating a ticket, amending a record, or booking an appointment. Keep these responsibilities distinct so that read-only assistance can be introduced before write permissions are considered. A grounded answer should not implicitly trigger a transaction.
For a support assistant, the sequence might be identify the enquiry, retrieve permitted help content, answer with source references, and offer to create a ticket. Ticket creation then uses its own validated contract and confirmation. If the retrieval finds no adequate evidence, the assistant should say so and route the question. Adding retrieval reduces some knowledge gaps; it does not guarantee that every generated answer is correct.
Authorization belongs outside the model
The system must decide whether the user and agent may access a record before information is sent to the model. A prompt that says 'do not reveal confidential data' is not an access-control mechanism. Server-side services should validate the identity, enforce resource permissions, and return only authorized fields. The same checks apply to every tool call, even when the agent appears to understand the rules.
Retrieval needs the same discipline. If documents from multiple teams share an index, preserve permissions and source provenance through indexing and query filtering. A post-generation check is too late if unauthorized content already entered the model context. Source permission changes and deletion also need an index-refresh policy. Confirm how quickly revocation must take effect and test that requirement with representative access scenarios.
Use APIs and MCP as controlled interfaces
Enterprise integration may use REST, GraphQL, webhooks, database connectors, or a dedicated adapter. MCP can offer a standardized tool interface to compatible agent clients, but it does not remove the need to enforce the underlying system's permissions. Choose the interface based on supported capabilities, data contracts, and operational requirements. Confirm access and licensing before committing to a proposed integration.
An adapter is a useful boundary. It translates a business action such as createServiceRequest into the destination's actual API, validates arguments, handles pagination or throttling where needed, and returns a safe result. Provider errors should not expose secrets or internal stack traces. Keep the agent independent of unnecessary vendor details while preserving enough information to distinguish rejection, timeout, and a confirmed successful action.
Validate proposals before executing them
Structured output makes a proposal easier to inspect; it does not make it correct. Validate required fields, formats, allowed values, and business constraints outside the model. Check that referenced records exist and that the requested action fits the current state. A generated appointment time may be syntactically valid but unavailable. A supplier identifier may look reasonable but refer to the wrong legal entity.
Human approval should show the information needed to make a decision: proposed changes, supporting sources, uncertain fields, and the action's scope. Bind approval to the specific action rather than a vague permission to continue. Revalidate time-sensitive conditions immediately before execution. If the destination state changes after review, return to the reviewer instead of silently modifying the approved transaction.
Design for uncertain outcomes and untrusted content
An external write may succeed even when the caller receives a timeout. The agent should not decide that a second write is safe merely because it saw an error. Use a stable operation identifier and the destination's supported idempotency mechanisms where available. Otherwise, inspect or reconcile the destination state before retrying. Multi-step actions need explicit partial-completion behavior and a responsible recovery owner.
Documents, emails, and tool results are also untrusted input. A retrieved page may contain instructions designed to redirect an agent. Tool restrictions and server-side authorization must remain effective regardless of that content. Avoid giving the agent unrestricted network destinations, arbitrary code execution, or access to credentials. Test attempts to disclose information, change tool arguments, or bypass approval using representative malicious content.
Evaluate quality and operations together
Create an evaluation set before expanding the agent's scope. Include common requests, ambiguous wording, missing records, stale knowledge, unauthorized users, and unavailable tools. Assess whether the response is supported, whether the correct tool was selected, and whether the action respected policy. A correct final sentence can hide an unnecessary or unauthorized intermediate tool call, so evaluate the trace as well as the answer.
Operational checks cover latency, bounded tool calls, dependency errors, and cost. Establish limits for execution time and model use. Capture minimized telemetry with a correlation identifier, tool names, outcome categories, and timing. Logging every prompt and response may expose unnecessary personal data; decide what evidence is needed and how it is protected. Quality and runtime health should remain separately visible.
Release autonomy in controlled increments
A practical rollout can start with read-only assistance, progress to reviewable drafts, and then permit narrowly defined low-risk actions. Each stage has its own acceptance criteria. Confirm that users understand limitations, that support teams can investigate issues, and that a shutdown or rollback procedure exists. The organization needs an operating model for the agent, not only a deployment process. Identify who can suspend a tool immediately, how pending requests are handled during suspension, and what evidence is needed to restore access.
Expansion should follow evidence about the actual task and data. More tools, memory, or collaborating agents add dependencies and new failure paths. Introduce them when they solve a demonstrated problem, then update permissions, evaluations, and runbooks. Enterprise integration succeeds when the agent's capabilities are useful, its authority is explicit, and the business can explain what happened when a request goes wrong.