What is a chain of events architecture?

A system built as a sequence of discrete, recurring events rather than as a conversation with a model. A message arrives, a payment clears, a document lands, a call ends. Each event has deterministic code that owns what happens next, its own memory of previous occurrences of that same event, and where judgement is needed, a small model tuned for that one job.

Why would small tuned models beat a large general model in an operating system?

Because an operating system event is not open-ended. It has the same shape every time, so a model specialised for it does not need to be told what the job is on each occurrence. A general model pays to rebuild context every time, in latency and in tokens, and an operating system is nothing but recurring events, so that cost is multiplied by everything the system does.

Is this an argument against large language models?

No. It is an argument about placement. A general model is the right tool for the open-ended and the unexpected, which is exactly what it should be kept for: the long tail of events that no specialist covers. The claim is narrower, that for the recurring core of a system, a specialist with memory wins on the axes an operating system is judged by.

What does memory mean in this context?

Per-event state that persists between occurrences, so the hundredth time an event fires the system knows what happened the previous ninety-nine times. That is different from a long context window, which re-reads history on every request and pays for it every time. The distinction between a store you write to and a context you refill is the whole point.

Why is fine tuning viable now when it was not before?

Because the economics changed. Low-rank adaptation and per-token training pricing brought the cost of adapting a model down to something a single function can justify, which is what makes a per-event specialist sensible rather than extravagant. When adapting a model cost as much as a project, one general model for everything was the only rational choice.

What is the downside of many small models?

Operational burden, and it is real. Every specialist is a thing to version, monitor, evaluate and retrain, and a fleet of them is a fleet of ways to drift quietly. A single general model has one of each of those problems. So an event only earns its own model when it is frequent enough and stable enough to repay that cost, and most events are not.

How do I know which events deserve a specialist?

Frequency and stability. If an event fires constantly and its shape has not changed in six months, it is a candidate. If it fires rarely, or the definition of a good outcome keeps moving, leave it with the general model. Start by instrumenting what your system actually does most often, because the answer is usually less interesting and more repetitive than anyone expects.

A chain of events beats one big model

A second position paper, and the one we would most want argued with.

The prevailing picture of an AI operating system is a large language model sitting in the middle, taking requests in natural language and reaching out into applications to satisfy them. Everything is a conversation, and the model is the thing that understands.

We think that is the wrong shape, and that the systems which end up winning inside specific functions will look almost nothing like it.

An operating system is not a conversation. It is a chain of events.

A message arrives. A payment clears. A call ends. A document lands in a folder. A threshold is crossed. Each of those is narrow, recurring, and shaped exactly the same way every time it happens. That is a completely different problem from an open-ended request, and it rewards a completely different architecture: deterministic control flow, a memory that belongs to the event, and where judgement is genuinely needed, a small model tuned for that one job.

One event, one specialist

1. The unit is the event, not the request

Everything follows from taking this seriously.

An open-ended request is unbounded. You cannot enumerate what somebody might ask, so you need something general, and a large model is the right answer.

An operating system event is the opposite. Its shape is known in advance. The hundredth invoice that arrives looks like the ninety-ninth. The decision to be made about it is the same decision. The set of possible outcomes was fixed when the system was designed.

That has three consequences, and each of them is an argument against putting a general model in the middle.

You can write the control flow down. If you know the shape, you know the branches, and branches belong in code, where they are fast, free, testable and identical every time. We made this case at length reading TypeSafe's System One: if you could draw the steps on a whiteboard before you started, you should not pay a model to rediscover them on every occurrence.

You can give the event a memory. Not a context window that gets refilled, an actual store that persists between occurrences and is written to by them.

You can tune for it. A model that only ever sees one kind of decision can be small, and small means fast and cheap, which at operating system event rates is the difference between viable and not.

2. Memory that belongs to the event

This is the part of the argument that we think is most often missed, so it is worth separating from the rest.

A long context window and a memory are not the same thing, and treating them as interchangeable is how systems end up paying enormous amounts to be mediocre.

A context window is refilled. Every time the event fires, the history is gathered, serialised and sent, and you pay for all of it again in latency and in tokens. The model learns nothing between occurrences. The hundredth time is exactly as expensive as the first and no better informed.

A memory is written to. The hundredth occurrence starts with what the previous ninety-nine established. The cost does not grow with history, and the quality does.

We have argued this from the biology side in why the brain keeps two memory systems and from the systems side in read and write memory. The consistent finding is that a fast store over the present and a slow consolidated one over history are different mechanisms doing different jobs, and collapsing them destroys information.

An event chain gets this almost for free, because the natural scope of the memory is obvious: it belongs to the event type. What usually happens with this supplier. What this customer normally asks for. Which of these alerts turned out to matter. That is a small, bounded, high-value store, and it is unreachable if your architecture is one enormous context shared by everything.

3. The cost that decides it

What gets paid for, every time

The economics are what make this an engineering argument rather than a taste.

An operating system does not handle one event. It handles the same event constantly. So any per-event cost is multiplied by the entire operation of the system, and a difference that looks negligible on a single request becomes the whole bill.

A general model asked to handle a recurring event pays, every single time, for: transmitting the context, reading it, working out what kind of situation this is, and deciding. The first three of those are rediscovery of something that was already known.

