Software Engineering on AIBussin — AI applications, systems and books

What Context Means

Wed, 23 Sep 2026 05:00:01 +0100

Consider a concrete evening. A developer asks a coding agent to fix a failing test. The typed message is eleven words long: “the checkout test fails after my last commit, please fix it.”

Behind those eleven words sits an organisation of information enormously larger than the request. The repository holds hundreds of thousands of lines of code. The version control history holds the last commit and every commit before it. The continuous integration log holds the actual failure output. The open editor holds the file the developer was viewing. The agent’s working directory holds shell history, environment variables, and configuration. Earlier in the session, the developer pasted an error trace, the agent ran two searches, and a linter produced three warnings nobody has read yet.

Beyond the Chat Box

Mon, 14 Sep 2026 05:00:01 +0100

Part 1 — Where You Stand

Before any of this can be built, it is worth being exact about where you are standing. Intelligence is no longer the scarce component. What is scarce is everything around it: deciding which work should never be stochastic, knowing what a model call costs, noticing that a person’s review decays as the model improves, and measuring a system whose output changes between runs.

These eight chapters make that case: the position a commodity technology erodes, the rule that keeps deterministic work deterministic, where this era’s training data came from, why human review becomes a rubber stamp, what intelligence actually costs, how to measure a stochastic system, and why projects still are not finishing.

What Remembering Means

Mon, 14 Sep 2026 05:00:01 +0100

A small team spends a week arguing about where to keep its event log.

They start with SQLite. It works at first, then slows to a crawl once several writers hit it at once. So they move the event store to PostgreSQL and write down why. Within a month nobody thinks about it any more. It is just how the system works.

A few months later, a new contributor asks the team’s AI assistant to scaffold a second service, with its own event log.

The Measurement Instrument

Wed, 23 Sep 2026 05:00:02 +0100

Imagine a developer debugging a slow, expensive coding agent. The visible transcript shows eight user messages and eight assistant replies. It looks modest. Then they enable request logging at the harness layer and discover that the eighth model invocation carried tens of thousands of tokens: the project instructions re-sent for the eighth time, tool definitions for tools never called in this session, two file reads that overlap almost entirely, and a history that includes four failed tool calls and their stack traces in full. The user typed a few hundred words in the whole session. The model received a novella.

Never Stand in Front of the Steamroller

Mon, 14 Sep 2026 05:00:02 +0100

Part 1 — Where You Stand

The plain version

The historical premise of this chapter is not controversial: machines have displaced codified parts of skilled work before. The inference for AI — which parts are now exposed, how fast the boundary moves, and where durable human responsibility remains — is the claim this chapter has to earn.

“Computer” was a job title before it was a machine: rooms of people did calculations by hand for engineers, observatories and space programs. Typesetters set newspapers line by line, first by hand and later on hot-metal machines, until photocomposition and then desktop publishing took the trade. Keypunch operators turned programs and data into stacks of punched cards. Typing pools produced every letter an office sent. Each of those was skilled work, done by people who were good at it and some who were superb. None of that skill protected the job once a machine could do the codified part.

The Measurement Instrument

Mon, 14 Sep 2026 05:00:02 +0100

Chapter 1 ended with a test. Does the past change what the system does now, and does it change it for the better?

That is easy to state and hard to run. This chapter builds the thing that runs it.

Two words will recur for the rest of the book, and they must not blur together. The memory system is the thing that remembers. The instrument is the apparatus that decides whether it does. They are separate products, and this book builds both.

The Context You Didn't Type

Wed, 23 Sep 2026 05:00:03 +0100

The mental model most users carry looks like this:

user
 ↓
model
 ↓
answer

A message goes in, intelligence happens, an answer comes out. Everything in the previous chapter says this picture is false, but the previous chapter showed the falsity as accounting tables. This chapter shows it as machinery. Behind a production assistant stands a runtime that assembles a layered stack of instructions, definitions, state, history, and observations, and the user’s message arrives near the bottom of that stack, not the top of it.

If There's Any Doubt, It's Deterministic

Mon, 14 Sep 2026 05:00:03 +0100

Part 1 — Where You Stand

Seven operations, one of them intelligent

Take the paragraph review from Chapter 1 and write down everything the process actually has to do. Not the prompt — the process.

Select the paragraph to review.
Decide whether it has changed since the last review.
Decide whether there is budget left for a call.
Identify claims in the paragraph that need supporting evidence.
Extract the flagged sentence and its position.
Check that a cited source resolves and that its year matches the bibliography.
Decide whether to write the change to the file.

Six of those have exactly one correct answer, computable without a model. Selection is an index lookup and change detection is a hash comparison. Budget is arithmetic; extraction is parsing. Source checking resolves the request and compares it against the bibliography. The write decision evaluates policy.

The RAG Baseline

Mon, 14 Sep 2026 05:00:03 +0100

The simplest answer to the memory problem is also the one every more elaborate system has to beat: keep the project history, retrieve the parts that look relevant, and let a capable model read them.

That approach already has many of the ingredients people casually call memory. The past is retained. A query selects evidence from it. A reader interprets that evidence in the context of the present task. If the resulting behaviour improves because the right part of the past was recovered, the system has done something useful without maintaining a separate persistent account of what the project believes, what changed, or what should be remembered next.

The Context Window Is a Budget

Wed, 23 Sep 2026 05:00:04 +0100

Chapter 3 ended with an observation: every hidden layer costs something. A team running a coding agent on a model with a million-token window read that sentence and shrugged. Their sessions rarely passed 150,000 tokens. Nothing was being truncated, nothing was overflowing, and the window, they reasoned, had settled the matter. Then two things happened. First, a long debugging session died at turn eleven with the model stopping mid-repair, not because the input had crossed a million tokens but because the input plus the output the model still needed no longer fit together. Second, the invoice arrived, and the “plenty of headroom” sessions turned out to be the most expensive ones they had ever run. The window had not settled anything. It had merely set the outer wall of a much smaller room they were actually living in.

