Architecture: How AI Connects to the Company

Why this module exists

The gap between a working prototype and a deployed system is almost never the model. It is integration: where the data lives, what it costs to move, who owns the system of record, which team's roadmap you are now on, and what breaks when any of it changes.

Executives who cannot picture this consistently underestimate delivery by a factor that ruins roadmaps — and, more damagingly, cannot tell the difference between a project that is late and a project that is impossible.

This module gives you the picture. You will not build anything. You will be able to ask the four or five questions that surface the real cost before you commit to a date.

4.1 The four layers

Every AI-enabled process, however it is marketed, decomposes into four kinds of work. You met these labels in Module 3; here they become an architecture.

Two observations that change how you read a proposal.

The cost is not where the attention is. In most enterprise deployments, the judgement layer is a small fraction of the build and the overwhelming share of the discussion. Movement and integration consume the schedule, because they touch systems you do not control.

Each layer fails differently, so each needs a different control. A rules failure announces itself. A movement failure is silent — the number is simply yesterday's, and everyone acts on it confidently. A judgement failure is worse still, because the output is fluent. Module 5 designs for this; here, note that "monitoring" is not one thing but four.

4.2 What an API actually is

An API is a contract between two systems: if you ask in exactly this form, I will answer in exactly that form. Nothing more mystical than that.

Three things executives should take from the definition, because each has appeared in the post-mortem of a late project:

"We have an API" and "we can integrate" are different claims. The first says a door exists. The second says the door is wide enough, opens often enough, and admits the data you actually need. The questions that distinguish them:

• What is in it? Systems frequently expose 20% of their data through an API and keep the interesting 80% inside.
• How often may we ask? Rate limits turn a five-minute job into an overnight one.
• Who authorises? Service accounts, permissions, and whether the API can see what a given user is allowed to see.
• What happens when it changes? Versioning and deprecation notice. Every integration is a standing maintenance obligation on someone else's release schedule.

Integration is a relationship, not a task. The right question to a vendor is never "do you integrate with SAP" — it is "which objects, in which direction, at what frequency, and what happened the last time SAP changed them."

Every boundary is a governance boundary too. Each hop where data leaves a system you control is a place where Module 6's residency, transfer and retention questions attach.

4.3 Tool use, and the direction that matters

Modern AI systems do not only produce text; they can be given the ability to call things. The model emits a structured request — "look up order 4471" — the surrounding system executes it against a real API, and the result comes back into the conversation. This is tool use, and it is what separates a chat interface from a system that does work.

The Model Context Protocol (MCP) standardises how tools are described and offered to a model, so that a capability built once can be exposed to different systems without bespoke glue each time. Treat it the way you would treat any interoperability standard: valuable because it reduces lock-in and integration cost, not because it is intelligent.

The design principle underneath is worth more than the technology, and it is the one to carry into every architecture review:

The model asks the pipeline for the number. The pipeline never asks the model whether one number is larger than another.

Direction is a decision. When a model calls a deterministic tool, you get the model's flexibility at the edges and the tool's exactness at the core — arithmetic stays arithmetic, policy stays policy, and the model handles the language around them. Invert it, and you have put a probabilistic component inside your load-bearing wall, with the reliability consequences Module 3 quantified.

A practical corollary for vendor conversations: ask which side of each boundary the decision is made on. "The agent checks eligibility" and "the agent asks the eligibility service" are different systems with the same sentence.

4.4 Retrieval, fine-tuning, or better instructions

Almost every "make it know our business" request resolves to one of three answers. Choosing correctly saves months.

The default is retrieval. It keeps the source of truth where it already is, produces citations — which matter enormously for both trust and Module 6's audit obligations — and updates the moment the underlying document does.

Retrieval quality, however, is mostly a content problem rather than an AI problem, and this is the finding that surprises teams most. If your policies live in six conflicting versions across three shared drives, retrieval will faithfully find the wrong one. The work is chunking, permissions, freshness and deduplication — unglamorous information management that no model fixes. Budget it explicitly, because it is usually the true critical path.