A specialist pays for the last one.

At operating system rates, there is also a latency argument that is arguably more binding than cost, and we set it out in AI implementation is an architecture decision: if a person is waiting, you have seconds, and a general model thinking at length does not fit. Events in a working system are usually in somebody's way.

The newer model classes make this concrete rather than theoretical. The models we covered in TypeSafe's System One and CLM-8B return structured decisions in around a tenth of a second precisely because they do not generate text. That is the shape a per-event specialist wants.

4. Why this is possible now and was not before

The obvious objection to per-event specialists used to be decisive: adapting a model cost more than the function was worth, so one general model for everything was the only rational choice.

That changed. Low-rank adaptation and per-token training pricing brought the cost of adapting a model down to something a single function can justify, which is the shift we wrote about in Tinker, Inkling and the return of fine tuning. Thinking Machines Lab's bet there was that models an organisation can adapt will beat one size fits all models, and the chain of events argument is what that bet looks like when you push it into system architecture rather than treating it as a training convenience.

The second enabling change is the one in CLM-8B and language model shape: distilling a capability into a different, narrower model shape is now routine. A specialist does not have to be trained from nothing. It can be a compressed version of something general, shaped for one job.

5. Where we think this is wrong, or at least expensive

When an event earns a specialist

A fleet of specialists is an operational burden that a single model does not have, and pretending otherwise would be dishonest.

Every specialist is something to version, evaluate, monitor and retrain. Twenty of them is twenty ways for behaviour to drift quietly, twenty evaluation sets to maintain, twenty things that were fine until the upstream data changed. One general model has one of each of those problems. That is a real advantage and it is why the prevailing picture is prevailing.

So the position we would actually defend is narrower than the headline:

An event earns its own model when it is frequent enough and stable enough to repay the cost of maintaining one. Frequent, because the saving is per occurrence. Stable, because if the definition of a good outcome keeps moving you will be retraining forever.

Most events do not clear that bar. They should stay with the general model, which is the correct tool for the long tail and for anything genuinely unexpected. The arrangement we are arguing for is a chain of events where the busy, stable core has specialists and everything else falls through to a generalist.

That fallback is not a concession, it is load bearing. A system of narrow models with no generalist behind them fails badly on the first thing nobody anticipated, and something nobody anticipated is guaranteed.

Two more honest problems.

Routing becomes a component. Deciding which specialist an event belongs to is itself a decision that can be wrong, and a misrouted event handled confidently by the wrong specialist is worse than one handled clumsily by a generalist.

Evaluation gets harder, not easier. Twenty small models are twenty things to prove are still working. This is the same burden we described in when the verifier moves inside the model: the check has to live somewhere, and distributing the intelligence distributes the obligation to verify it.

6. What this predicts

If the argument is right, some things should be observable over the next few years.

Vertical systems should outperform general assistants inside their vertical, by margins that look surprising given the relative size of the models. Not because the small model is smarter, but because it is not rediscovering the domain on every request.

The winning products should look unglamorous. Mostly ordinary software, with models appearing at specific points rather than as the interface.

Cost per completed task should diverge sharply between architectures that look similar from the outside, which is the measurement we keep insisting on in what tokens actually cost and small language models.

And the general assistants should keep winning at everything that is genuinely open-ended, which is most of what people find impressive and not much of what a business runs on.

This is the architecture behind Nure AI OS, which is built as a chain of events over a customer record rather than as a chat interface with tools bolted to it. We would rather state that openly than have it read as a coincidence.

7. What would change our mind

If context windows get cheap enough that refilling stops mattering. The whole cost argument in section three assumes per-occurrence context is a real expense. If that goes to approximately zero, the specialist's advantage narrows to latency alone.

If general models get fast enough to fit the latency budget. The models are getting faster and the budget is not moving. If a general model can answer inside the window a specialist currently owns, the second pillar goes.

If maintaining specialists turns out to be worse than we think. We have argued the burden is manageable for a small number of high-frequency events. If in practice it grows superlinearly, the honest answer is one model and a good retrieval layer.

This is an argument, not a result. We have not published a benchmark comparing the two architectures on the same workload, and we should. That is the experiment this note is really asking for, and if somebody runs it before we do, we will link to it here.

If you are designing a system around a model and are not sure whether it should be one general one or several narrow ones, talk to us, or see how we build systems for businesses.

8. Sources

This is a position paper and the argument is ours. What follows is the published work the load-bearing claims rest on, so the parts that are not opinion can be checked separately from the parts that are.

Hu et al, LoRA: Low-Rank Adaptation of Large Language Models, 2021, the result underneath the claim in section 5 that adapting a model for one event is now cheap enough to be worth doing.
Lewis et al, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020, on grounding generation in a store rather than in a context window.
McClelland, McNaughton and O'Reilly, Why there are complementary learning systems in the hippocampus and neocortex, Psychological Review, 1995, the two-store argument section 2 borrows from, read at length in why the brain keeps two memory systems.
Our own read and write memory and TypeSafe's System One: code orchestrates, the two notes this paper most directly builds on.

This note sits in our Research track, alongside the operations, foundation models and system design threads. The full library is at Research.