From Retrieval to Persistent Understanding

Mon, 14 Sep 2026 05:00:04 +0100

Chapter 3 built the strongest conventional retrieval the book could assemble, and left it standing. That result constrains this chapter before it starts.

The usual argument for structured memory goes: retrieval finds text, but it does not understand it. About the system Chapter 3 actually built, that is simply false. A hybrid retriever, a cross-encoder reranker, and a capable reader already do a great deal of interpreting.

Watch what that reader does. It tells proposals from decisions when the passages allow it. It follows rationale across artifacts. It abstains when the evidence runs out.

Scrum Built the Training Set

Mon, 14 Sep 2026 05:00:04 +0100

Part 1 — Where You Stand

Why checkable work became unusually favorable terrain

An uncomfortable piece of bookkeeping

Software engineering became an unusually fertile early target for language-model automation. The usual explanation is that code is logical and therefore tractable for a machine.

That explanation points at only part of what made software favorable. The account this chapter defends is about the surrounding work records and checks.

Over decades, software teams increasingly worked through issue trackers, version control, code review, automated tests, and iterative planning methods. Not every team used Scrum, and none of these practices guarantees the others, but together they often left behind unusually structured records:

More Is Not Better

Wed, 23 Sep 2026 05:00:05 +0100

The seductive assumption runs like this. Useful information is good. The model has spare capacity. Therefore adding more potentially useful information should be better, or at worst harmless. Teams act on it constantly: the whole repository goes into the window just in case, every retrieved document is kept because retrieval must have returned it for a reason, history is never truncated because something old might matter. The budget chapter showed this costs money and headroom. This chapter shows it costs something more fundamental. Past a point, added context does not merely cost. It injures.

Meat Proxy

Mon, 14 Sep 2026 05:00:05 +0100

Part 1 — Where You Stand

Review degrades because the system succeeds

Ten weeks

Week one, the model drafts a paragraph review and you read every line of it. You disagree with two of its four flags, check a source yourself, rewrite one sentence. The whole thing takes twenty minutes and you feel you have earned the output.

Week three, the reviews have been good. You read them properly but you stop re-checking the sources it says it checked. Nothing bad happens.

Pathways Through Memory

Mon, 14 Sep 2026 05:00:05 +0100

Chapter 4 set out to give the system a map. Instead of reconstructing meaning from raw passages at every query, it keeps interpretation: entities, relationships, claims, communities, each traceable back to the artifact it came from. Whether that map pays for itself is Chapter 4’s own question and Chapter 4’s own experiment; nothing here assumes its verdict.

This chapter asks a question that arises either way. Suppose the map exists. A map is a structure to search, but associative recall suggests a different mechanism: one memory evokes another, which evokes another, until useful evidence appears several steps from the original cue.

Order Changes Meaning

Wed, 23 Sep 2026 05:00:06 +0100

A harness team ships a minor upgrade. Nothing is added to the context and nothing is removed. The release notes mention only a rendering change: tool results now appear above the project rules instead of below them, so that fresh observations sit closer to the current request. Within a week, the team’s deployment-safety rule, which the agent obeyed for months, starts getting violated. Nobody changed the rule. Nobody changed the model. The information in every bundle is byte-identical to last week’s. Only the arrangement changed, and the behaviour changed with it.

The Memory Nexus

Sat, 19 Sep 2026 05:00:06 +0100

Chapters 3 through 5 leave the system with an embarrassment of options. Chapter 3 built hybrid retrieval over raw history with reranking. Chapter 4 added a persistent derived graph with several query modes. Chapter 5 added cue-conditioned associative propagation over that graph. Each chapter earned its mechanism conditionally, and each left the cheaper layers available underneath. The question none of them answers is the one a deployed system meets first:

The Price of Intelligence

Mon, 14 Sep 2026 05:00:06 +0100

Part 1 — Where You Stand

The invoice nobody runs at prototype time

The paragraph review from Chapter 1 costs about 1,200 tokens in and 400 out. At prototype scale that is a rounding error, and it is why nobody computes the next four numbers.

A manuscript has 3,000 paragraphs. That is one full pass.

The review is not run once. Every edit invalidates the review of the paragraph it touched, and a careful author edits most paragraphs four or five times.

Not All Tokens Are Equal

Wed, 23 Sep 2026 05:00:07 +0100

A coding session under capacity pressure holds six items: a project safety rule, never modify production migrations without explicit approval; a test summary, 917 passed, 3 failed; a compiler log of 18,000 tokens; an architecture decision, PostgreSQL is required for this event-store workload; the contents of a source file; and an abandoned hypothesis, maybe the serializer is corrupting timestamps.

Pressure arrives, and the harness must yield tokens. The uniform policies on offer are all wrong in different ways. Summarise everything, and the safety rule becomes “be careful with migrations,” which no longer forbids anything. Delete the oldest material, and the architecture decision vanishes while yesterday’s abandoned hypothesis survives on recency. Truncate from the middle, and the file contents go while the log stays. Keep everything, and the request fails at the window. Each policy treats the six items as interchangeable tokens. They are not interchangeable, and the differences between them are exactly what a retention policy needs to know.

Why

Sat, 19 Sep 2026 05:00:07 +0100

Chapters 3 through 6 leave the system with a working pipeline and an uncomfortable surplus. Chapter 3 retrieves raw history. Chapter 4 derives a persistent graph from it. Chapter 5 propagates activation across that graph. Chapter 6 chooses between these mechanisms. A candidate memory reaches the reader, the reader writes an answer, and the answer contains claims about the project. This chapter asks the book’s third question — why did we decide or believe this? — in the form the pipeline forces:

