Claude to anything: patterns for connecting AI to your stack

A model on its own can only reason about what you put in the prompt. The moment it needs to know a customer’s order history, check a policy, or update a record, you’re no longer building an AI feature — you’re building an integration.

That’s where most of the engineering effort actually lands, and where the difference between a demo and a system gets decided. These are the patterns worth knowing, roughly in order of how much they cost you to run.

Pattern 1: Retrieval — bring the data to the model

The most common starting point. Fetch relevant documents, put them in the prompt, ask the question. Good for policies, documentation, knowledge bases, contracts — anything that’s read rather than changed.

The failure mode isn’t retrieval, it’s over-retrieval. Real user queries are vaguer than test queries, so the retriever returns more, someone raises the limit to compensate, and now every call carries three times the context it needs. Costs rise, latency rises, and answer quality often falls because the signal is buried.

Cap what you pass, rank it properly, and log what was actually retrieved on a sample of live traffic. The gap between what you think you’re sending and what you’re sending is where the problems live.

Pattern 2: Tools — let the model ask for what it needs

Instead of guessing what data a request needs, you describe the functions available — look up an order, check stock, create a ticket — and the model decides which to call.

This is a better fit for anything transactional, and it scales where retrieval doesn’t: you can’t put your whole order database in a prompt, but you can expose a lookup.

Two rules make the difference between tools that work and tools that surprise you:

• A tool call is a request, not an instruction. Validate every argument server-side. The model proposing refund(order, amount) doesn’t mean you execute it.
• Write descriptions for a competent stranger. Most tool-selection errors are description problems, not model problems — ambiguous names and vague parameters produce ambiguous calls.

Pattern 3: MCP — stop rewriting the same connector

Once you have tools in three different applications, you notice you’ve written the same integration three times with three sets of conventions. The Model Context Protocol exists to solve exactly that: a standard way to expose data and actions so any client can use them.

The practical benefit is organisational rather than technical. One MCP server for your ticketing system serves every AI surface you build — the internal assistant, the agent workflow, the thing someone builds next year. You maintain the connector once, and its permissions and audit logging live in one place instead of being reimplemented per project.

It’s worth reaching for when you can see the second and third consumer coming. For a single one-off integration, it’s ceremony you don’t need yet.

Pattern 4: In-platform — go to where the work happens

The pattern most teams underuse. Rather than building a new interface that connects to your systems, put the capability inside the system people already use — ServiceNow, the CRM, the ticket view.

You inherit three things for free: adoption, because nobody has to change where they work; context, because the record is right there; and governance, because the platform’s existing permissions, audit trail and retention already apply.

A separate AI tool gets used enthusiastically for a month. A summarise button on the ticket people already have open gets used forever.

Keeping data close

Every integration is a decision about what leaves your boundary. Make it deliberately rather than by default:

• Send the minimum. Filter and redact before the call, not after. The safest field is the one that never left.
• Give the model narrower permissions than the user. It should never reach data the person couldn’t reach directly.
• Treat retrieved content as untrusted. If a document or email can reach the prompt, assume it may contain instructions aimed at the model.
• Require confirmation for anything irreversible. Payments, deletions, outbound communication — a human confirms.

Choosing between them

A rough guide that holds up in practice:

• Reading a body of documents → retrieval
• Looking things up or changing them → tools
• Same system needed by several AI surfaces → MCP
• The work already happens in a platform you own → in-platform, first

Most real systems end up using more than one. That’s fine — what causes trouble is choosing a pattern because it’s the interesting one rather than because it fits the job.

The model is rarely the hard part. The integration is the product.

Get the connection right — the right data, the right permissions, in the place the work already happens — and the AI part tends to look after itself. Get it wrong and no amount of prompt engineering will rescue it.

If you’re mapping integration patterns across your stack, start a conversation. You’ll be talking to the people who do the work.