Seven layers from the chip to the signature

Last week I argued that the wrapper around a model now shapes the outcome more than the model does. This week I want to name the layers, because the wrappers are going up and we need words for where they land. Last week's diagram had seven layers with placeholders above the bot; this is the second cut, and it replaces them. Software engineering settled the principle in 1972, when David Parnas published On the Criteria To Be Used in Decomposing Systems into Modules. He called it information hiding: an abstraction is useful to the exact degree that it hides complexity behind an interface the next layer can use without looking inside. A file system hides the disk. A network stack hides the wire. Programmers address files and sockets, and each layer of hiding let more people build more software for less. Wrapper builders are doing the same above the model, and the model, like the disk, stays at the bottom doing the work it is good at.

I have seen this shape before. Between 2012 and 2016 I led Project PACE for Aurizon Network, a research program with Brisbane optimisation firm Polymathian and the University of Newcastle to schedule maintenance across 2,670 km of the Central Queensland coal network. The maths ran on Gurobi, a commercial solver. Hand it a model and it finds the optimum faster than any human could. It has no idea what a train is.

Most of the effort in that program went into the layer above the solver: the model of the constraints. Which track segments could close together, how long a possession took, what the access undertakings required, what the crews could reach. The model took inputs a maintenance planner could read and returned outputs a planner could act on. Over all of it sat an objective written in the business's own terms. For PACE that was three competing goals: asset reliability, resource affordability and compliance with the network's obligations. Aurizon Network is a regulated, ring-fenced below-rail business. It does not sell coal, so its objective was track available for the miners' tonnes at a cost the regulator would allow. The supply-chain optimisation that followed had a bigger objective: more margin on each tonne at the customer, optimised from pit to port.

The solver never changed. The value came from the wrapper that turned a general engine into an answer a planner could use, in the language of a goal the business already had. The people building on language models are repeating that move, one layer at a time.

The Softwired seven-layer model

The OSI model names its seven layers for the job each one does, so an engineer can say "that is a transport problem" and be understood. I want the same for AI, so here is a seven-layer model of my own. Each layer hides the complexity of the one beneath it and offers one unit of work to the one above. The human scale rises with it: a chip, a model, a task, a team's workflow, a department's rules, an enterprise's objective, and at the top the organised system that creates value in an economy or a community at a scale that matters. The test for whether a layer is real is Parnas's: can the layer above use it without knowing how it works?

1. Infrastructure

Hides physics. Chips, data centres, electricity and water. Takes capital and power, returns compute by the hour. Examples: NVIDIA, the hyperscalers, the data-centre operators, the generators and utilities now signing their supply contracts. Most of what is written about the AI boom is written about this layer. It is the physical layer of the stack, and the only one where the barrier to entry is capital and power rather than knowledge.

2. Model

Hides compute. Tokens in, tokens out. Replaceable, and replaced every few months. Examples: any frontier or mid-tier model behind an API; Gurobi under PACE.

3. Agent

Hides the task. A model with tools, context, a scope and a point where it stops and asks. Takes a prompt and context, returns an artefact. Examples: a coding agent that opens a pull request; a bot that drafts a policy from a template and the firm's register; a clerk that reads an invoice and codes it. This is where last week's piece left off, and where most organisations are.

4. Coordination

Hides the workflow. Several agents with roles, hand-offs, an exception path and one place to stop the lot. Takes a work item, returns completed work. Examples: a Friday reporting cycle where one agent collects, one checks, one writes, and the layer knows the order and what done looks like; a recruitment pipeline from advert to shortlist; a month-end close. The sponsor above it receives the report at four o'clock.

5. Control

Hides permission and measurement. Takes an objective, returns the rules the layers below must obey and the evidence that they did. Examples: a budget per function; a usage policy; the one-page record per tool with an owner and its access; approval points; the two or three numbers a department reports to the board. This is where a department lives, and where shadow AI dies, because a tool with no entry here has no permission to run.

6. Value

Hides the trade-offs. The objective function in the organisation's own terms, and the risk appetite that bounds it. Every layer below inherits it, and every layer below is wrong if it optimises for anything else. Examples: margin per partner hour for a firm; network availability at an allowed cost for a regulated utility; tonnes at a margin, pit to port, for a coal supply chain; member retention for a sporting club. Aurizon Network wanted the track open for the miners' trains at a cost the regulator accepted, and the maintenance schedule was a means to that.

7. Accountability

Hides nothing. A named person signs the objective and owns the result. Last week I called this human purpose; accountability is its operational form. It is the only layer that cannot be a wrapper, because the whole point is that someone looks inside. Examples: the managing partner who signs the margin target; the executive who answers to the regulator; the board. This raises the question people keep asking me: can an AI system be accountable? On this model, no. Accountability is the property of being answerable to other people for a result, and a system cannot be answerable, only its owner can. That is a feature of the stack. It tells you where the humans have to stay.