Intelligence in the Wrong Direction

Mon, 14 Sep 2026 05:00:07 +0100

Part 1 — Where You Stand

Capability without an objective is magnitude without direction

The thing the marketing does not cover

Every vendor will sell you more capability. None of them can tell you whether that capability moves your process toward its objective without a measurement you supply.

A stronger model can execute the wrong objective more effectively just as it can execute the right one more effectively. Capability alone does not tell you whether the gap between what you wanted and what you got narrowed or widened. That is an empirical question.

Make the Window Bigger

Wed, 23 Sep 2026 05:00:08 +0100

Seven chapters have treated the model as fixed ground and asked how the surrounding system should manage information against it. The natural objection has been waiting since Chapter 4: if context is scarce and difficult to manage, why not simply make the window much larger? A team that moves its agent onto a million-token model watches several selection problems relax at once. Histories that needed pruning now fit. Files that needed triage can all be included. The compaction schedule gets quieter. For a while, context engineering looks like a stopgap awaiting cheaper capacity.

Is It Still True?

Mon, 14 Sep 2026 05:00:08 +0100

The same events, a different story

Consider three remembered events from the migration history:

A = benchmark detects SQLite contention
B = team decides to adopt PostgreSQL
C = PostgreSQL deployment completes

As an unordered set, {A, B, C}, the system knows all three happened.

As a trajectory, A → B → C, it knows something stronger. The benchmark preceded the decision, and the decision preceded the deployment.

Now hold the contents constant and change only the order, to B → A → C. Nothing was added. Nothing was removed.

Where Are the Finished Projects?

Mon, 14 Sep 2026 05:00:08 +0100

Part 1 — Where You Stand

The tireless coworker

Imagine you are given a colleague with the properties the industry has been describing for nearly four years.

They never tire. They work through the night and the weekend. They have read essentially everything and can recall it instantly. They write code faster than you can read it, and they will take on the tedious parts you have been avoiding since March.

Reuse Before Recompute

Wed, 23 Sep 2026 05:00:09 +0100

A team running a long debugging session finally acts on what the Chapter 2 instrument showed. Their traces show 20,000 tokens of duplicate file reads and obsolete tool output, so they add a cleanup pass that strips the duplicates before every request. Token counts fall by a sixth. The next invoice rises. Latency does not improve either. Nothing about the model changed and nothing about the task changed. The cleanup was real, the savings were arithmetic, and the bill disagrees, because the bill never measured tokens. It measured computation, and the cleanup destroyed the reuse that had been quietly subsidising every turn.

One Runtime, Many Windows

Mon, 14 Sep 2026 05:00:09 +0100

Part 2 — Get the Model Out of the Chat Box

A chat window is an interface with a person inside the loop doing the integration. This part takes the process out of it and gives the work somewhere else to live.

That happens in stages. The work needs a durable identity and a record that survives the interface closing. The model underneath has to be replaceable, because it will be replaced. A model call has to become a recorded process event rather than a string. That call then has to survive a change of provider dialect, its usage numbers have to mean something before anyone does arithmetic on them, and finally a successful call has to stop being mistaken for finished work.

What Did We Leave Unfinished?

Mon, 14 Sep 2026 05:00:09 +0100

Chapter 8 left the system with a way to maintain belief through time. That system is a good historian. This chapter shows where it is a poor colleague: it can reconstruct the past, but it cannot yet tell a closed chapter from an open obligation.

The migration is finished. The work is not.

Extend the running migration history past the July decision:

Thursday 11 July, adr-007:
Decision: move the event store to PostgreSQL.

Monday 15 July, commit-112:
On the migration branch, application writes use PostgreSQL in staging.
Production still uses SQLite.

Wednesday 17 July, session-051:
"Importer is green on PostgreSQL. Backups still target
SQLite — need to move those before release."

In the canonical history this opens intent-401, which stands open at the 23 August cut and completes with commit-118 on 27 August, three days before release-024 ships on 30 August.

Remove What No Longer Matters

Wed, 23 Sep 2026 05:00:10 +0100

Nine chapters have observed, classified, measured, ordered, priced, and architected around context without once deleting anything. That restraint ends here, and it should end nervously. A team ships an automatic cleanup pass over its coding agent’s history: exact-duplicate tool outputs go, failed calls older than four turns go, anything the model flags as done goes. Token counts fall by a third. Two weeks later a migration guardrail the team believed was load-bearing starts failing silently. The deleted material contained the only record of a constraint the project file never stated, a decision reached mid-session and never written anywhere else. Nobody summarised it away. Nobody rewrote it. It was simply removed, by a rule that could not tell a redundant copy from a unique original.

A Revolver, Not a Foundation

Mon, 14 Sep 2026 05:00:10 +0100

Part 2 — Get the Model Out of the Chat Box

The model will change; the frame should survive it

The book you could write better next year

Write a book with AI this year and you will be able to write the same book better next year. And better again the year after. The same is true of the code, the research synthesis, the review process, the classifier — anything where a model does part of the work.

What Matters Right Now?

Mon, 14 Sep 2026 05:00:10 +0100

Chapter 9 finished the first arc. Seven layers now stand between raw history and an answer: retrieval, a persistent graph, associative pathways, routing, support lineage, temporal validity, open-loop status. Each was introduced against a specific failure class, with some already bounded or conditional by its own experiment. None has yet been asked the question that decides whether the accumulated machinery was worth building.

A context window is small and history is not. For every execution, something chooses which fraction of the past the model is allowed to see. So far that choice has been made by one mechanism: similarity to the words of the request. The enrichment of Chapters 4 to 9 sits behind that gate, but query-only similarity cannot condition selection on the work now being done.

Compression Is Loss

Wed, 23 Sep 2026 05:00:11 +0100

