Chris M. / 17 August 2026 / Reviewed 17 August 2026

AI and Software Architecture Translation Guide

How modern AI systems are actually assembled, written for construction leaders, project managers and commercial teams who need to make decisions about them without becoming software engineers. This is a technical reference, not a policy or a vendor comparison: it answers how is it built and what do I ask a supplier, not what should our policy say and who signs it, which is a separate and ongoing piece of governance work for each organisation.

The six parts below are also published as their own pages, linked at the end of each section, for anyone who wants to bookmark or share one on its own. This page carries the complete guide in one place.

One part of this guide, the model landscape in part two, is a dated snapshot rather than a durable principle, and it says so at the point you reach it. Everything else describes how systems are put together and should hold for several years regardless of which specific models are current when you read it.

Part one: where AI belongs, and where code belongs

Almost every expensive mistake in an AI project comes from one decision made badly. Before anything else is designed, bought or built, ask whether the correct answer to a task can be written down as a rule, a formula or a database constraint. If it can, that task belongs to deterministic software: exact, repeatable, effectively free to run once it is written, and auditable line by line. If it cannot, because the task needs interpretation, ambiguity resolved, language understood or judgement exercised, that task belongs to an AI model, which costs money and time on every call and needs evidence behind its answers rather than trust alone.

Complexity is not the length of a task. It is the number of ways it can quietly go wrong. Long horizon, ambiguity, trade-offs, the amount of context needed and whether the system might need to self-correct all decide how much intelligence a task needs. A sixth factor, consequence, is separate: it decides how much control the task needs regardless of how intellectually simple it is. Counting a payment certificate is not complex. Getting it wrong is.

In practice the two tools work in sequence rather than in competition. A model reads messy input and proposes structured values. Code then checks those values against known project codes, valid ranges and mandatory fields, flagging anything that fails rather than accepting it silently. The model does the reading. The code does the enforcing. A useful test for any design review: ask whoever is proposing a system to point at the exact line where the model stops and the code starts. If they cannot draw that line, the system has not been designed, it has been prompted. Read the full part: where AI belongs, and where code belongs.

Part two: the model landscape, safeguards and access in 2026

This section is a dated market snapshot, correct as at 17 August 2026 and due for re-verification after 30 November 2026. Provider names, tiers and prices move on a scale of weeks; the durable pattern below is worth more than any specific figure in it.

Every major provider now ships a volume tier for high throughput work, a balanced tier for everyday drafting and comparison, and a frontier tier for genuinely hard problems, with a spread of more than forty times in list price between the cheapest and dearest tier shown below. The architectural decision that matters is not which model is smartest. It is which level of intelligence a given task actually justifies.

The other change through 2026 is that providers now separate what a model can do from what a given account is allowed to make it do, and gate the difference behind approval, including account security requirements with real deadlines and retention terms that differ by tier rather than only by provider. Anthropic's own announcement of Claude Opus 5 is one example: it describes safety classifiers that divert flagged high risk queries away from the frontier tier automatically. A significant amount of what gets discussed as available is also not: an announced model is not a shipped one, and a shipped model is not necessarily one your account, or your region, can actually use. Build against a tier, not a model name, so a delayed flagship is an inconvenience rather than a replan. Read the full part: the model landscape, safeguards and access in 2026.

Part three: under the bonnet, waiting and where data lives

A construction system spends most of its life waiting: for a database, for file storage, for an external API, for an AI service to respond. Node.js, the runtime behind a large share of modern application backends, lets an application keep working while those waits play out rather than standing still until one finishes. The useful idea is not literal parallelism. It is that waiting is not the same as working, and a well designed system does not stand still during a wait.

Underneath that runtime, relational and document data are not a choice between rigid and flexible; both need design, the difference is where the design effort sits. PostgreSQL's JSONB type lets a system keep identifiers, money and status in strict, controlled columns, where they can be validated and joined, while properties that vary by trade or product type sit in a flexible field that is still queryable in ordinary SQL.

Read the full part: under the bonnet, waiting and where data lives.

Part four: how a system finds the right record and cites it

