An agent that can only talk is a demo. An agent that can look something up in your CRM, raise a ticket, or update a record is useful — and is also where the engineering starts. The gap between the two is mostly about access, identity and what happens when something goes wrong.
Reads and Writes Are Different Projects
Reading is comparatively straightforward: authenticate, query, return. Writing changes the risk profile entirely. A wrong answer wastes someone’s time; a wrong write creates a record somebody has to find and undo. Teams that treat both as “connect the API” discover the difference in production.
A practical progression is to ship read-only first, watch what people actually ask for, then add writes one action at a time — each with its own permission scope and its own decision about whether a human approves it.
Whose Permissions Does the Agent Use?
This is the question most often deferred and most often regretted. Two models:
- Service account. The agent holds one identity with a fixed permission set. Simple to build. The risk is that the account accumulates broad access, and every user effectively inherits it — an agent that can read all records will answer questions the asker was never entitled to ask.
- Delegated user identity. The agent acts as the person asking, inheriting their existing permissions. More work to implement, but your existing access model keeps working and the audit trail names a real person.
Delegated identity is the right default wherever the underlying system supports it, particularly for anything containing customer, HR or financial data.
Design for the Failure Modes
- The system is down or slow. The agent should say so plainly. An agent that answers from stale context during an outage is worse than one that admits it cannot reach the system.
- Ambiguous targets. Three customers share a name. The agent must ask, not guess — guessing is how the wrong account gets updated.
- Partial completion. Two of three steps succeeded. Decide in advance whether to roll back or report precisely what was done; silence here is what erodes trust.
- Repeated actions. A retry should not create a second ticket. Idempotency belongs in the design, not in an incident review.
Where MCP Fits
The Model Context Protocol gives agents a standard way to reach tools and data, which means an integration you build once can serve more than one agent or assistant instead of being wired into a single product. That is a genuine architectural benefit. It does not remove any of the questions above — an MCP server still needs scoped permissions, an identity model, audit logging and sensible failures. The protocol standardizes the plumbing, not the judgement.
What to Log
Anyone operating an agent against business systems will eventually be asked what it did and why. Record the request, the tools invoked with their parameters, what came back, what the agent did, and who approved anything that needed approval. This is not only governance — it is the only practical way to debug behaviour you cannot reproduce on demand.
A Sensible First Project
Pick one workflow with a clear owner, a real cost in staff time, and a bounded blast radius. Ship it read-only, measure whether people use it, then add the one write action that saves the most effort — with approval on it until the logs justify removing that step.
Related service: AI agent integration services