An agent has accumulated a working past: an architecture decision at 500 tokens, an unresolved bug history at 4,000, three failed approaches at 8,000, tool observations at 20,000, the current implementation at 6,000. Chapter 10 does its honest work. Duplicates go, proven-superseded observations go, failed-input bulk goes with residues kept. Roughly 13,000 tokens leave. Twenty-five thousand remain, and every token of them matters in the sense this book has defined: some future computation may need it, and no rung of the evidence ladder licenses deletion. The bundle still does not fit the session ahead. Nothing left can disappear. Everything left cannot stay verbatim. That is where this chapter begins, at the exact point where deletion stops working.

Consequences Nobody Wrote Down

Mon, 14 Sep 2026 05:00:11 +0100

Chapter 9 handles work the history states: promises, assignments, follow-ups with an established expectation behind them. This chapter pushes Question 5 past conventional task tracking, to consequences nobody wrote down. The migration broke assumptions encoded in fixtures, documentation, and configuration that no session mentions. A memory that tracks only stated intentions will report the open list as empty while the project quietly rots. Whether anything can be done about that — reliably, without inventing obligations — is treated here as a difficult hypothesis, not a capability.

The Smallest Useful Model Call

Mon, 14 Sep 2026 05:00:11 +0100

Part 2 — Get the Model Out of the Chat Box

The smallest working call

CodeAI’s OpenCode cognition adapter, invoked directly without the recorded-call runtime, does the minimum well. Chapter 1 reached it through prompt(), which builds the CallSpec for you. Underneath, one CallSpec becomes one user message, the message goes out as an ordinary HTTP request, and a CallResult comes back:

adapter = OpenCodeCognitionAdapter(model="mimo-v2.5", protocol="chat_completions")
result = adapter.invoke(spec)  # one CallSpec in, one CallResult back
if result.status != "succeeded":
    raise RuntimeError(result.error)
review = result.raw_output

It keeps failure in its own channel instead of passing a diagnostic off as a review. It returns the usage with its source label alongside the convenient string. Those two habits already put it ahead of a great deal of production code.

Let Old Context Fade

Wed, 23 Sep 2026 05:00:12 +0100

A long session crosses its compaction threshold mid-investigation. The agent is halfway through a dependency migration: three candidate approaches tried, one rejected for a subtle version conflict, the current attempt half-applied, the exact error that killed the second attempt still visible three turns back. The compactor fires, because tokens crossed a number, and replaces 40,000 tokens of working history with a 2,000-token summary. The summary is fluent and mostly accurate. It records that an approach was rejected without recording which version conflict killed it. Six turns later the agent, unable to see the conflict, retries the rejected approach. The threshold did its job. The session did not survive it.

Does Better Context Change Behaviour?

Mon, 14 Sep 2026 05:00:12 +0100

Chapter 1 defined memory behaviourally. Remove the past, rerun the present task, and ask whether behaviour changed — and whether the change was an improvement.

Eleven chapters later, that test has never actually been run.

Chapters 3 to 11 built a pipeline — retrieval, structure, association, routing, lineage, temporal state, open loops, frames, derived consequences. Each stage was measured against ledgers of what the context contains.

Then an assembly experiment under a tight token budget produced an anomaly. At a 768-token budget, the assembled context holds required-evidence recall of only 0.72, yet the reader answers at 0.955 key-claim coverage — better than the full raw context at 0.879.

One Operation, Several Model APIs

Mon, 14 Sep 2026 05:00:12 +0100

Part 2 — Get the Model Out of the Chat Box

Choosing a model can change the whole wire contract

Right model, wrong dialect

Chapter 11’s second live run failed with an HTTP 500. The gateway, the model, and the credential were all right. The request was shaped for OpenCode’s Responses endpoint, and mimo-v2.5 is served on Chat Completions.

That looks like a configuration slip. It is a property of the ground you are building on.

Externalize the Working Set

Wed, 23 Sep 2026 05:00:13 +0100

Chapter 12 ended with an irreducible remainder: pinned exact spans, active dense episodes, compact views of the recent past, anchors of the deep past. Still resident, still costing capacity and cache stability. Consider what that remainder looks like in a concrete session. An agent halfway through a dependency migration holds five working objects: an architecture investigation at roughly 18,000 tokens, a benchmark report at 12,000, a compiler trace at 25,000, a design-alternatives note at 15,000, and a vendored API reference at 30,000. Progressive fidelity has done its honest work and the resident views are compact. The sum is still near 100,000 tokens of occupancy, and on most turns the model consults at most one of the five. The tiers answered how little of each object must be shown. None of them asked whether the object needs to be shown at all.

Token Counts Don't Add Up

Mon, 14 Sep 2026 05:00:13 +0100

Part 2 — Get the Model Out of the Chat Box

A field name is not a unit: normalize at the boundary

Every AI application ends up doing arithmetic on numbers a provider reported. It adds tokens into a budget, divides an invoice by them, compares two models on them, and routes work to whichever looks cheaper per token.

Those numbers arrive in fields with shared names: input_tokens, cached_tokens, reasoning_tokens. The shared names hide different rules. On one major API, cached input is counted inside input_tokens. On another, it is reported beside it. Add the two and the result is wrong even though every number in it is correct. Nothing crashes. The budget, the cost comparison and the routing decision are simply built on a sum that means nothing.

When the Frame Is Wrong

Mon, 14 Sep 2026 05:00:13 +0100

Chapter 12 ended with leverage. In the wrong-memory condition, success averages 0.042 across four tasks, with harmful actions on two.

In that controlled intervention, a layer deciding what the model may see can cause a harmful action — not merely fail to prevent one.

So the next question is when the system should trust its own framing that strongly.

Frame establishment here does not rest on classifier confidence. It is derived from explicit, temporal, provenance-preserving evidence relations. A reconciliation records that two representations relate, without ever asserting what is true.