Metadata, embeddings, vector search and retrieval augmented generation, RAG, are the machinery behind every credible claim that a system can answer questions about your own project information rather than about the internet in general. Retrieval finds the relevant records first, using metadata and permissions to decide what is even eligible, then supplies them to the model as evidence, so it answers from your project information and can cite exactly where each claim came from.

Vector similarity is not proof. Retrieval can miss relevant records and return irrelevant ones, and it will miss evidence living in an unindexed attachment, an uncaptioned photograph or a conversation that only happened verbally. A retrieval system produces records that may support a position; it does not produce an analysis on its own, and high consequence outputs need their sources preserved, their uncertainty surfaced, and a human in the loop before anything is relied upon. Read the full part: how a system finds the right record and cites it.

Part five: agents, tools and orchestration

An agent is an AI driven workflow that can decide which steps or tools to use while pursuing a goal. A tool is a defined capability. MCP, the Model Context Protocol, is a standard way for AI applications to discover and invoke the capabilities a server chooses to expose, and it does not itself grant access: the server, the permissions and the host application decide what a model is actually allowed to see or do.

Zoomed out, intelligence is one package within a wider system: an interface, an application layer, an orchestrator, a model router, a data layer, retrieval, human control and finally action and evidence, eight layers in total. Most failures are not model failures. They are failures in the layers around it: permissions applied inconsistently, everything routed to one model regardless of task, records that were never indexed, or approval reduced to a tick box with no evidence behind it. Read the full part: agents, tools and orchestration.

Part six: putting it to work

The working output of the whole guide is a routing matrix, deliberately written without naming a single model so it survives the next release cycle: a fixed rule goes to code, high volume extraction goes to a volume model with deterministic validation, general drafting goes to a balanced model, complex multi document reasoning goes to a frontier model with retrieval and human review, autonomous action goes to an agent with tightly scoped tools and approvals, and anything bearing on safety, payment or a formal notice goes through an evidence led workflow with a competent human decision that is never automated end to end.

Applied once, end to end, to a single site record: capture through an interface people already use, structure into a controlled record, an AI model proposes values, deterministic code validates them, retrieval finds related records with permissions applied first, a stronger model reasons only where genuinely needed, a human reviews anything consequential, an approved action updates the register, and the output retains links to its sources and logs what happened. Only three of those nine stages involve a model at all. The rest is capture, validation, control and evidence, and that ratio is what a defensible system actually looks like.

Building this starts with capture and deterministic validation, both unglamorous and both decisive, before routing across model tiers, retrieval and any of the controls that depend on knowing how much a wrong answer would cost. The most common sequencing error is starting with the most impressive part instead of the first one. Read the full part: putting it to work: routing, a worked example, where to start.

What this guide is built on

This edition consolidates earlier internal drafts, corrects technical claims that did not hold up under scrutiny, and updates the model references against provider release materials and documentation for Anthropic, OpenAI and Google, together with independent reporting, as at August 2026. Product names, tiers, availability and prices change on a scale of weeks; re-verify before any external use, particularly anything in part two.

The Model Context Protocol's specification revision dated 28 July 2026 introduced a stateless protocol core, an extensions framework and authorisation hardening, emphasising access control, user visibility and a human's ability to deny sensitive tool invocations. RICS' Responsible use of artificial intelligence in surveying practice, first edition, took effect 9 March 2026 and is mandatory for members and regulated firms worldwide where AI use has a material impact on service delivery.

UK data protection requirements around meaningful human involvement in automated decision making apply to decisions about individuals based on personal data. This guide is not legal, contractual or professional advice, and it is not a procurement recommendation. Take specific advice on regulatory scope for your own organisation.

This guide may be circulated internally and shared externally in full and unaltered. If a section is extracted or reformatted on its own, the model snapshot caveat in part two should travel with it.

Intelligence is one package. The system is the project. If this guide is doing its job, it has replaced one question with another: not what can this technology do, but what is the cheapest, safest and most reliable architecture that produces the required outcome and the evidence to stand behind it. That is a question construction professionals are already extremely good at answering about any package on any project. If you would rather work through it against your own business than start from a blank page, AI Metric runs this exercise with contractors and consultants directly.