Two rules follow from information hiding. Each layer speaks to its neighbours only in the neighbours' terms: Control hands Coordination a set of rules, and Value hands Control an objective. A layer that leaks the vocabulary of two layers down has failed as an abstraction. In the billing run below, a coordination layer that asked the partner for prompts would have failed that test, because the partner's unit of work is a pack to sign.

One firm, seven layers

Abstractions are easier to see in one place than in a list, so take a 300-person professional services firm at month end. The bills go out on time. The problem is what is on them: partners write off hours they never meant to, and narratives that read badly get queried.

Infrastructure and model. Somebody else's data centre, a mid-tier model behind an API. Finance has changed model vendor twice this year and nobody above noticed.

Agent. Reads one engagement's timesheet lines and the partner's notes, drafts the narrative, and stops to ask when hours exceed the quote. A partner still opens, reads and sends it.

Coordination. The billing run. Agents pull work in progress, draft narratives, check each against the engagement letter and assemble the pack. Disputed hours go to an exception queue with a human name on it. The partner gets a pack on Tuesday at nine with the exceptions on top, and never sees a prompt.

Control. Finance's rules, written once. Write-offs above five per cent need partner sign-off. A narrative reaches a client only with a partner's name on it. Every agent in the run is on the register. Two numbers go to the board: realised rate against standard, and invoice queries per hundred.

Value. Realised margin per partner hour, without a client complaint about an invoice. That second clause is the risk appetite, and it is why the control layer has the sign-off rule.

Accountability. The managing partner signs the objective, the finance director signs the rules, each partner signs each invoice. If the realised rate falls, three people know whose problem it is, and none of them is a model.

The same stack sits under PACE. Gurobi, on the university's servers, was the infrastructure and model layers. The constraint model was the agent and coordination layers, in a maintenance planner's terms. The access undertakings and network rules were the control layer. The three objectives were the value layer. The accountability layer never settled: nobody had been named to weigh reliability against cost against compliance, so a tool that produced schedules the planners could read never reached production planning.

Why this is the frontier labs' problem

The labs own layer 2, rent layer 1, and are reaching for layer 3. Information hiding says the value sits higher, because each layer up wraps more complexity into a form more people can use. A token means nothing to a CFO. A policy and a number do. I do not expect the labs to build layers 4 to 7 for you, because those layers are made of your workflow, your policies, your objective and your names, and the labs do not hold any of them. That is the weak point in a business priced per token: the better the engine gets, the more of the value moves to the layers the engine's maker cannot reach. It is also the whole case for the wrapper argument. A language model on its own is a solver without a constraint model. Each layer also has to hide the state below it, or the bill grows with every hand-off. That is next week's piece.

What the solver taught us

Three lessons from PACE carry straight across.

First, the engine is replaceable and the model of the constraints is the asset. I estimate we could have swapped Gurobi for another solver in a week; the constraint model took the better part of the program to build, because it held everything the planners knew. The same holds now. Most of Softwired's client work runs on mid-tier models, and the quality comes from the wrappers: the contracts, the checks, the context, the stop. When we have swapped a model under a working wrapper, the client has not noticed. When we have changed a contract or a check, the output has changed the same day.

Second, the objective function is the hardest part to settle. PACE's maths was sound and the tool still never reached production planning, because three objectives that pull against each other need a human to weigh them, and the organisation had not settled who that was. A value layer without a settled objective has the same problem at a larger scale. Agents will optimise whatever they are given, so the control layer's first check, before any agent runs, is whether the objective above it has an owner.

Third, abstraction stops where accountability starts. A wrapper can carry an objective, a budget, a policy and a stop. It cannot carry the accountability for choosing them. Somebody signs the maintenance plan. Somebody owns the margin. That is layer 7, and every layer below it has to report upward in plain words.

What this means if you are buying

Ask which layer a tool is. An agent is useful; a coordination layer with a real workflow and a real stop is worth more; a control layer with a policy and a measure is where the money is defended. Ask whose objective it serves and whether that objective is written down. Ask whether its inputs and outputs are in your people's terms or the vendor's. And keep a named person at layer 7 who reads the output and is held to it.

Limitations

This is a working model built from one optimisation program and two years of building agents for clients and for Softwired. The names are a first cut and will move. The billing firm is a composite. PACE's lessons come from a solver; the engine-and-wrapper parallel holds, and the maths does not carry across. The top two layers are claims about organisations, which the evidence from AI deployments has not yet tested at scale.

We use this stack with clients to decide which layer to build next, who owns it, and what number it reports. I would like it tested. If you have a better model, or a layer I have missed or misnamed, say so in the comments. If you are working out which layer to build next, book a call.