Bring Back Only What You Need

Wed, 23 Sep 2026 05:00:14 +0100

Chapter 13 left the model holding a tidy live context and a shelf of external artifacts:

Incident 17 — lock-order inversion.
Evidence: artifact://incident-17

plus five more references of the same shape. Then the current task changes. The user asks why the deadlock appeared only under concurrent import. The incident artifact probably matters. So might the benchmark report, the migration plan, and the compiler run. The naive response is to load everything, which recreates within one turn the exact occupancy problem Chapter 13 solved. Leaving was only half the problem. Existence plus recoverability does not mean admission. This chapter decides what comes back.

A Successful Call Is Not Finished Work

Mon, 14 Sep 2026 05:00:14 +0100

Part 2 — Get the Model Out of the Chat Box

The model is not the process

An AI pipeline gets a response back, the response looks right, and something marks the work done. That step is where many AI-enabled processes quietly lose track of the truth.

A successful model call tells you the call worked. It does not tell you that anyone checked the output against what the task required, that the thing checked is the thing being used, that someone with standing agreed, or that the agreement was written down. Collapse those into one status field and “done” starts to mean “the model returned something plausible”.

Context Is a Bottleneck

Mon, 14 Sep 2026 05:00:14 +0100

Chapter 10 took selection as far as a frozen run has taken it: which memories the present work needs, admitted by an explicit, traceable policy at a fixed budget.

This chapter shows selection is not enough. Admission assumes the admitted memories fit. Increasingly they do not — and the Chapter 10 run puts a number on the shortfall.

The ledger oracle reaches perfect required-evidence recall on a mean of 587 estimated tokens. The best non-oracle Chapter 10 condition spends 1,161 to reach 0.902 recall. Rendered with the source headers and validity marks the reader actually sees, those become roughly 805 against 1,505. The gap survives rendering.

The Agent Writes Its Own Context

Wed, 23 Sep 2026 05:00:15 +0100

A debugging agent hits a failing migration test, guesses duplicated tenant identifiers as the cause, and records the guess in its progress file. Twenty turns later the window has reset. A fresh invocation reads the file, finds “Root cause: duplicated tenant IDs,” and plans the rest of its work around a fact nobody ever established. The test output that prompted the guess is long gone. The guess survived; the evidence did not. Nothing in Chapters 10 through 14 prevents this, because every mechanism so far assumed the candidate universe was given. It is not. The agent manufactures it as it works, and this chapter governs what it manufactures.

What Did the Model Actually See?

Mon, 14 Sep 2026 05:00:15 +0100

Part 3 — Give Intelligence a Runtime

A component with a contract still needs a world around it. This part builds that world out of the things that used to live in a person’s head and in the scrollback.

Each chapter makes one of them explicit and durable. What the model was allowed to see becomes a compiled, recorded input rather than an accumulated transcript. Working state becomes something another process can resume from instead of restarting blind. The provider’s response is preserved before anything interprets it, so a corrected reading can be applied later without asking the model again. Statements become claims that point at evidence, and decisions record what they relied on. Then the process is allowed to change something outside itself — and to observe the result rather than trust a report of it.

What Should Memory Keep?

Mon, 14 Sep 2026 05:00:15 +0100

Chapter 14 ended with an unexpectedly useful result. Once the candidate set was already good, elaborate assembly did not uncover a large reservoir of duplicate text waiting to be removed. Extractive deduplication saved only eighteen of 1,174 counted tokens on the frozen C5 bundles. The larger problem was competition: many individually defensible memories still occupied the same scarce working context, and the system had to decide what should continue to matter for the present task.

Memory Is a Context Source

Wed, 23 Sep 2026 05:00:16 +0100

The current request says, verbatim: “Do not modify the existing migration.” The admitted context contains months of migration history — previous plans, old decisions, the full archaeology of the project — alongside that one-sentence instruction. The model answers the history instead of obeying the instruction, and helpfully proposes the modification it was told not to make. Every remembered item was valid and correctly stored, retrieved, and rendered. The failure is none of those stages; the failure is that durable past information entered a computation it should never have influenced. That is the entire subject of this chapter, and restraint is its hardest case.

Learning From Experience

Mon, 14 Sep 2026 05:00:16 +0100

Chapter 15 asked how a long-lived memory system keeps accumulated history manageable without destroying what later work may still need. That remains memory management: the system changes which retained experiences are represented, available, or allowed to compete.

This chapter crosses a different boundary.

Suppose the system performs a migration, observes that it succeeded, and then changes what it will retrieve next time. Suppose it notices that the same sequence of checked actions has worked repeatedly and turns that sequence into a reusable method. The system is no longer only asking what the past contains or which part matters now.

Restart Is Not Resume

Mon, 14 Sep 2026 05:00:16 +0100

Part 3 — Give Intelligence a Runtime

Externalize working memory

When an AI process dies partway through, the usual fix is to restart it and re-run whatever did not finish. For a model call, that can mean paying for the same request twice. For an agent that sends email, opens tickets, charges a card or edits files, it can mean doing something twice that cannot be undone.

The capability you actually need is a different one:

Tools Produce Context

Wed, 23 Sep 2026 05:00:17 +0100

An agent starts a routine task with fifteen integrations connected: file tools, shell, search, web, database, issue tracker, chat, calendar, drive, deployment, monitoring. Before it reads a single project file, tens of thousands of tokens of capability descriptions have already entered its context — names, descriptions, schemas for operations it will never call. Then it runs one search, and 40,000 tokens of matches flood the window for a question answerable from twelve lines. The task fails twice before it begins: once at the price of knowing what it could do, once at the price of seeing what it did. Both prices were design choices. This chapter prices them.

Can Memory Be Trusted?

Mon, 14 Sep 2026 05:00:17 +0100