4.5 Where your data lives decides the architecture

Two distinctions carry most of the weight.

Systems of record versus systems of engagement. Your ERP, LIMS, EHR or core banking platform is a system of record: authoritative, change-controlled, slow to modify, and correctly protected by people whose job is to say no. Systems of engagement — portals, inboxes, chat — are where people meet the work. AI belongs, almost always, in the engagement layer reading from the record layer. Proposals that require writing into a system of record should be scoped as a different, slower project with different approvers, and they usually are not what the value depended on anyway.

Move the data, or move the computation. If data cannot leave a jurisdiction or an environment, you do not send it to a model — you bring a model to it. This is the point at which Module 6's residency obligations stop being a constraint on the design and become the design.

That produces a small deployment ladder:

The economics have shifted the calculus here. Because smaller open-weight models have become genuinely capable at narrow tasks, "run it yourself" is no longer synonymous with "accept much worse quality" — for a bounded job such as redacting identifiers or classifying a document type, a small local model is often the right answer on both cost and compliance. The rule of thumb: frontier models for open-ended judgement, small local models for narrow, high-volume, sensitive steps.

4.6 Build, buy, or assemble

Most build-versus-buy discussions omit the option that fits the largest number of enterprise cases.

• Buy a complete application when the process is standard and not a source of advantage. Payroll, expenses, service-desk deflection.
• Build only where the process itself is the advantage, and be honest that you are taking on a permanent maintenance obligation.
• Assemble — the missing third option — when you already own most of the pieces. The movement layer exists in your data platform. The rules live in systems of record. The integration points are already built for other purposes. What is missing is a judgement step and the governance around it.

Assembly is usually the fastest route to a working system, and it is under-proposed for a simple structural reason: nobody sells it to you. Module 3's bill-of-materials discipline is what reveals it — once the steps are labelled, you can see how many you already have.

4.7 The questions that surface the real cost

Five questions, in this order, applied to any proposal. They take twenty minutes and routinely move an estimate by a factor of two.

1. Which systems does the data pass through, and who owns each one? Ownership means a roadmap and a queue, not just a name.
2. What is the slowest hop? Batch windows and rate limits set your latency ceiling regardless of how fast the model is.
3. Where does data cross a boundary — vendor, jurisdiction, network? Each crossing is a governance item and a failure point.
4. What has to be written back, and who approves writes to that system? Read-only projects and write-enabled projects are different projects.
5. Which pieces do we already own? This is the assembly question, and it is the one nobody asks first.

Exercise — Draw your integration map

Time: 60 minutes. Produces the artefact for this module.

Take the workflow you labelled in Module 3 and draw it as an integration map.

1. Draw every system the data passes through, in order, left to right. Not conceptual boxes — the actual systems, by name.
2. Label each hop with its layer: movement, rules, integration, judgement.
3. On each hop, record: who owns it, whether an API exists, the frequency it supports, and the slowest window.
4. Circle every boundary crossing — vendor, jurisdiction, network.
5. Mark the deployment decision for each judgement step: vendor API, your tenancy, or local.
6. Underline what you already own.

Then answer one question in writing: what is the slowest hop, and does the value case survive it? If the answer is no, you have saved a quarter.

Self-check

1. A vendor says their product "integrates with your ERP." Name three questions that establish whether that is true in a way that matters.
2. Why does the direction of a tool call — model calling the service, versus service calling the model — change the reliability of the system?
3. A team proposes fine-tuning so the assistant "knows our current pricing." What is wrong, and what is the alternative?
4. Under what circumstances does a data residency obligation stop being a constraint and start being the architecture?
5. In your own estate, name one process where the assembly option is available and has not been proposed.

Further reading

• Model Context Protocol specification and documentation, 2024–.
• Anthropic, Writing Effective Tools for AI Agents, 2025.
• Martin Zinkevich, Rules of Machine Learning, Google, 2016 — Rules 2 and 4, on infrastructure before modelling.