The layer between your systems and the model
When an enterprise AI project stalls, the post-mortem almost never says "the model wasn't smart enough." The models have been good enough for most business workflows for a while now. What the post-mortem usually says, in more polite language, is: we couldn't get the model to safely touch our actual systems.
That gap has a shape. On one side you have systems of record — SQL Server databases with fifteen years of schema history, internal APIs with authentication schemes designed long before anyone imagined a language model as a caller, file stores, ticketing systems, spreadsheets that are secretly databases. On the other side you have a model that is very capable and completely ignorant of all of it.
What the layer actually consists of
The integration layer is not glue code. Done properly, it's four things, and skipping any of them is how pilots die on the way to production.
Tools with contracts. The model shouldn't see your database; it should see a small set of well-described operations — "look up a policy by number," "list open work items for a team" — each with a typed schema for inputs and outputs. The Model Context Protocol (MCP) has become the standard way to express this, and it matters because a contract is something you can review, version, and test. Raw access is something you can only regret.
Identity and least privilege. The question "what can the model do?" must have the same answer as "what can this specific user, in this specific context, do?" — never more. That means the layer carries the caller's identity through to the underlying system, and the model's tools are scoped down to it. An agent with a service account that can read everything is an incident report with a start date.
An audit trail. Every tool call, its inputs, its outputs, and which conversation triggered it. Not because regulators ask (though in financial services they will), but because the first time an agent does something surprising, the only useful question is "what exactly did it do, and why?" — and you either can answer that from logs or you can't.
Failure paths. Timeouts, rate limits, partial results, systems that are down. A model that gets a clean error it can explain to the user is a feature. A model that gets a stack trace, or worse, silence, will improvise — and improvisation is precisely the behaviour you built the layer to contain.
How to start without betting the year
The pattern that works is narrow and deep, not wide and shallow. Pick one system and one workflow that people actually do every week. Build the layer for that slice — read-only first, real data, real permissions. Get it in front of five users, not five hundred. The lessons from a real slice transfer; the lessons from a demo don't.
Read-only first is worth underlining. Most of the value in early deployments comes from the model reading and synthesising — answering "what's the status of X across these three systems" — and read-only tools carry a fraction of the risk of anything that writes. Earn the write access with months of boring logs.
Why this favours systems engineers
There's an assumption floating around that AI integration is a new specialism unrelated to what came before. The opposite is true. Contracts, least privilege, audit, failure handling — this is what people who have run production systems have been doing for years. The model is a new kind of caller, unusually capable and unusually unpredictable, and it makes that discipline more valuable, not obsolete.
Which is, plainly, the bet this firm is built on.
← All insights