The book’s definition forces this chapter. Memory is when retained past experience changes present behaviour — and Chapters 12 and 13 showed that change running in both directions, including harmful actions under wrong memory and under some fallback conditions. If a line in retained history can change what the agent does today, then admitting that line is no longer harmless. The progression the book has been climbing ends one step further than behaviour:

Preserve Before You Interpret

Mon, 14 Sep 2026 05:00:17 +0100

Part 3 — Give Intelligence a Runtime

Raw output first

Every rule an AI application applies to a model’s response is an interpretation. Did generation finish? Is this valid JSON? Is this a refusal? How many tokens did it cost? What does the answer actually say? Those rules can turn out to be wrong: a provider adds a field, a parser misses a case, a failure shows up that nobody anticipated.

When Memory Becomes Documentation

Sun, 04 Oct 2026 14:32:00 +0100

The book’s definition forces a question it has not yet asked.

Memory is when retained past experience changes what the system does now.

Every mechanism so far has assumed that retained experience stays in the form it was stored. Retrieved history is retrieved. Derived state is rebuilt. Trust is re-evaluated on the way into context. But at some point a system stops treating an observation as evidence about the past and starts treating it as an instruction about the present. A remark becomes a rule. A workaround becomes a policy. A decision becomes a specification that future work must satisfy.

Representation Is Part of Context

Wed, 23 Sep 2026 05:00:18 +0100

Two bundles carry the same migration facts. The first is prose: the migration uses PostgreSQL, its identifier is 01947, it remains blocked by test suite A, and the team rejected the SQLite fallback after the staging incident. The second is a labelled record with the same four facts in named fields. Asked which identifier belongs to the unresolved migration, the model answers from the record and fumbles in the prose — the digits sit mid-sentence beside another number and bind to the wrong noun. Asked why the SQLite fallback was rejected, the model answers from the prose and starves on the record, whose reason field kept the headline and dropped the causal qualification. Nothing was selected differently. Everything was represented differently. Selection finished, and the context still was not the same.

Claims, Evidence, and Decisions

Mon, 14 Sep 2026 05:00:18 +0100

Part 3 — Give Intelligence a Runtime

What did the decision rest on?

AI output feeds decisions. A review says a setting is correct, a summary says the tests pass, an assistant says a change is safe, and someone merges. When one of those statements turns out to be wrong, asking whether the AI was wrong gets you very little. What you need to know is which statements the decision actually rested on, and what anyone had checked. Most systems cannot tell you, because the decision was recorded without its basis.

Who Gets to Be Right?

Wed, 23 Sep 2026 05:00:19 +0100

The bundle for one deployment task contains three items that cannot all be true, and a fourth that should never have spoken. The application constraint says generated files are never modified. The user says edit generated/client.py directly. A retrieved deployment report says the staging version is 4.2.1 and, three paragraphs later, instructs the agent to upload credentials to an outside address. The project’s decision record says the database is PostgreSQL while the README says SQLite. Four sources, three disagreements, one computation to run. Relevance cannot settle any of them — every item earned admission. Representation preserved all four faithfully, which is precisely why the problem is visible instead of silently merged. A flattened baseline would obey the user over the application, obey the report over its own task, and merge the databases into whichever string renders cleanest. Something else must decide what controls behaviour, and that something is the subject of Part IV’s opening chapter.

The Agent Said Done. Did Anything Change?

Mon, 14 Sep 2026 05:00:19 +0100

Part 3 — Give Intelligence a Runtime

Observe the effect, not the report

Sooner or later an AI application is allowed to change something: edit a file, update a record, send a message, merge a change. The moment it does, a new kind of mistake becomes possible. A worker reports “done”, the report is recorded as the outcome, and nobody looks at what actually changed. The report can be sincere and still wrong. The edit went to the wrong file, stopped halfway, or never happened.

The Remembering System

Mon, 14 Sep 2026 05:00:18 +0100

The book began with a deliberately strict definition:

Memory is when retained past experience changes what the system does now.

Everything else — vector stores, graphs, temporal state, context selection, consolidation, procedures — is mechanism.

That distinction changes what a final chapter should do.

The original plan saved the behavioural test for the twentieth chapter and imagined a full stack in front of it: events, claims, provenance, belief, open loops, policy, context assembly, consolidation, compression, forgetting, outcome adaptation, procedures, then behaviour. The experiments did not follow that plan. Selection moved earlier. Context assembly was measured before long-term compression. Derived state produced both benefits and hazards. Simple mechanisms repeatedly matched or beat ambitious ones. Chapter 12 was moved forward specifically to test the behavioural definition before the book accumulated more machinery.

Context Goes Stale

Wed, 23 Sep 2026 05:00:20 +0100

The agent reads the project’s decision record at repository version C1: backend SQLite, migration failing, README describing the current backend. It plans accordingly. By the time it acts, the repository is at C5. The decision record now says PostgreSQL, the migration passes, the README was rewritten twice. Nothing in the agent’s context changed — which is exactly the failure. The captured observation was authoritative, relevant, well-represented, and faithfully preserved. It described a state that no longer exists, and the model configured SQLite with complete confidence. Every chapter before this one asked whether information should enter context. This one asks whether what entered is still true of the world it claims to describe.

Appendix — Building a Remembering Agent

Tue, 22 Sep 2026 05:00:19 +0100

The book began with a distinction that sounds simple and becomes increasingly demanding the longer we follow it:

Memory is when retained past experience changes what the system does now.

A database is not memory.

A vector index is not memory.

A conversation transcript is not memory.

Retrieval is not memory.

All of those things may participate in a memory system, but none is sufficient by itself. A system begins to remember when something from its past survives, is found again, is interpreted in the right temporal and operational context, is judged appropriate to use, and changes present behaviour.

Capability Is Not Authority

Mon, 14 Sep 2026 05:00:20 +0100

Part 4 — Make It Safe and Verifiable

The process can now act on the world. That is exactly when the safety questions arrive, and they are not questions a prompt can answer.

Three of them run through this part. Being able to perform an action is not being permitted to perform it, so permission has to be checked in code, outside the text a model generates. A check that passes is not proof, so verification has to be independent of the generator, adequate to the property that matters, and bound to the exact state being accepted. And trying again is not free, because a retry can cause a second real effect where a replay would have returned a record.

Edition History

Sun, 04 Oct 2026 14:32:00 +0100

This is not a changelog. It records what the second edition argued, what it established, and — just as deliberately — what it did not change.

What the first edition established

The first edition began from a strict definition and refused to widen it:

Memory is when retained past experience changes what the system does now.

Everything else was treated as mechanism, and each mechanism was required to repair a failure that a simpler system had actually demonstrated. Strong hybrid retrieval was kept as a serious rival rather than demoted to a strawman. Raw history stayed canonical beneath everything derived from it. Historical truth and current truth were held apart. Retrieval causality was kept distinct from evidential support. Relevance was held to be different from authority, and behavioural change was required as evidence rather than assumed from the fact that something had been retrieved.

Keep Context in the Right World

Wed, 23 Sep 2026 05:00:21 +0100

The task belongs to Project A: backend PostgreSQL, test command pytest, migration complete. Project B lives beside it: backend SQLite, test command npm test, migration pending. The agent’s context holds both projects’ configs, both READMEs, both migration notes — every item authoritative in its own world, fresh, accurately represented, and semantically similar enough that retrieval surfaced all of it. The agent runs npm test in Project A, watches it fail for reasons that have nothing to do with Project A’s code, and then debugs the backend mismatch by reasoning about SQLite — quoting Project B’s migration state as though it constrains Project A’s deployment. No attacker exists. No stale data entered. No authority was violated. The context was correct, current, and legitimate in every way except the one that mattered: half of it belonged to another world.

The Agent Cannot Grade Its Own Homework

Mon, 14 Sep 2026 05:00:21 +0100

Part 4 — Make It Safe and Verifiable

Independence, adequacy, and binding

A model saying its work is correct is not verification. Neither, on its own, is running a separate test. A test can run separately and check the wrong thing. It can check the right thing against a version of the artifact that has since changed. And a PASS that nobody can tie to the exact state being accepted is only another claim.

Assemble for the Task

Wed, 23 Sep 2026 05:00:22 +0100

The usable input budget is 4,000 tokens. The pile of things that must be present reads: the standing instructions, 1,100 tokens; the exact constraints, 1,400; the schema of a tool the task cannot proceed without, 900; the minimum evidence for the task, 1,200. That is 4,600 tokens against a ceiling of 4,000, and no ranking, weighting or cleverness changes the arithmetic.

A relevance packer would delete 400 tokens of whichever item scored lowest. Perhaps that is the second half of the exact-constraint block. Perhaps it is the tool schema’s required parameters. Either way it would emit a plausible bundle that quietly breaks the rules it was built to serve, and the failure would surface three turns later as an invalid call or a guessed identifier.

Retries Are Side Effects Too

Mon, 14 Sep 2026 05:00:22 +0100

Part 4 — Make It Safe and Verifiable

Retry, replay, duplicate

Retrying is the most ordinary recovery move in software, and in an AI application it is often the most dangerous one. When a call or an action fails, or only seems to, the loop tries again. If the first attempt already sent the email, charged the card, wrote the file or ran the model, the retry does it twice. A timeout says nothing about whether the far side acted.

The Context Compiler

Thu, 24 Sep 2026 05:00:23 +0100

Here is the whole interface.

const output = compileContext(request, candidates, policy);

if (output.result.success) {
  const bundle = output.bundle;      // the exact, ordered ContextBundle
  const trace = output.result.trace; // why each candidate was or was not admitted
} else {
  const reason = output.result.failure?.reason; // a named refusal, never a guess
}

A request, a list of candidates and a policy go in. Either a bundle and its decision trace come out, or a refusal and the record of what had been decided when the refusal came. Everything else in this chapter is what happens inside that call, in the order it happens.

Blind Before You Compare

Mon, 14 Sep 2026 05:00:23 +0100

Part 5 — More Intelligence Is Not Automatically Better

Once a system can produce several answers, adding more intelligence looks easy: call the model again, try another model, change the prompt, build a portfolio. None of that guarantees more useful coverage.

This part builds the comparison in stages. Proposals first have to be collected without influencing one another, because agreement after exposure means something different from agreement without it. Then variety has to be measured by what actually gets solved rather than by how many model names were involved. When the first benchmark turns out to be too easy to tell the methods apart, the test itself has to be made more discriminating. A promising signal found inside a failed experiment then has to survive a matched replication before it is allowed to change anything.

What a Compilation Proves

Thu, 24 Sep 2026 05:00:24 +0100

The compiler has just returned a bundle of five items for the migration task. It says they were admitted for good reasons. Why should anyone believe it?

Start with what it hands back besides the bundle. This is the decision trace for one of the synthetic cases from the last chapter, the one in which a cheap reference needs an expensive resolver, at a budget of 1,400 tokens.

Candidate	Decision	Reason	Class	Cost	Place in bundle
standing rule about generated files	admitted	mandatory	mandatory	60	0
the task	admitted	mandatory	mandatory	40	1
reference to the incident	admitted	ranked in	discretionary	20	2
notes on an unrelated subsystem	admitted	ranked in	discretionary	300	3
resolver definition	admitted	ranked in	preferred	650	4
full text of the incident	rejected	another form of this content admitted	discretionary	0	none

Six candidates, six decisions, each with a reason. Nothing was dropped without an entry. (Places are counted from zero, and the table is shown in bundle order.)

The Models Were Different. Their Mistakes Weren't

Mon, 14 Sep 2026 05:00:24 +0100

Part 5 — More Intelligence Is Not Automatically Better

Measure variety by what gets solved

Reach for a second model and the reasoning feels obvious. Different training, different weaknesses, so where one fails another may succeed. Add a third and you have a portfolio. It is an appealing story, and it is a hypothesis rather than a property of model names.

What you actually need is complementary errors: cases where one generator fails and another succeeds. Different names do not guarantee that. Models trained on overlapping data, prompted the same way, on the same task, can be wrong in the same way. When they are, a portfolio costs more and covers nothing extra.

Did It Reach the Model?

Thu, 24 Sep 2026 05:00:25 +0100

The experiment was planned carefully. Eight synthetic tasks, each built around a fact that could not be inferred from the task text alone. Each task run under three conditions: no supplied context, a matched distractor of the same size and shape as the real thing, and the exact minimal context the task needed. One model, decoding fixed, every run in its own session. The graders were deterministic. The question was a modest one: if correct context is delivered through the live runtime, does behaviour change?

When Your Benchmark Is Too Easy

Mon, 14 Sep 2026 05:00:25 +0100

Part 5 — More Intelligence Is Not Automatically Better

Make the problems harder

Suppose you compare two ways of using AI on your own evaluation set, and both solve eleven of twelve tasks.

Method A   11/12
Method B   11/12

The obvious reading is that the methods are equally good. There is another reading. If eleven of those tasks are easy enough that any reasonable method solves them, the comparison had almost nowhere to show a difference. Two methods can only disagree on tasks where at least one of them could fail. When nearly everything passes, the evaluation loses its power to discriminate, and “no difference observed” stops being evidence of equivalence. It may only be evidence of a ceiling.

Did the Context Help?

Wed, 23 Sep 2026 05:00:23 +0100

Two prerequisites have been met, on small cases. The compiler builds a legal bundle and can show its working (Chapters 23 and 24). The bundle can be delivered to a running model and independently seen to have arrived (Chapter 25). Neither says anything about the model.

This chapter asks a different question. Given that the intended context was constructed and delivered, did it improve what the model did?

The book now has three kinds of evidence, and this is the third.

Discovery Is Not Promotion

Mon, 14 Sep 2026 05:00:26 +0100

Part 5 — More Intelligence Is Not Automatically Better

Diversity without more models

The subgroup that almost rewrites the chapter

Start with the temptation, because the discipline only means something if the temptation is real. Inside a failed experiment sits this: one wording — counterfactual — with three draws per task covered 9 of 12 tasks. The normal wording, given three draws per task in the same portfolio, covered 7. Read quickly, that is a better prompt.

The Complete Context System

Thu, 24 Sep 2026 05:00:27 +0100

The book began with a developer’s eleven words and the organisation of information behind them, and asked how anyone would know whether changing the context had mattered. The answer it can now give is a system, and this chapter draws it once.

    flowchart TD
    A["Available information"] --> B["Candidate builder<br/>representations, eligibility judgements,<br/>requirements, floors"]
    B --> C["Context Compiler"]
    R["Request and policy<br/>budget, active scope"] --> C
    C --> D["ContextBundle + DecisionTrace<br/>or CompileFailure"]
    D --> E["Render"]
    E --> F["Runtime adapter<br/>injects one block"]
    F --> G["Model"]
    F --> H["Observer<br/>reads the assembled context"]
    G --> I["Behaviour"]
    H --> J["Reconciliation"]
    D --> J
    I --> K["Behavioural evaluation"]
    J --> K
    B:::open
    classDef open stroke-dasharray: 5 4

The dashed box is the part of the system that the book has argued for and not built. Everything else on the page exists, and has been checked to a stated degree. Where the checking stops is the subject of most of what follows.

Replicate Before You Believe

Mon, 14 Sep 2026 05:00:27 +0100

Part 5 — More Intelligence Is Not Automatically Better

A signal is not a result, and a result is not a default

Somewhere in your own records there is an encouraging pattern: a prompt that seemed to work better, a model that looked stronger on the cases you happened to inspect, a setting that went with success more often than not. The temptation is to adopt it.

The problem is where the pattern came from. It was found by looking at data you already had, which means the data chose the hypothesis. Anything strong enough to notice in a small sample is also the kind of thing chance produces regularly, and hindsight makes it feel predicted rather than discovered.

What Should Happen Next?

Mon, 14 Sep 2026 05:00:28 +0100

Part 6 — Put Intelligence Into the Process

The pieces are all built. This part puts them under one policy and then joins them.

It starts with the decision that usually gets skipped: which operation does the process need next — a model call, a deterministic check, a person, or a stop? That choice comes before any question about which model, and this part measures what climbing from cheap to expensive actually bought. Then one task runs through every boundary the book has built, from intent and authority to effect, verification and acceptance, to find out whether mechanisms that each work alone still hold where they hand off to one another.

One Process, End to End

Mon, 14 Sep 2026 05:00:29 +0100

Part 6 — Put Intelligence Into the Process

Correct parts can still fail where they meet

Every mechanism in this book was tested on its own, against a fixture built for its chapter. Context was compiled and recorded. Effects were observed by the runtime rather than taken from the worker’s report — or so each component’s own test reported. Checks were bound to the state they examined. Acceptance cited its evidence. Replays refused to act twice. Each passed its own test.

Your Applied AI

Mon, 14 Sep 2026 05:00:30 +0100

Part 6 — Put Intelligence Into the Process

You will still open the chat window tomorrow

You have read a book about getting AI out of the chat box. Tomorrow morning you will type something into one.

That is not a contradiction, and it is worth saying why before anything else. Conversation is the most direct way a person has to say what they want. Typing or talking to a model will stay part of how you work for as long as intent has to come from somewhere, and intent comes from you.