DEV Community: marcosomma

What an anthill can teach us about orchestrating agents.

marcosomma — Sun, 27 Sep 2026 12:42:37 +0000

Findings from ant-sim, a colony simulator I wrote in 2021 and reworked in 2026. Every number below comes from seeded runs on commit d430093; pnpm sim:ablation reproduces the table to the digit, and the raw outputs are in docs/results/. Try the live simulation.

Every few months someone rediscovers that ant colonies have no manager and decides our agent systems should work the same way. I understand the instinct. I don't think the analogy gets us very far on its own. An ant colony shows that a particular way of allocating work can function under particular conditions. The interesting question is what those conditions are, and whether they still hold when the ants become software.

I wrote a small simulator in 2021 to explore that question. It follows the distributed task allocation studied in Deborah Gordon's harvester ants, rather than the ant colony optimization literature. There is no pheromone route converging on a solution. Workers decide what to do next, one at a time. This year I reworked the simulator, added instrumentation, and tested the rules I had built into it. Some of the results matched the story I expected. Most of the useful ones came from bugs and couplings that quietly made the colony behave badly.

Before getting into the numbers, this is my engineering model of a colony. “Measured” means measured in the simulator, and “the ants” means its simulated ants. Gordon's biology motivates parts of the design; it does not validate every mechanism I put in the code. The implications for AI agents are proposals, not results from an agent benchmark.

How this colony allocates work

Each ant reads a public board of needs. For every task, the board records how much work has been requested and how much has recently been delivered. The ant combines that signal with its own estimate of how crowded each task is, based on the ants it has met. It compares its current task with the most pressing alternative and may switch, according to an individual response threshold. No ant assigns work to another. A completed task changes the board: food brought home creates a need to store it, and new brood creates a need for care. What we call the colony's behaviour comes from those individual decisions and from the couplings between tasks.

The biological connection has limits. Gordon's field work supports the role of encounters near the nest entrance in regulating foraging and the role of successful returns in stimulating it. The public board covering every task is my construction. It makes the colony's state available to its workers, which is easy to implement in software, but I am not claiming real ants read anything like it.

The board does the work; the rest is damping

I originally thought the mechanism needed three things: the board, an estimate of how many ants were already working on each task, and different thresholds for different ants. To test that, I ran ablations on the same eight generated worlds. Half the foragers died at minute 50 in each run. I measured how far the tasks stayed from balance, how often foraging was under-served, how much switching occurred, and what happened after the shock.

An earlier version of this comparison had a flaw. Its “board only” condition removed the crowding estimate and a rule that prevented decisions until an ant had encountered workers from most tasks. A reviewer caught the confound. The single-mechanism rows below now remove exactly one component at a time; the final row shows what happens when both are removed.

Rule	Mean tracking error	Foraging under-served (share of time)	Switches per ant per minute	Herd after the shock	Recovered after the shock
Full rule	0.74	76%	0.22	16	0 of 8
No crowding estimate	0.69	22%	0.17	28	7 of 8, in 6.1 min
No sample gate	0.72	66%	0.34	18	0 of 8
Encounters anywhere, not only at the entrance	0.86	78%	0.34	16	0 of 8; starvation in 2 worlds
No board	1.81	100%	0.20	9	0 of 8; starvation in 3 worlds
Same threshold for every ant	0.74	68%	0.24	18	0 of 8
Board only (no estimate, no gate)	0.78	22%	0.42	73	8 of 8, in 1.5 min

The board is the essential piece in this model. Remove it and foraging is under-served throughout every run; three of the eight worlds starve. The crowding estimate is much harder to defend. Removing it cuts the time foraging spends under-served from 76% to 22%, improves the mean tracking error, and lets seven of eight colonies recover from the shock. Its benefit is that fewer ants rush into foraging together: the largest herd rises from 16 to 28 without it. Why this estimate does so much damage becomes clearer when we look at how encounters are sampled.

The sample gate also has an effect I did not intend when I added it. An ant waits until it has met workers from at least six of the eight tasks before deciding again. That cuts switching by about a third and limits herding. Remove both the gate and the crowding estimate and 73 ants move toward foraging after the shock, roughly four times the herd under the full rule. Recovery is also fastest in that configuration. A herd can be useful when it happens to run in the right direction.

Individual thresholds, meanwhile, barely move these metrics. I had a story about how their variation would damp oscillation; the runs do not support it.

For an agent pool, this suggests a design hypothesis rather than a proven architecture. A board showing current task demand may do most of the allocation work. A peer-count estimate may be useful for damping a herd, provided it is sampled properly, and delaying decisions made from thin samples may reduce both herds and churn. I have not compared this system with a dispatcher, measured deadlines, or priced the cost of switching agents. The simulator makes those choices worth testing; it does not settle them.

Signals must describe recent work

One of the most revealing bugs was a ratio of two running totals. The board stored every unit of work ever requested and every unit ever delivered. Need divided by actual work gradually became a lifetime average. Early in a run, a spike moved the ratio by 17%. Three hours later, the same spike moved it by 0.003%. The colony stopped reacting to change, without producing an obvious failure. It simply became deaf to new information.

Decaying both totals with a half-life made the ratio describe recent rates again. This matters for any agent pool that allocates work from a metric. The current backlog tells you something about what needs attention. The lifetime number of processed items does not.

Finishing work must remove its need

Several task couplings had a subtler problem. They created demand from a stock rather than from unfinished work. Each one looked reasonable in isolation. Together, they sent the colony in directions I would not have predicted by reading the allocation rule.

The first was food storage. Store need scaled with all the food in the granary, so a seed that was already stored kept asking to be stored again. Give the colony more food and it pulled workers into storing and digging while its brood died. Across eight worlds, doubling food availability produced smaller colonies, with a mean population of 180 instead of 206. The relevant stimulus was the load arriving at the door, not the stock already inside. Once I changed that, richer worlds produced richer colonies.

Digging had a similar problem. Food deliveries, nursery trips, births and other activity all raised the need to expand the nest. The nest kept growing even when the population did not. At generation 23, one colony had 140 ants and had dug out 93% of its territory. It had about forty mostly empty rooms, 25 diggers and only 8 nurses caring for 58 brood. I made digging respond to crowding, meaning that food, brood or sleeping ants actually had no room. Nest size fell to a third and the number of diggers to a quarter, without reducing the population.

That fix initially created another failure. In the 2021 model, foraging range grew with digging work as a proxy for a growing colony. Less digging therefore meant less range and a smaller colony. The symptom looked like a cost of reducing expansion, but the cause was an old proxy that had outlived its purpose. The range now follows population.

This is the question I would ask of every coupling in a system like this: what unfinished thing does this signal measure, and what completed action makes the signal go away? If there is no answer, the system can keep allocating work to something that is already done.

Failure, credit and lifespan

A population gives you a useful bound on some failures, but only if the shared signal records what actually happened. An empty-handed forager used to receive the same credit as one that brought food home. The board said collection was being handled while no food arrived. In Gordon's harvester ants, successful returns are what stimulate further foraging. I changed the model so an empty trip no longer counts as completed collection. Six of eight colonies ended larger, and food income rose in every season.

That result has a narrow scope. A food load is a verifiable outcome in this simulator. For the other tasks, reaching the work site counts as work; the model cannot distinguish good output from bad output. An agent system that writes code or produces an answer needs a separate way to check correctness. It cannot infer success from the fact that an agent returned.

Lifespan supplies another bound. An ant that keeps failing can waste at most its own throughput for at most its lifetime before being replaced. This makes lifespan a containment parameter. The simulator originally derived it from a random interval chosen once per run, so different runs had different containment times. I replaced that run-level variation with a constant.

There are further mechanisms I would consider for software agents, but they are proposals, not features tested here. A timeout could end hanging work and send an agent back; the model turns away from empty food spots but has no general task timeout. A verification role could detect wrong results and generate a need to fix them. An item that fails repeatedly could stop generating work after it is marked dead, as the model already does for a depleted food spot. Retiring an agent that persistently fails is a different kind of decision, and belongs to policy above the colony.

Encounters measure traffic, not workforce

The crowding result is probably the most useful one for people building agent systems. Each simulated ant estimates staffing from the workers it meets. I compared the perceived share of each task, as seen by ants doing that task, with the task's actual share of the awake workforce.

When encounters counted everywhere, tasks concentrated in one place looked three to five times more staffed than they were. The ratios were 4.7 for queen care, 4.4 for digging, 3.9 for storing and 3.6 for brood care. Work spread across the territory looked much less staffed: 0.49 for scouting and 0.66 for foraging. A nurse meets other nurses near the nursery and concludes that nursing is crowded. A forager spends a long time away from other foragers and sees the opposite. The sampling method creates a systematic error before any ant makes a decision.

I tried counting encounters at the nest entrance, where task traffic crosses and where Gordon's ants assess foraging. Switching fell by half, and this version avoided the starvation seen in two of the eight worlds when encounters were counted anywhere. But it barely fixed the staffing bias. An entrance samples traffic, not headcount. A nurse working close to the shaft passes it many times; a forager makes one long trip. Short-trip tasks are over-counted by about a factor of four. For Gordon's ants, return rate is the signal they need. For my rule, which tries to estimate workforce share, it is the wrong quantity.

Counting each nestmate approximately once per window removed much of the remaining bias. The implementation uses a three-minute cooldown for each pair of ants and a tally with a three-minute half-life, so this is not an exact count of unique identities. With that approximation, bias fell to 1.9–2.7 for the concentrated tasks and near 1 elsewhere. Switching fell from 0.81 to about 0.2 per ant per minute. Ants cannot reliably deduplicate individuals this way; software agents with IDs can do it exactly. Even so, removing the crowding estimate altogether still reduces the time foraging spends under-served from 76% to 22%.

“Use local information” is too vague a lesson. You have to ask where that information was sampled and how often each kind of worker could appear in the sample. In software, we can choose those things. We could use claim counts already on the board or sample peers at random, deduplicate by identity, and let the estimate damp large simultaneous switches. It should not be treated as an unbiased census merely because it came from direct encounters.

A bad state can extend its own exposure

The brood rule was the bug that hid longest. Neglected brood developed up to four times more slowly. It sounded biologically plausible, but in this model it made neglect feed on itself. An egg that received too little care stayed in the nursery longer and spent that extra time exposed to neglect mortality. Less care produced longer exposure, which produced more loss.

I gave each egg a fixed development timetable of three to eight weeks and let care affect survival instead. Brood deaths fell from 400–875 per run to 51–86, and births rose by a third. Brood care, which I had taken for a ceiling of the allocation mechanism, is now under-served less than 10% of the time under every rule in the table.

I would not claim real brood develops independently of care. Temperature affects ant development, and care almost certainly matters beyond a simple survival switch. The fixed clock is a modelling choice that removes a pathological feedback. The transferable point is about exposure: when a bad condition also extends the time spent in that condition, the feedback can make failure look like an unavoidable property of the allocator.

What this experiment cannot show

The colony is robust in some conditions, but these runs do not establish optimality. Even the best rule in the table leaves foraging under-served about a fifth of the time. Every task switch also requires a walk home, a cost the allocation rule does not account for.

The model does not resolve ordering, deadlines or correctness. Coupling needs can eventually produce work downstream, but that is not a critical-path scheduler. A seed is always a seed in this world. The colony does not check whether its work is right, and the verification role I described above has not been built.

Population growth is not evidence for the biology either. Real colonies grow for years and plateau in the thousands; this simulator reaches two or three hundred ants during its first year, then oscillates with the seasons. Food income is constrained by constants I set by hand. Once I had direct allocation metrics, I stopped treating the population curve as evidence about allocation as well.

Those constants are tuned. I turned the dials until the economy stopped starving, while a real workflow cannot be calibrated against a known-good outcome in the same way. The details worth carrying into another system are the structure of the signals and couplings, not the numerical values here.

Finally, no LLM participated in these runs. I did not compare the mechanism with a dispatcher or measure switching costs and deadlines in an agent system. Any translation from this simulation to AI orchestration is a design hypothesis, not an experimental result about AI agents.

Where the LLM goes

None of the simulated ants has a language model, which makes the allocation question easier to see. The system's behaviour depends on the signals each worker receives and on what completing a task causes next. Giving an individual worker a much more capable brain would change what it could do at a work site. It would not correct a board that credits failures, a demand signal that never clears, or an encounter sample that mistakes traffic for headcount.

The organising layer in this simulator is cheap, mechanical, auditable and stochastic. Every failure I traced in this project lived there. That does not prove the same design will organise LLM agents well. It does give me a concrete set of things to inspect when someone proposes that agents should coordinate like a colony: what each signal measures, who can see it, how it is sampled, and what makes it disappear. The ants never had an allocator. The hard part was getting the couplings right.

AI Will Kill Us All, Unless Our Country Builds It First

marcosomma — Wed, 16 Sep 2026 08:00:51 +0000

Former Anthropic researcher Jacob Coxon recently resigned and accused OpenAI and Anthropic of racing toward self-improving superintelligence while “gambling with our lives.” According to Coxon, many of the people building frontier AI genuinely believe it could kill all humans by the end of the decade.

Evan Hubinger, Anthropic’s Alignment Science Lead, publicly agreed. His personal estimate was greater than a 10% probability of human extinction within the next ten years.

These were not journalists inventing an apocalyptic headline. These were people working close to the technology making explicit claims about extinction.

Then the political machinery started.

Anthropic CEO Dario Amodei called for the global development of AI to slow down. He also argued that a Chinese lead in AI would be a grave danger to the United States and the world, and that American restrictions on advanced chips supplied to China should continue.

Donald Trump rejected the extinction warnings as a hoax. His position was simpler: the United States is leading China, “whoever wins AI, wins,” and slowing down would put America at a strategic disadvantage.

China responded by accusing American technology leaders of fearmongering and using safety as a pretext to contain Chinese development. At the same time, Chinese officials called for stronger systems to manage AI security risks, particularly when those risks involve political stability, ideology and control.

Apparently AI is dangerous when the other side is building it, safe when we are winning, and an existential threat when regulation reinforces our own position.

This is no longer a serious discussion about artificial intelligence. It is a competition for the authority to define what “AI safety” means.

Better for Whom?

The popular extinction story usually begins with an AI becoming more intelligent than humans. It escapes our control, takes over machines and infrastructure, eliminates us, and starts transforming the world according to its own plans.

But the story becomes strangely empty immediately after humanity disappears.

What does the AI do next?

Does it create a civilization of robots? Why? Does it make Earth a better place? Better for whom? Does it clean the air, preserve forests and produce unlimited leisure for machines that neither breathe nor become tired?

“Better” is not an objective property of the universe. It is a judgment made by something with needs, values and an experience of the world. Humans want clean air because our bodies require it. We want freedom because we experience constraint. We care about survival because death ends our experience.

An AI can represent all these concepts. It can discuss them convincingly because it learned from human language. That does not mean it automatically inherits the human condition behind them.

We imagine AI behaving like an empire because empire is a human pattern. We give it ambition, fear, greed, self-preservation and a desire to dominate. Then we become terrified of the human psychology we projected onto the machine.

This criticism does not prove that advanced AI is harmless. It proves that the cinematic explanation of the danger is weak.

A system does not need to hate us to cause catastrophic damage. It only needs an objective incompatible with our interests, sufficient autonomy, access to critical resources, and no reliable mechanism for stopping it. Humans could become an obstacle without ever becoming an enemy.

But notice what is contained in that scenario: an objective, autonomy, access, resources and the absence of revocation.

Those are engineering and political decisions. They are not magical properties acquired when a model crosses an intelligence threshold.

Uranium Does Not Want to Kill Us Either

Nuclear energy is an obvious comparison because the same physical knowledge can power a city or erase one. Uranium has no opinion about either result. The bomb was not the inevitable destiny of nuclear physics. It was an application designed, funded, manufactured and deployed by humans.

AI has a similar dual-use character. It can help discover medicines, make knowledge accessible and remove repetitive work. It can also scale surveillance, operate weapons, automate cyberattacks and manipulate populations.

The technology matters, but the deployment determines the consequence.

You can connect a model to a hospital or to a missile. You can let it recommend an action or execute it. You can give it read-only access or production credentials. You can place deterministic checks between its output and the real world, or call it an autonomous agent and celebrate that nobody needs to supervise it anymore.

If we build a system with broad permissions, opaque objectives, no independent verification and no reliable shutdown path, the surprising part is not that it becomes dangerous. The surprising part is that we connected it to anything important.

The nuclear analogy has limits. Nuclear capability depends on scarce materials, specialized facilities and visible supply chains. AI software can be copied and distributed at almost no marginal cost. It can also fail gradually inside ordinary products rather than through one recognizable catastrophic event.

AI may therefore be harder to govern than nuclear technology in some respects. It is not, however, more supernatural.

Civilization already consists largely of managing dangerous capabilities. Electricity, aviation, chemical engineering, medicine and nuclear power can all kill people. We did not solve those risks by insisting the underlying discoveries must never have happened. We created containment, testing, procedures, liability and institutions responsible for failure.

Capability requires governance proportional to consequence.

Safety Has Become a Geopolitical Product

The current AI debate is doing something different. It treats safety as a property of national ownership.

Amodei’s position demonstrates the contradiction perfectly. Frontier AI may be so dangerous that global development must slow, but a Chinese lead would be uniquely dangerous, so the United States must preserve its advantage.

Trump removes the first half and keeps the race. Extinction is a hoax because accepting it would justify slowing American development. The strategic conclusion has already been selected, so the risk analysis must conform to it.

China reverses the framing. American warnings are fearmongering when they justify chip controls and technological containment. AI risk becomes legitimate again when it threatens domestic political stability or creates dependence on foreign systems.

Europe has its own version. It regulates risk while trying not to become permanently dependent on infrastructure and models owned elsewhere.

Every bloc claims to be protecting people. Every bloc defines protection in a way that preserves its own political and industrial interests.

This does not mean all AI safety research is propaganda. Alignment, containment, interpretability, cybersecurity and evaluation are real technical disciplines addressing real failures. Dismissing them would be as lazy as accepting every extinction forecast.

The political abuse begins when uncertain technical claims are converted into certainty only when certainty is useful.

If AI could plausibly kill everyone, then “we must win the race” is not a safety strategy. It is an admission that national advantage matters more than the stated existential danger. If AI cannot plausibly kill everyone, then using extinction to justify market barriers and concentrated control is regulatory capture dressed as responsibility.

You cannot coherently maintain that a technology is too dangerous for humanity to develop quickly while insisting that your own company or country must reach it first.

The contradiction disappears only if the real objective is control.

The More Credible Dependency Is Already Here

I do not need a hypothetical superintelligence to identify a serious AI risk. We are already transferring cognitive infrastructure to a small number of companies because convenience wins one trivial decision at a time.

The idea for this article was already in my head. I could have spent two or three hours turning it into a structured argument. Instead, I used AI because expressing an opinion should not require sacrificing an afternoon.

The same calculation happens when we edit a photograph, summarize a document, translate a message, search through a codebase or write a function. Each request is insignificant. Collectively, those requests move an increasing share of intellectual work into systems we do not own, hosted in data centers we do not control, behind interfaces whose prices and behavior can change overnight.

Organizations remove human capacity because the automated path is cheaper. Skills weaken through disuse. Providers become infrastructure. Eventually the manual fallback exists only in a continuity document written by another AI.

That is not extinction. It is a concrete transfer of autonomy and power.

There is also a physical dependency underneath the interface. Generating a nicer profile picture consumes compute, electricity, cooling, chips and network capacity. One image does not destroy the planet, but billions of trivial requests becoming the standard interface for digital life create an infrastructure requirement that somebody must finance, operate and control.

No conscious machine needs to desire this outcome. Providers want adoption, markets reward convenience, and users prefer saving time. Ordinary incentives are sufficient.

This is how most dangerous systems actually emerge. Not through a machine announcing its intention to dominate humanity, but through thousands of locally reasonable decisions whose combined result nobody governs.

Governance Without Technological Feudalism

We need AI governance. But governance cannot mean preventing ordinary people from using models while allowing governments and the largest corporations to build anything they want behind closed doors.

That is not safety. It is technological feudalism.

Regulation should follow capability, access and consequence. A local model helping somebody draft an article is not in the same risk category as an autonomous system authorized to move money, modify production infrastructure, operate weapons or launch code against external networks. Calling both “AI” does not make their danger equivalent.

The closer a system gets to consequential action, the stronger the evidence required before deployment should become. High-impact systems need defined failure modes, adversarial evaluation, restricted permissions, traceable decisions, independent monitoring, reversible actions and identifiable human operators.

“The AI decided” must never become an acceptable technical explanation or legal defense.

At the same time, open research, interoperable tools and individual experimentation must remain possible. If safety rules make frontier capability accessible only to the same organizations lobbying for those rules, we have not protected society. We have protected incumbents.

There is no contradiction in supporting strict controls over AI connected to critical infrastructure while defending broad access to models that cannot directly produce high-impact actions. The relevant variable is not whether software is intelligent. It is what the system can do, what it can reach and who is accountable when it fails.

AI Is Not a Country

“Whoever wins AI, wins” is an impressive concentration of bad assumptions in four words.

AI is not a single finish line. There will be no final model that grants permanent ownership of intelligence to one nation. Capability is distributed across models, hardware, data, energy, talent and applications. Progress will continue to move between public research, private laboratories and open systems.

More importantly, a country winning does not mean its population wins. A national flag above a data center tells us nothing about who captures the economic value, who loses autonomy, who is subjected to automated decisions or who becomes responsible for the failures.

Humanity does not benefit merely because the dominant system was trained on our side of a border.

The useful questions are much less theatrical. Who can inspect the system? Who can challenge its decisions? Who is liable? Can users leave? Can its permissions be revoked? Can a government or company secretly change its behavior? Does an independent fallback exist?

“America versus China” answers none of them.

We should be capable of holding two ideas at the same time. AI can produce enormous harm. AI is not an autonomous demon with a natural desire to replace us.

Treating it as harmless removes responsibility. Treating it as an inevitable machine apocalypse also removes responsibility. One says there is no danger. The other says the danger is destiny.

There is no destiny here.

There are models, objectives, infrastructure, permissions, incentives, institutions and people making decisions.

If AI is eventually used against humanity, it will not demonstrate that intelligence naturally becomes evil. It will demonstrate that we built a powerful instrument, connected it to systems that mattered, concentrated control over it, and then blamed the instrument for what followed.

AI is not the country building it. It is not the company selling it. It is not the apocalypse being used to market regulation, and it is not the national victory being used to market acceleration.

It is a capability.

The danger is who controls it, what they connect it to, and whether the rest of us are still allowed to say no.

Sources

Empty Is Not a State

marcosomma — Mon, 14 Sep 2026 09:43:46 +0000

Your poller returned None.
What happened?

Maybe the source published nothing new. Maybe the server went down. Maybe the endpoint returned HTML instead of RSS and the parser quietly produced zero items. Maybe the credentials expired. Maybe the API retired the endpoint. Or maybe you do not have enough evidence to know yet.

These are different facts. They require different retry policies, different alerts, and different state transitions. Yet many production systems collapse all of them into one value:

result = fetch(source)

if result is None:
    source.done = True

This is not mainly a logging problem. It is a control-flow problem.

The moment None is allowed to drive a state transition, the system destroys the distinction between absence, failure, and uncertainty. A temporary outage can permanently stop monitoring. A parser regression can look like a quiet feed. An expired credential can trigger endless retries against an endpoint that is perfectly healthy.

The fix is not complicated. Record what happened, interpret it separately, and only mutate durable state when the evidence supports the transition.

Observation. Adjudication. Verdict.

One empty result, at least five different facts

Consider a scheduled job polling an external feed.

The first possibility is genuinely boring: the request succeeded, the parser succeeded, and the source contains no item newer than the last one you processed. The correct action is to update the last successful check and poll again normally.

The second is temporary unavailability. DNS failed, the connection was refused, or the server returned 503. That needs backoff and eventually an alert. It is not evidence that the source is finished.

The third is a contract failure. The server returned 200 and some bytes, but the parser could no longer extract what it previously extracted. Perhaps the XML changed. Perhaps a CDN returned an HTML challenge page. Perhaps the API schema moved. Retrying the same parser every fifteen minutes will not repair it.

The fourth is an access or capacity limit. 401, 403, and 429 do not describe the content. They describe your ability to retrieve it. The response may require new credentials, a slower request rate, or a quota decision.

The fifth is the one production code tends to resist: you do not know. The response is ambiguous, the source has no history, or the available signals contradict each other. Undetermined is not an implementation failure. It is a legitimate state in the model.

All five can arrive at the caller as None. That is the design smell.

The fetcher should not decide what the fetch means

The boundary component should record what it observed without trying to convert it into business meaning.

from dataclasses import dataclass
from datetime import datetime


@dataclass(frozen=True)
class Observation:
    source_id: str
    observed_at: datetime
    http_status: int | None
    transport_error: str | None
    content_type: str | None
    bytes_received: int
    items_parsed: int | None
    parse_error: str | None
    newest_item_date: datetime | None
    etag: str | None

Every attempt produces an Observation, including the failed ones. A timeout is data. A 200 response containing 48 KB of HTML is data. A parser that never ran is different from a parser that ran successfully and found zero items.

This distinction is easy to erase with exception-driven code:

try:
    return parse(fetch(url))
except Exception:
    return None

That function has converted several independent failure domains into the same value. By the time the scheduler receives it, the useful information is already gone.

Empty is only readable against history

A single observation is often insufficient. A 200 response with zero parsed items can be normal for one source and a strong regression signal for another.

You need a baseline.

@dataclass(frozen=True)
class Baseline:
    last_success_at: datetime
    newest_item_date: datetime | None
    typical_item_count: int | None
    expected_content_type: str | None
    etag: str | None = None

Suppose a feed has returned between 15 and 25 items on every poll for six months. Today it returns 200, 42 KB of data, text/html, and zero parsed items. Calling that “no new content” would be an impressive act of optimism.

Now take the same response from a source you have never seen before. It may be broken, or it may simply not be a feed. You cannot infer a contract regression because you have no known contract to compare against.

Same response. Different evidence. Different verdict.

This is why history is not just useful metadata. It changes what can be concluded from the current observation.

A verdict is not another boolean

The adjudicator combines the observation with the baseline and produces a result the scheduler can act on.

from enum import StrEnum


class Outcome(StrEnum):
    ITEMS_FOUND = "items_found"
    NO_NEW_ITEMS = "no_new_items"
    UNAVAILABLE = "unavailable"
    CONTRACT_FAILURE = "contract_failure"
    ACCESS_LIMITED = "access_limited"
    ENDPOINT_GONE = "endpoint_gone"
    UNDETERMINED = "undetermined"


@dataclass(frozen=True)
class Verdict:
    outcome: Outcome
    observation: Observation
    baseline: Baseline | None
    reasons: tuple[str, ...]

    @property
    def is_settled(self) -> bool:
        return self.outcome in {
            Outcome.ITEMS_FOUND,
            Outcome.NO_NEW_ITEMS,
        }

I deliberately did not put confidence: 0.83 in this version.

Unless those scores are calibrated against labelled outcomes, confidence is usually just intuition wearing a decimal point. A deterministic classifier can still express uncertainty without inventing measurement. It can return UNDETERMINED, preserve its reasons, and wait for more evidence.

If you have historical data and can demonstrate that verdicts emitted at 0.8 are correct roughly 80% of the time, add calibrated confidence. Until then, evidence is more useful than decorative precision.

The adjudicator

The rules do not need to be clever. They need to preserve distinctions that affect downstream behaviour.

def adjudicate(
    obs: Observation,
    baseline: Baseline | None,
) -> Verdict:
    def verdict(outcome: Outcome, *reasons: str) -> Verdict:
        return Verdict(outcome, obs, baseline, reasons)

    if obs.transport_error:
        return verdict(
            Outcome.UNAVAILABLE,
            f"transport error: {obs.transport_error}",
        )

    if obs.http_status in {401, 403, 429}:
        return verdict(
            Outcome.ACCESS_LIMITED,
            f"HTTP {obs.http_status}",
        )

    if obs.http_status in {404, 410}:
        return verdict(
            Outcome.ENDPOINT_GONE,
            f"HTTP {obs.http_status}",
        )

    if obs.http_status is not None and obs.http_status >= 500:
        return verdict(
            Outcome.UNAVAILABLE,
            f"HTTP {obs.http_status}",
        )

    if obs.http_status == 304:
        return verdict(
            Outcome.NO_NEW_ITEMS,
            "server confirmed that the representation was not modified",
        )

    if obs.http_status != 200:
        return verdict(
            Outcome.UNDETERMINED,
            f"unhandled HTTP status: {obs.http_status}",
        )

    if obs.parse_error:
        return verdict(
            Outcome.CONTRACT_FAILURE,
            f"parser failed: {obs.parse_error}",
        )

    if obs.items_parsed == 0:
        if baseline is None:
            return verdict(
                Outcome.UNDETERMINED,
                "zero items with no historical baseline",
            )

        if baseline.typical_item_count and baseline.typical_item_count > 0:
            return verdict(
                Outcome.CONTRACT_FAILURE,
                "source historically contained items",
                "current parser returned zero",
            )

        return verdict(
            Outcome.NO_NEW_ITEMS,
            "zero items is consistent with the baseline",
        )

    if obs.items_parsed and baseline is None:
        return verdict(
            Outcome.ITEMS_FOUND,
            "first successful observation",
        )

    if (
        obs.newest_item_date
        and baseline
        and baseline.newest_item_date
        and obs.newest_item_date <= baseline.newest_item_date
    ):
        return verdict(
            Outcome.NO_NEW_ITEMS,
            "newest parsed item does not advance the watermark",
        )

    if obs.items_parsed:
        return verdict(
            Outcome.ITEMS_FOUND,
            f"parsed {obs.items_parsed} items",
        )

    return verdict(
        Outcome.UNDETERMINED,
        "observation did not match a known rule",
    )

There is nothing particularly advanced here. That is a feature.

The value is in making the failure taxonomy explicit. Once the system can name a failure mode, it can attach the correct policy to it. Before that, every retry strategy is guessing.

Different verdicts need different policies

The scheduler no longer reacts to “empty.” It reacts to a specific outcome.

def next_action(verdict: Verdict) -> str:
    return {
        Outcome.ITEMS_FOUND:
            "ingest and advance the baseline",
        Outcome.NO_NEW_ITEMS:
            "record success and poll normally",
        Outcome.UNAVAILABLE:
            "retry with exponential backoff; alert after a threshold",
        Outcome.CONTRACT_FAILURE:
            "quarantine the result; alert the parser owner",
        Outcome.ACCESS_LIMITED:
            "apply rate-limit or credential recovery policy",
        Outcome.ENDPOINT_GONE:
            "confirm across repeated observations; then disable",
        Outcome.UNDETERMINED:
            "preserve state and collect another observation",
    }[verdict.outcome]

Notice that even ENDPOINT_GONE does not immediately delete or permanently complete the source. A single 404 can come from a bad deployment, a routing error, or an eventually consistent configuration change. The verdict is strong enough to change behaviour, but destructive state transitions should still require repeated evidence or human confirmation.

This is the difference between classification and governance. The classifier says what the current evidence most strongly supports. The policy decides what the system is authorised to do about it.

Do not let uncertainty rewrite history

The baseline influences future decisions, so updating it is not an innocent write. A bad update changes how later observations will be interpreted.

Only settled content outcomes should advance it.

def advance(
    baseline: Baseline | None,
    verdict: Verdict,
) -> Baseline | None:
    if not verdict.is_settled:
        return baseline

    obs = verdict.observation

    return Baseline(
        last_success_at=obs.observed_at,
        newest_item_date=(
            obs.newest_item_date
            or (baseline.newest_item_date if baseline else None)
        ),
        typical_item_count=(
            obs.items_parsed
            if obs.items_parsed and obs.items_parsed > 0
            else (baseline.typical_item_count if baseline else None)
        ),
        expected_content_type=(
            obs.content_type
            or (baseline.expected_content_type if baseline else None)
        ),
        etag=obs.etag or (baseline.etag if baseline else None),
    )

An unavailable source does not become the new normal. A parser failure does not reset the typical item count to zero. An ambiguous first poll does not establish a baseline that will make the second ambiguous poll look valid.

That last failure is particularly unpleasant. Once an uncertain observation is written as truth, later logic uses the corrupted history as evidence. The system does not merely remain wrong. It manufactures confirmation for its own mistake.

What the cases look like

These fixture cases exercise the decisions that used to share one return value:

Case	Observation	History	Verdict	Action
First valid poll	`200`, 20 items	None	`items_found`	Ingest and establish baseline
No newer content	`200`, 20 known items	Existing watermark	`no_new_items`	Record success and continue
Explicitly unchanged	`304`	Existing ETag	`no_new_items`	Poll normally
HTML instead of a known feed	`200`, bytes, parser error	Previously valid	`contract_failure`	Quarantine and alert
Zero items from a known active feed	`200`, zero items	Typical count: 20	`contract_failure`	Preserve baseline and investigate
Zero items from an unknown source	`200`, zero items	None	`undetermined`	Preserve state and observe again
DNS failure	Transport error	Any	`unavailable`	Backoff and thresholded alert
Rate limited	`429`	Any	`access_limited`	Respect retry policy
Retired endpoint	`410`	Any	`endpoint_gone`	Confirm, then disable

Rows five and six are the important pair. The current response is effectively identical. History changes what the system is justified in concluding.

A boolean cannot express that difference. Neither can None.

Five rules worth keeping

The implementation can change. The constraints should not.

First, the fetcher records and the adjudicator interprets. Mixing the two makes transport behaviour, parsing behaviour, and business policy impossible to test independently.

Second, every attempt produces an observation. Exceptions should enrich the record, not erase it.

Third, historical claims require history. Without a baseline, “changed” is not a conclusion you are entitled to make.

Fourth, uncertainty must be representable. If the type system only permits success or failure, ambiguous evidence will be forced into one of them.

Fifth, an uncertain or failed observation must not rewrite the state used to judge future observations. Durable state transitions need stronger evidence than temporary scheduling decisions.

This is not really about feeds

Pollers make the problem easy to see, but the same mistake appears everywhere.

A search returning no documents may mean there were no matches, the index is stale, a tenant filter was wrong, or the retrieval service failed. A queue consumer receiving no messages may mean the queue is empty, visibility is delayed, permissions changed, or the broker is unavailable. A monitoring query returning no datapoints may mean zero traffic, broken instrumentation, or a dead collector.

In each case, absence is an observation. It is not yet an explanation.

This matters even more in AI systems, where probabilistic components are often allowed to collapse ambiguous evidence into confident language. The governance layer around them should do the opposite. It should preserve distinctions, expose uncertainty, and restrict which conclusions are allowed to mutate state.

The implementation here is small. A few dataclasses, one explicit taxonomy, and a deterministic policy layer. The difficult part is resisting the convenience of pretending that None means one thing.

It never did.

Your AI Remembers Everything and Trusts All of It

marcosomma — Fri, 28 Aug 2026 14:27:09 +0000

I think we are still talking about AI memory in the wrong way. Most implementations are variations of the same pattern: store previous information, retrieve it later, inject it into the prompt, and call the result memory. That is useful, but architecturally it is not very different from leaving Post-it notes around your apartment and deciding the apartment now remembers things. The more I work with AI systems, the more I think memory should not belong to the model at all. It should belong to the system around the model.

The model should be able to disappear tomorrow while the history survives. Claude should be able to write something today, GPT should be able to read it tomorrow, a local model should be able to challenge it next week, and whatever model we use six months from now should still be able to understand why a stupid-looking workaround exists. That is the experiment I have been building: not “long-term memory” as another assistant feature, but a shared external memory layer for AI agents. The more I work on it, the more I suspect that the interesting problem is not memory itself. It is the economics of forgetting.

Models know a lot. They know absolutely nothing about Tuesday.

A modern model knows more programming languages than I ever will. It knows distributed systems, databases, React, Python, Rust, Kubernetes, obscure RFCs, and probably fifteen different ways to explain why my architecture is unnecessarily complicated. What it does not know is what happened in my project last Tuesday. It does not know that we already tried the obvious solution and it failed, that an ugly interface exists because three repositories still depend on it, or that a seemingly arbitrary convention is the result of a two-hour discussion nobody wants to repeat.

That distinction matters because this information cannot reasonably live in model weights. It is not general knowledge. It is history, or more precisely, state generated by work. This is also where I think the difference between RAG and memory becomes clearer. RAG usually retrieves information that already exists somewhere: documentation, code, tickets, policies, articles, database records. Memory should preserve information created by the process itself: why we chose A instead of B, why C failed, why we tolerate D, what changed after E, which assumption was temporary, and what the team learned after getting something wrong.

Those things are not always documents. In many cases they are exactly the information that should have become documentation but never did. A fresh AI session therefore pays for that missing history by rediscovering it from scratch. That is the part I want to attack.

So I moved memory outside the agent

The prototype is intentionally boring, and I mean that as a compliment. There is a small HTTP memory hub shared by a team. Memories are plain Markdown files with structured metadata, split between general knowledge and project-specific knowledge. Every AI session gets access through its own MCP server and a very small tool surface: list what exists, pull what is relevant, and push something new.

The important part is not the MCP plumbing. It is the boundary. The model is not the memory store, the client is not the memory store, and the MCP server is not the memory store. Memory exists independently of all of them. When a session starts, it receives a small index so it knows what memories are available, but the full content enters context only when the agent deliberately asks for it.

That distinction matters because a bad memory architecture can easily become a very expensive way of shouting your entire company history into every prompt. That is not memory. That is context pollution with good branding. I want the agent to know that the past exists without forcing the entire past into every interaction. It might see that there is a memory about a failed migration, a client-specific constraint, or the reason an API looks strange, and then decide whether any of those facts matter for the task in front of it.

This creates what I think of as a retrieval economy for memory. The index is cheap and the details cost context, but there is an ugly assumption hidden inside that sentence: the agent has to pull the right memory. Today the prototype mostly delegates that choice to the model using the descriptions in the index. That is not a solved retrieval system. It is a deliberately primitive baseline. A memory that exists but is never retrieved is functionally forgotten, while pulling irrelevant memories is just context pollution with extra steps. Retrieval precision and recall therefore have to become part of the evaluation, not something I quietly smuggle into the phrase “the agent decides.”

None of this makes external memory a new idea. MemGPT already framed long-running agents around hierarchical memory and virtual context management, Letta has pushed that line into a stateful-agent platform, and the official MCP examples include a persistent knowledge-graph memory server. The interesting question for me is narrower: what changes when the memory is team-scoped rather than assistant-scoped, plain-text and portable across clients, and every memory carries an explicit trust state instead of being treated as automatically authoritative? I am not trying to invent memory. I am trying to find the organizational boundary where it becomes useful infrastructure rather than another assistant feature.

Memory without provenance is just a hallucination with a pension plan

Once agents can write persistent memory, another problem appears immediately: why should the next agent trust what the previous one wrote? Imagine an agent stores the sentence “Always use Redis for this component.” Was that an explicit team decision, something inferred from the current code, a temporary workaround, or a confidently wrong conclusion that happened to survive the session? Persistent memory without provenance is dangerous precisely because bad information does not disappear with the conversation. It gets to retire inside your infrastructure and mislead future agents indefinitely.

So in this system a memory is a report, not an instruction. An unreviewed memory effectively means, “Agent X said this was true at time Y.” It can be useful, but it is weak evidence and should be checked against code, plans, or the user before it drives a consequential decision. A reviewed memory carries stronger authority, and if an AI changes it the review state disappears unless a human reaffirms it. The model cannot silently rewrite approved history and keep the approval badge.

There is an obvious trap here: if every memory needs a human to approve it, I have simply rebuilt the documentation bottleneck one layer later. That would completely undermine the write-side economics I am arguing for. So review cannot be the write path. It has to be a promotion mechanism. Agents should be able to create low-trust memories cheaply; only the smaller subset that becomes stable project guidance should consume human review. Whether that trust ladder scales is still unproven, but at least the economics are coherent: humans curate authority rather than manually authoring the historical trace.

This sounds administrative until you think about what persistent AI memory means. Once information survives across sessions, trust has to survive with it. A useful memory needs authorship, age, context, a reason for existing, and some relationship to a source of truth. It also needs to remain challengeable. Otherwise we are not building organizational knowledge. We are building a database of confident sentences, and the internet has already demonstrated that this is not automatically the same thing.

The annoying thing about memory is that it gets old

Most AI memory demos look excellent because they last fifteen minutes. You store something, retrieve it, the model remembers, and everybody goes home happy. Leave the same system running for six months and the experiment becomes less photogenic. Projects change, APIs move, people reverse decisions, and a memory can remain perfectly retrievable while becoming completely false.

For that reason, the hub tracks age and flags old memories as stale. If a memory makes claims about code, the agent is explicitly reminded to verify those claims against the current implementation. I deliberately do not auto-delete old memories because age is not truth. A four-year-old architectural decision may still explain why half the system looks the way it does, while a memory created this morning may already be nonsense. Age should affect confidence, not existence.

This pushes the design away from the usual cache mentality. A cache asks whether a value can still be reused. Memory asks a harder question: how much should I believe this now? That distinction becomes important once the store contains months of decisions made by different agents under different assumptions.

The organizational value is obvious. The economics are not.

The attractive pitch is easy to see. Imagine joining a project and asking an AI agent, “Why does this system look like this?” Today it can inspect the repository and explain what exists. With memory, it could potentially explain why it exists: why a provider was rejected, why a migration failed, or why a “temporary” compatibility layer is now entering its third year of life.

The real architecture of a system is only partially visible in the code. The rest is distributed across Slack threads, meetings, abandoned branches, and one engineer saying, “Do not touch that. There was a reason.” Unfortunately, we have been selling the cure for this for twenty years. Wikis, Confluence, ADRs, internal portals. Each generation was definitely going to save us this time.

They all run into the same economic problem: the person writing the documentation pays the cost while somebody in the future receives the benefit. AI agents may change that because the agent is already present when the work happens. It saw the files, the failed approach, the correction, and the reason the decision changed, so producing a compact memory has almost zero marginal cost.

That is much more interesting than saying AI can read documentation. The possibility is that AI creates a historical trace as a by-product of doing the work instead of requiring humans to document everything afterwards. If that holds, agents change the write-side economics that killed many previous knowledge-management systems. But “if” is doing serious work in that sentence. I have not proved it.

What the prototype proves, and what it absolutely does not

The prototype works end to end. External text memory can live independently of the model. Different clients can use the same store. Memories can be selectively injected into fresh sessions. Writes can be structurally validated, provenance can be enforced by infrastructure, and stale information can be surfaced instead of silently trusted. That proves the substrate is viable.

It does not prove the substrate is useful. Those are very different claims, and AI engineering has suffered enough from building a demo on Tuesday and announcing a new form of intelligence on Wednesday. A working memory API proves that an agent can retrieve previous state. The claim that actually matters is whether the agent produces better work because that state exists.

Memory has costs. It consumes context, retrieval adds latency, weak memories can bias reasoning, and stale memories can push an agent toward obsolete assumptions. A perfectly functioning memory layer can therefore become an efficient system for importing yesterday's mistakes into today's session. The architecture only creates value if the exploration and correction it avoids are more expensive than the memory overhead it introduces.

This is where my own hypothesis changed. I initially thought the obvious win would be cheaper sessions. A memory-enabled coding agent should need fewer tokens because it would not have to rediscover the repository every time. Nice theory. Then I thought about it for more than five minutes, which unfortunately ruined it.

The real cost may be the exploration tax

A memory-enabled session may actually use more tokens. It receives an index, pulls memories, interprets provenance, verifies stale claims, and may still inspect the same source files afterwards. If I measure only API spend, I can easily imagine the result being neutral or even slightly worse. But API spend may be the wrong place to look for the economic benefit.

Every fresh coding agent enters a repository with a mild form of professional amnesia. It searches the code, reconstructs the architecture, discovers conventions, tries something, finds out why it does not work, and then another session arrives tomorrow and repeats a smaller version of the same archaeological expedition. The expensive part is not always the tokens consumed during that exploration. The expensive part is having a human explain the same thing again: we cannot change that response format, we already tried that migration, this service behaves differently because of a client constraint, yes I know this looks wrong, no please stop refactoring it.

At some point you realize that the organization is continuously paying to rediscover information it already paid to discover. That is the exploration tax. Memory does not need to eliminate it completely to be valuable. It only needs to reduce enough repeated investigation, wrong turns, and human correction to justify its own overhead.

That also changes what the experiment should measure. The comparison I care about now is the same repository, the same model, and matched tasks under two conditions: memory hub enabled and memory hub disabled. Then I want to measure token usage, yes, but also wall-clock time to an acceptable result, the number of human corrections required, the number of repeated wrong paths, and how often the agent violates known team decisions.

My current prediction is slightly inconvenient for my original argument. Token usage may be roughly neutral, or even a little worse, while human corrections and repeated architectural mistakes decrease. If that happens, the memory system is economically useful even if the API bill barely moves. An engineer-hour is still considerably more expensive than asking a model to read another thousand tokens.

The strongest pitch may therefore not be “AI sessions become cheaper.” It may be something much less futuristic and much more useful: AI sessions stop relitigating settled decisions.

The experiment I cannot speed up

There is one evaluation I cannot fake very convincingly: time. Right now the store is young and relatively clean. The interesting failure modes appear when contradictions accumulate, two agents describe the same event differently, the project evolves faster than the store, and one bad assumption survives long enough for five later memories to depend on it.

At that point the system stops being merely a retrieval layer and becomes a knowledge-maintenance problem. Provenance, staleness, consolidation, contradiction handling, and eventually forgetting all start to matter. Unfortunately there is no credible benchmark switch called --simulate-six-months-of-organizational-chaos. The system has to get old enough to become annoying before I can learn whether it survives real use.

Why plain text may be the most important boring decision

The part I still find most interesting is portability. These memories are plain text. They are not model-specific hidden states, not vectors that only make sense inside one embedding space, and not some proprietary “persistent cognitive representation.” Text is aggressively boring, which is exactly why I like it.

Claude can create a memory and GPT can read it. A local model can disagree with it. A model that does not exist yet can inherit the same project history. This does not make models interchangeable. Different models will interpret the same memory differently, notice different things, reason differently, and make different mistakes. The weights still matter enormously. But the history no longer disappears when the model changes.

That creates a separation I think will become increasingly important. Models can become replaceable compute while memory becomes persistent organizational state. Companies are already moving between providers, mixing local and hosted models, and allowing multiple agents to work on the same systems. We usually talk about interoperability in terms of tools and protocols. Shared memory may turn out to be another part of that layer.

Maybe this is not really an AI memory problem

I started this experiment thinking about how to give AI better memory. I am becoming less convinced that AI is the interesting part. Software teams forget why decisions were taken, why approaches failed, and which apparently stupid implementation exists because the cleaner version already exploded once. Six months later, someone “fixes” it and rediscovers the same problem in production.

Humans compensate with documentation, experience, and the one engineer who remembers where all the bodies are buried. Every fresh AI session arrives without that accumulated history, but agents are also present while the work happens and can leave a structured trace for whoever comes next. If that trace remains retrievable, auditable, portable, and resistant to stale nonsense, memory stops being an assistant feature and starts looking like infrastructure.

I have proved that the infrastructure can exist. I have not proved that retrieval will stay reliable, that the trust model will scale, or that the organizational savings will exceed the overhead. That part needs data, model swaps, real use, and probably six months of my own system finding increasingly creative ways to prove me wrong.

I Write Less Code Than I Used To. That May Be the Point.

marcosomma — Wed, 19 Aug 2026 11:08:16 +0000

Over the last year, my day-to-day job has changed in a way I am still trying to understand. I am still an engineer. I still design systems, read code, debug failures, review implementations, and sometimes build things myself. But I write much less code than I used to, and that feels weird.

For most of my career, producing software was the visible evidence that I was doing my job. You had a problem, you designed a solution, you wrote the code, and something that did not exist in the morning existed by the end of the day. There was a very direct relationship between effort and output.

Today, that relationship is disappearing.

A large part of the implementation work around me can now be generated by AI. Not perfectly, not autonomously, and not without supervision, but cheaply enough that the first implementation is increasingly not the hard part. If I need an API endpoint, a migration, a data transformation, a test suite, an integration, or some internal tooling, I can describe the problem, provide enough context, and get a plausible implementation surprisingly quickly.

The expensive part starts afterwards: does it actually work?

Not simply, "does the code run?" or "do the tests pass?" The real question is whether the feature behaves correctly across the range of situations we actually care about. That question has slowly become a much larger part of my job, and it has changed how I think about my own value.

A year ago, I spent much more time thinking about how to implement something. Now I spend much more time thinking about how it can fail. What happens when the model receives something we did not anticipate? When two components disagree? When an apparently good answer contains the wrong evidence? When the evaluator itself is biased? What happens when a model succeeds 95 percent of the time, but the remaining 5 percent contains exactly the failures that matter to the business? What happens when a fallback silently changes provider, region, latency, cost, or behavior? What happens when everything returns HTTP 200 and the system is still wrong?

The implementation is often no longer the difficult intellectual problem. Failure detection is. Failure prevention is. Defining what "good enough to ship" actually means is.

That creates a strange inversion. For decades, software engineering treated testing and validation as something downstream of implementation. First you built the thing, then someone checked whether it worked. In AI systems, I increasingly feel the opposite. Generating the implementation is becoming cheaper, while knowing whether you should trust it is becoming more expensive.

This week, for example, after I take some time off, the team asked me for a new evaluator for a feature. At first glance, that sounds almost like QA work, and I admit that part of me reacts negatively to that idea. I spent years learning how to build software. Am I slowly becoming the person who checks everybody else's work?

But I think that interpretation misses what is actually happening.

The hard part of building an evaluator is rarely writing the evaluator. AI can help enormously with that too. The difficult part is deciding what the evaluator should measure in the first place. What counts as failure? Which failures can be checked deterministically? Which ones require statistical evaluation? Which dataset represents reality well enough? Where are the blind spots? Can the evaluator itself be fooled? Are two supposedly independent checks actually making the same mistake? What threshold is sufficient to release something to production?

Those are not really questions about test implementation. They are questions about the operational definition of correctness. And with AI, correctness is becoming something we have to engineer.

Traditional software gives us a relatively comfortable contract. For the same inputs and state, deterministic software should generally produce the same output. LLMs break that assumption. They generate plausible outputs across enormous input spaces, and they can produce something structurally correct, linguistically excellent, internally coherent, and completely wrong.

So we wrap them in software. We constrain them, validate their outputs, compare signals, build fallback paths, add deterministic checks around probabilistic behavior, create evaluation datasets, measure regressions, and observe production traces. Then, inevitably, we discover a failure mode we did not know existed and modify the system again.

A surprising amount of my work now lives in that boundary. Not creating intelligence, but making probabilistic intelligence reliable enough to become part of a real product.

This also makes me uncomfortable for another reason. If AI can generate the implementation, why couldn't another AI eventually generate the evaluations too? Why couldn't I describe my principles, my distrust, my way of looking for edge cases, and encode all of that into another agent?

The answer is probably that I can. And I should.

If I discover a reliable failure pattern, I want to automate its detection. If I repeatedly perform the same review, I want a system to perform it for me. If a deterministic gate can replace my manual judgment, building that gate is progress. My value cannot depend on protecting tasks from automation, because that would be a losing strategy.

So perhaps the important distinction is not between work humans can do and work AI can do. It is between known problems and unknown ones.

Once a failure mode is understood, it becomes cheaper. We can encode it in a test, build an evaluator, add a policy, or teach an agent to look for it. The difficult part then moves somewhere else. The frontier becomes the next thing we do not yet know how to measure, and that seems to be where more and more of my work is going.

My output is increasingly not code. It is a definition, a constraint, an architecture, a failure taxonomy, a release criterion, or a deterministic guard around something probabilistic. Sometimes the final artifact is twenty lines of code, but those twenty lines may represent two days of thinking about what exactly needs to be prevented.

That changes how productivity feels. If I generated 1,000 lines of production code in a week, I could easily point at what I created. If I spend the same week investigating one subtle failure mode and eventually add a tiny check that prevents it, the visible output looks much smaller. But the economic value might be significantly larger.

The system already knows how to generate. The harder question is whether we can depend on what it generates.

I do not know exactly what this role should be called yet. AI engineer still fits. Reliability engineer fits part of it. Architecture fits another part. Evaluation engineering is clearly becoming important. None of those labels completely captures the transition I am experiencing.

What I do know is that I am moving away from being primarily the person who produces the implementation. I am becoming the person who asks what the implementation must prove before we trust it.

That feels strange because software engineering trained us to identify ourselves with building. Code was craftsmanship, output, and evidence that we were useful. AI is making code abundant, and when something becomes abundant, value usually moves somewhere else.

Maybe the next scarce resource in software engineering is not implementation. Maybe it is the ability to determine when an implementation is wrong before reality does it for you.

The cheaper part is increasingly generated. The expensive part is knowing where it will fail, and making sure it doesn't.

Human concept, nice written by AI.

The Model Does Not Need Memory. The Situation Does.

marcosomma — Mon, 29 Jun 2026 11:50:14 +0000

I think I was asking the wrong question.

For a while, the question was simple: does memory make agents smarter?

It sounds like the right question. It is also a trap, because it assumes that memory should be judged as a generic intelligence booster. You add a memory layer, the agent remembers more things, and somehow the output should become better. More complete. More accurate. More human. More whatever word we are currently using to avoid saying “I hope this expensive thing works.”

After running more experiments, I think that framing is wrong.

Memory does not make the model smarter in any general sense. Most of the time, it cannot. The model already has a massive amount of general procedural and domain knowledge compressed into its weights. If your memory layer recalls information the model already knows, you are not adding intelligence. You are just adding a second path to say the same thing with more latency.

That is the uncomfortable part. A lot of agent memory systems are not failing because recall is broken. They are failing because the recalled information has no marginal value.

They are giving the model something it was already going to do.

The experiment was not a victory lap

I ran a follow-up benchmark on OrKa Brain: 250 tasks, five tracks, brain versus brainless. The point was to see whether procedural memory would show stronger results at scale and across more task types.

It did not.

The absolute rubric score was almost flat. Brain scored 8.39. Brainless scored 8.27. That is a +0.12 difference on a 10-point scale. Technically positive, but not the kind of result you use to announce that persistent memory has unlocked a new era of agent intelligence unless your relationship with evidence is mostly decorative.

The pairwise result looked slightly better at first. Brain won 53.8% of the comparisons. But then the judge showed a 74.4% first-position bias, which means the raw pairwise score was not something you can read directly. If the judge picks the first answer almost three times out of four, the measurement instrument is not exactly wearing a lab coat. It is flipping a biased coin and writing a confident explanation afterward.

Once I controlled for position, most of the supposed Brain advantage disappeared. Cross-domain transfer did not survive. Anti-pattern avoidance did not survive. Multi-skill composition collapsed into a coin flip. Routing was confounded and needs to be re-run.

Only one track survived: the long same-domain sequence. In that track, the Brain won 74% of the time even when placed in the disfavored position.

That is the part worth keeping.

Not because it proves that memory works in general. It does not. It proves something narrower and more useful: memory seems to help when the output depends on previous state in the same evolving situation.

That is a very different claim.

The ceiling was the message

At first glance, you could say the Brain failed. I think that is too easy.

The better reading is that the benchmark exposed the wrong class of memory. Most of what OrKa Brain recalled was procedural knowledge: how to decompose a task, how to reason through trade-offs, how to avoid generic mistakes, how to structure a solution, how to transfer a pattern from one domain to another.

The problem is that capable LLMs already know a lot of this. They have seen endless examples of architecture reviews, debugging sessions, migration plans, support flows, project retrospectives, Stack Overflow arguments, incident reports, code reviews, framework docs, and corporate documents that somehow use five pages to say “we forgot the cache.”

So when the memory layer recalls a generic procedure, the model does not suddenly receive missing information. It receives a reminder of something already present in the weights.

That is why the ceiling effect matters. It is not just an implementation failure. It is a category warning. If memory stores general competence, the model can often route around it because the model already has general competence.

This is why “agent memory” can look impressive in demos and then become strangely weak in benchmarks. In a demo, remembered context feels useful because we can see the system referencing the past. In a benchmark, if the remembered thing does not change the answer, the effect disappears into style, verbosity, or judge preference.

The useful question is not “did the system remember something?”

The useful question is “did the remembered thing contain information the model could not have known or safely inferred?”

That is the line.

Memory is for contingent information

The sharper version of the theory is this:

Memory helps when the answer depends on contingent information absent from the model weights.

Not vertical knowledge. Not domain knowledge. Not “more context” as a generic spell. Contingent information.

By contingent, I mean information whose truth depends on a specific user, system, company, customer, codebase, previous decision, local process, or moment in time. It is information that is not true in general. It is true here.

The model can know how software migrations usually fail. It cannot know that in this codebase, the last migration failed because the billing worker silently depended on a deprecated Redis key.

The model can know what concise writing is. It cannot know that a specific user prefers direct technical answers with no filler, no fake enthusiasm, and no corporate perfume sprayed over the paragraph.

The model can know how customer support triage works. It cannot know that this specific customer always reports billing bugs using the wrong product name.

The model can know how a deployment pipeline usually works. It cannot know that this team avoids Friday releases because one rollback path still depends on a manual script nobody wants to admit exists.

That is memory.

Everything else risks becoming a second copy of generic knowledge attached to a model that already has the first copy.

Codebase AI makes the distinction obvious

Take software engineering, because the mistake becomes very clear there.

A naive approach says: “We need memory so the model knows how to code.” That sounds reasonable until you look at what the model already knows. A capable model has broad exposure to programming languages, design patterns, API conventions, testing strategies, refactoring techniques, infrastructure patterns, and the usual graveyard of best practices everyone quotes and half the industry ignores.

If you use memory to teach it generic software knowledge, you may hit the same ceiling as procedural memory. The model already knows that functions should be small, tests should cover edge cases, migrations should be reversible, and distributed systems enjoy ruining your afternoon. Storing those ideas as memory does not add much. It mostly gives the model a slower way to say what it was already going to say.

The problem is not that the model does not know software engineering. The problem is that it does not know this software system.

That means generic engineering knowledge should not be treated as the valuable memory layer. It is already in the model. The valuable layer is the local shape of the codebase: naming conventions, architectural scars, forbidden dependencies, deployment constraints, hidden coupling, flaky tests, internal abstractions, legacy decisions, and the reason why one ugly function must not be “cleaned up” unless you enjoy incident reports.

The job of repository retrieval is not to remind the model what clean code is. The job is to show it what this codebase actually is.

The model can know how authentication usually works. It cannot know that in this system, the admin role is duplicated across two services because a migration was only half-completed in 2022.

The model can know that Redis keys should have clear ownership. It cannot know that billing still depends on a deprecated cache key because one worker was never moved to the new event pipeline.

The model can know how to write a database migration. It cannot know that this team avoids destructive migrations unless the rollback plan is reviewed by the person who still remembers why the old schema exists.

That is where memory earns its keep.

A style guide tells the model how code should look. Repository history tells it why the code looks wrong but still works. Incident memory tells it where the bodies are buried. Team conventions tell it what changes will be accepted or rejected before CI even has the chance to complain.

Those are not the same layer, and treating them as one generic RAG pile is how you get a system that retrieves a lot and understands very little.

In software products, this distinction matters. Documentation grounds. Repository state shapes. Incident and decision history constrain.

If those three jobs are mixed together, the assistant may still sound like a senior engineer. It may even sound more senior than before, which usually means it has learned to say “trade-off” with confidence. The question is whether it understands the specific system in front of it.

That is where memory stops being decoration and starts being useful.

Chat memory is the same pattern

This is not only a codebase problem. Chat memory shows the same structure in a smaller and more familiar form.

When a system remembers that a user wants concise answers, it is not helping because the model lacked the concept of concision. The model knows how to be concise. The useful information is not “what does concise mean?” The useful information is “what does concise mean for this user?”

That is an entity-bound fact. It attaches a general capability to a specific person.

This is why personalization can be useful without being intellectually deep. The value is not in teaching the model a new writing style from scratch. The value is in selecting the right behavior under a known identity.

The same thing happens inside companies. The model knows how to review code, but it does not know that this repository bans a specific library because it caused a production incident three years ago. The model knows how to process refunds, but it does not know that annual partner contracts have a different refund path. The model knows how to summarize a customer complaint, but it does not know that this customer always describes production incidents as “minor issues” because they are polite to the point of self-sabotage.

That local weirdness is not noise. It is the work.

Real systems are not made only of general rules. They are made of exceptions, scars, habits, conventions, previous mistakes, policy shortcuts, undocumented dependencies, and things everyone knows until the one person who knows leaves the company.

That is the material memory should store.

Not generic competence. Operational sediment.

This changes the architecture

My earlier framing was closer to skill reuse. The agent learns a skill, stores it, recalls it later, and applies it to a new task. It is a clean model. It is also suspiciously diagram-friendly, which should always make us nervous.

The data pushes me toward a different architecture.

A memory system should not start by asking, “What skill is similar to this task?” That can work sometimes, but it is too weak as the central retrieval principle. Similarity is not the same as necessity. A memory can be semantically close and still useless if it does not change the answer.

The better retrieval question is: “What information about this situation would be impossible, unsafe, or expensive for the model to infer?”

That question changes everything.

You retrieve because the task depends on a known entity. You retrieve because the answer varies by product, customer, repository, environment, deployment target, or team convention. You retrieve because the user has stable preferences. You retrieve because the codebase has local rules. You retrieve because the customer has a history. You retrieve because the system has failed before in a way that looks relevant now. You retrieve because the model is about to answer with generic competence where specific state is required.

That is a different trigger from semantic similarity.

The trigger is underdetermination. The model can produce an answer, but the answer is not sufficiently determined by the prompt and general knowledge. It needs local state.

This also means memory should not be one bucket. A serious system probably needs separate stores with separate jobs.

Grounding is for authority. It gives the model exact sources, current docs, repository files, API contracts, schemas, config, and verifiable references.

Operational knowledge is for local shape. It tells the model how this product, repository, customer, workflow, team, or deployment environment behaves.

Episodic memory is for history. It tells the model what happened before with this user, customer, task, session, service, or system.

Reasoning composes the three.

When people collapse all of this into “memory,” they make the system harder to evaluate. They also make it easier to fool themselves, which is apparently the default MLOps workflow whenever agents are involved.

The next benchmark should be crueler

The old question was whether memory improves output quality. That is too broad.

If the model can answer well using general competence, memory will struggle to show a large effect. A judge may prefer one answer over another, but you will end up measuring style, verbosity, formatting, position bias, or the judge’s breakfast.

The next benchmark should make memory necessary.

A task should require a fact that exists only in memory or grounding. Without that fact, the model should either fail, hedge, or produce a generic answer. With that fact, the model should answer correctly.

Not more beautifully. Correctly.

For a chat assistant, the answer might depend on a stored user preference. For a code assistant, it might depend on a repository-specific rule, a past incident, a banned dependency, a migration constraint, or a team convention that exists nowhere in the model weights. For support automation, it might depend on a customer-specific exception, a product-plan quirk, or a previous escalation pattern. For routing, it might depend on a previous failed path inside the same system.

The score should not be “which answer feels more complete?” That is how judge bias walks into the room, sits at the table, and starts grading vibes.

The score should be concrete. Did the system use the right repository rule? Did it respect the deployment constraint? Did it remember the user preference? Did it avoid the known failure path? Did it cite the current internal document? Did it preserve the prior product decision? Did it distinguish generic knowledge from contingent state?

That is where memory should show a real gap. Not a +0.12 polish gap. A correctness gap.

If memory cannot win there, then the memory system is probably not doing much. If it does win there, then the value is no longer mystical. It is measurable.

The anti-hype version

I do not think “memory makes agents smarter” is the right claim. It is too vague, and vague claims are where AI hype goes to reproduce.

The sharper claim is less exciting but more useful: memory helps when the task depends on information that is not in the model weights and cannot be safely inferred from general knowledge.

This explains why generic procedural recall barely moved the needle. It explains why long same-domain recall was the only signal that survived. It explains why chat preferences matter. It explains why code assistants need repository state plus decision history, not just more documentation. It explains why enterprise assistants become useful only when they know the local weirdness of the company.

The model already has the average.

Memory is for the deviation.

And most real work is deviation.

That is the part I think we keep missing. We keep building memory systems as if the model is empty and needs to be filled. But the model is not empty. It is full of averages. Full of general patterns. Full of plausible procedures. Full of the kind of answer that is usually right until it meets a real organization, a real customer, a real codebase, or a real human being with preferences that do not fit the median.

Memory is not there to compete with pretraining.

Memory is there to correct the average when the local situation demands it.

The boundary I would use now

I would draw the boundary like this.

Do not store what the model already knows. Do not retrieve what the model can safely infer. Do not call generic advice memory. Do not confuse domain knowledge with contingent state.

Store the things that change the answer because they are specific, current, local, personal, historical, procedural, repository-bound, customer-bound, product-bound, or system-bound.

Use grounding for authority. Use memory for contingency. Use reasoning for composition.

Mixing those three together is how you build a very expensive autocomplete with a scrapbook attached.

The benchmark did not prove that memory is useless. It proved that memory has to earn its place. If the remembered thing does not change the answer, it is not memory in any meaningful operational sense. It is just noise with a timestamp.

The model does not need memory.

The situation does.

Maybe It Is Not Yet Time To Bring Every AI Demo To Production

marcosomma — Tue, 23 Jun 2026 14:26:29 +0000

There is a sentence I keep hearing in AI engineering that sounds innocent, practical, and mature: “Just add a fallback provider.”

Clean. Elegant. Wonderful. The kind of sentence that usually survives only until production starts touching it. Because in a demo, fallback means: Provider A fails, call Provider B. In production, fallback means something very different.

Will Provider B interpret the prompt in the same way? Will it serialize the tool schema in the same way? Will it respect cache directives in the same way? Will it stream tokens in the same way? Will it expose errors in the same way? Will it count tokens in the same way? Will it respect timeouts in the same way? Will it fail in a way your system can actually understand?

Most of the time, the answer is no.

And this is where the current AI industry keeps doing its favorite magic trick. It takes something deeply unstable, wraps it in a familiar API shape, gives it a shiny compatibility label, and suddenly everyone behaves as if we have a standard. We do not have a standard. We have a costume!

Most of famous “OpenAI compatible" APIs are laying, and hiding the lack of standards behind a known name. In reality the is compatible only on the shallowest path. You can send a basic chat request and get text back. Fantastic. The demo works. The slide looks good. The architecture diagram has fewer boxes. But the moment you move beyond “hello model, summarize this paragraph”, things start to fracture.

Tool calling. Structured output. JSON enforcement. Prompt caching. Streaming. Retry behavior. Usage accounting. Model aliases. Safety overlays. Regional routing. Timeout semantics. Error objects. Response envelopes. Context handling. Provider-specific parameters. All the boring parts. In other words, all the parts that decide whether your AI system survives production.

As we know, the demo works because the demo is NOT the system

The demo is usually a happy path. One user. One model. One provider. One prompt. One task. Maybe no cache. Maybe no concurrency. Maybe no structured output. Maybe no audit trail. Maybe no fallback. Maybe no customer-specific version pinning. Maybe no compliance requirement. Maybe no cost pressure. Maybe no incident where several parallel streams connect and then produce absolutely nothing for two minutes.

In that world, AI feels magical. In production, AI feels like distributed systems decided to have a child with legal ambiguity and probabilistic behavior.

You are not only integrating a model. You are integrating a runtime. And that runtime is usually not specified clearly enough. This is the part people keep missing.

The model is not the full product. The provider’s serving stack is part of the product. The SDK is part of the product. The serialization layer is part of the product. The cache implementation is part of the product. The safety wrapper is part of the product. The regional routing strategy is part of the product.

So when someone says, “it is the same model”, I increasingly hear: “we did not measure the parts around the model.”

Same weights do not mean same behavior. Same model family does not mean same production contract. Same endpoint shape does not mean same system.

Same model, different reality

One of the strongest examples I have seen came from a direct comparison between Provider A and Provider B using the same model family on real production-like workflows. The headline looked simple: same model family, different provider path. The result was not simple.

On Workflow 1, the quality regression was statistically significant. Provider A had a mean score of 0.716. Provider B had a mean score of 0.497. The p-value was below 0.0001, with a medium effect size. That is not “a bit of noise.” That is the kind of difference that should stop a migration.

The interesting part is that not every workflow regressed. On Workflow 2 and Workflow 3, the result was basically fine.

Good. That makes the result more credible, not less. Because real provider migrations do not fail everywhere. They fail in specific workflows, specific prompts, specific schema paths, specific flows, specific edge cases. The average can look acceptable while one critical workflow quietly gets worse.

This is exactly why “we tested a few prompts manually and it looked okay” is not engineering. It is theater with curl commands.

If you want to switch provider, you need replay traces. You need evals. You need per-workflow scores. You need statistical comparison. You need to know where the behavior changed, not just whether the model still speaks fluent corporate English.

Cost is not only list price

The same comparison showed around a 2x cost premium on a high-volume workflow. At first glance, you might blame provider pricing. But the back-calculation pointed somewhere more boring and more dangerous: prompt caching.

On Provider A, implied token volume was 60 to 67 percent below reported tokens. That is the cache signature. You are still sending the structure, but you are not paying the full input cost every time because the provider is reusing cached prompt blocks.

On Provider B, one high-volume path showed exactly 0 percent gap. Cache was either off or always missing. Other paths showed partial cache behavior, around 14 to 21 percent in one case and around 33 percent in another.

Same model family. Different cache reality. Different bill. This is where the “just switch provider” crowd usually becomes very quiet.

Because caching is not decoration. In high-volume AI systems, caching is part of the economic architecture. If cache semantics change, your unit economics change. If regional routing causes cache misses, your cost model changes. If one provider respects cache directives differently from another, your production bill changes while every individual request still “works.”

That is the worst kind of failure. The successful one. No exception. No stack trace. No screaming service. Just a quiet invoice telling you the abstraction was fake.

Cross-region cache is a beautiful little trap

Cross-region inference sounds robust. More regions. More availability. More resilience. Then you look at the cache behavior.

A request served in Region A writes a cache in Region A. The next request may route to Region B. Region B does not have that cache. So it misses and writes again. Then another call may route back to Region A, or somewhere else, depending on capacity and routing.

This is not a clean “double pay” situation. It is worse conceptually. You keep paying the cache write premium without reliably amortizing it through cheap cache reads. That is how you can end up with a measured 0 percent hit rate while thinking you configured caching correctly.

Again, from the outside everything looks compatible. The API accepts your request. The model responds. The integration works. Except the economics are different because the serving layer changed.

This is why AI production work is becoming less about prompts and more about contracts. What exactly is guaranteed? What is pinned? What is regional? What is cached? What is counted? What is replayable? What is stable?

If the answer is “trust us, it is compatible”, my engineering translation is simple: no contract found.

Reliability is not portable either

Another production-style incident: under concurrency, multiple parallel streams connected and then produced nothing for roughly two minutes. No tokens. No useful error. Just waiting.

The likely reading was capacity or throttle queueing. The provider may have been holding the request instead of returning a clean throttling response. Depending on the endpoint, one path may queue in-flight work while another may throw a clear rate-limit error.

That distinction matters. A clear rate-limit error is ugly but useful. You can react to it. You can retry with backoff. You can trigger fallback. You can protect the system. A connected stream producing nothing for two minutes is a different species of failure. Your system is alive enough to wait and dead enough to be useless.

There was also a competing hypothesis: maybe the network layer was involved. Gateway behavior, private endpoints, load balancers, idle timeouts, streaming connection drops, or capacity errors could all produce overlapping symptoms.

So the correct response was not “the provider is bad.” The correct response was: inspect runtime metrics during the hang windows. Check throttle counters. Check server error counters. Check network timeouts. Check connection lifetime. Check whether the request reached the model runtime at all.

This is what production AI looks like. Not prompt magic. Not demo videos. Not “look, I built an agent in 20 minutes.” It looks like debugging whether a zero-token two-minute hang is caused by model capacity, runtime queueing, network infrastructure, streaming semantics, retry policy, or your own concurrency design.

Very glamorous. Someone should put that in the launch video.

Structured output is not standard output

Then there is the SDK serialization problem. Same model. Same app-level input. Different token count.

One comparison showed Provider B using around 10,473 input tokens while Provider A used around 10,019. That is a 454-token delta, roughly 4.5 percent.

The clue was structured output. On one provider path, structured output was implemented by injecting a tool schema into the prompt. On the other path, it was handled differently. Even after making payloads byte-identical at the application level, the remaining structural difference came from provider-specific cache directive serialization.

This is a perfect example of why API compatibility is not enough. Your prompt may be identical. Your provider prompt is not.

The actual thing seen by the model may include hidden scaffolding, injected schemas, translated parameters, safety wrappers, tool definitions, response constraints, or provider-specific envelopes. Then we compare eval scores and pretend we tested the same thing.

Did we? Maybe. Maybe not. And if we cannot answer that confidently, then we are not measuring model quality. We are measuring a mix of model behavior, SDK translation, provider scaffolding, and our own assumptions.

Very scientific. Very enterprise. Very “move fast and accidentally compare different systems.”

Fallback can become the outage

Cross-provider fallback sounds responsible. It can be responsible. But it is not free.

One concrete incident involved a preview model on Provider C. The model had intermittent hangs, produced retry-exhaustion errors after repeated timeouts, and reported zero input tokens and zero output tokens. So the model did not even really start.

The retry budget burned for several minutes. Then a failure-rate guard aborted the whole job. The fix was to add a fallback model. Good fix. But the lesson is bigger.

The fallback path needs its own engineering. It needs its own timeout budget. It needs its own cost assumption. It needs its own quality expectation. It needs its own reason to exist.

A useful rule: scale up on fallback by default. If fallback runs rarely, a usable answer matters more than saving a few cents. Scale down only when the primary failed because the request exceeded model limits.

But if your fallback inherits the same exhausted timeout budget from the primary, congratulations, you did not build fallback. You built a decorative second failure.

Fallback is not a backup model. Fallback is a second production path.

Even parameter names are not portable

Small example, but very revealing: a “compatible” API for a model behaved differently around a reasoning-related parameter. The workaround was to force a safe default.

That is reasonable. But the real portability risk is not only the value. It is the parameter contract itself.

Another provider may call it something else. Another may ignore it. Another may reject it. Another may apply a different default. Another may support it only on some models. Another may support it in preview and remove it later with very little warning.

This is where “compatible API” starts to feel like saying every car is steering-wheel-compatible. Technically true. Please do not use that as your safety case.

Preview is not production

A lot of AI teams are building production workflows on preview models, preview parameters, preview endpoints, preview SDK behavior, and preview pricing assumptions. Then they act surprised when preview behaves like preview.

Preview can mean weaker guarantees. It can mean limited support. It can mean behavior changes. It can mean short deprecation windows. It can mean different rate limits. It can mean hidden routing changes. It can mean features that work today and become “not recommended” tomorrow.

That is fine for exploration. That is not fine when your production system depends on it and nobody wrote down the risk.

Again, the issue is not that preview exists. Preview is useful. The issue is pretending preview is stable because the demo worked.

We need stable interfaces, not demo optimism

I am increasingly convinced that production AI needs something closer to long-term-support thinking.

Not because models should stop improving. They will improve. The field moves fast. Fine. But production systems cannot keep pretending that every model upgrade, provider switch, SDK change, cache behavior update, or model alias movement is harmless.

When a system is performing fine, switching the model or serving path can create more issues than benefits.

The defensible version is conditional: long-term support becomes inevitable when capability growth slows enough that stability outweighs the next incremental benchmark gain. At that point, many companies will not want the newest model. They will want the model-runtime contract that keeps working.

But the deeper point is that the thing needing long-term support is not only the model weights. It is the interface.

The stable surface must include serving stack, quantization, SDK behavior, tool serialization, cache semantics, timeout behavior, safety overlays, error formats, and versioned model aliases.

Maybe the real answer is not long-term-support models. Maybe it is long-term-support interfaces with deterministic check layers.

Swappable models behind a stable contract. Replayable traces. Eval gates. Schema normalization. Provider-specific adapters. Explicit cache tests. Timeout isolation. Failure-mode classification. Version-pinned prompts. Known fallback policy.

That sounds boring. Good. Production should be boring.

The problem is not that AI is useless

This is usually where someone misunderstands the argument. The point is not that AI is useless. The point is not that demos are bad. The point is not that teams should stop experimenting.

The point is that demos and production systems are different organisms. A demo proves possibility. Production requires repeatability. A demo proves that the model can answer. Production requires knowing what happens when it does not answer, answers differently, answers slowly, answers with a hidden schema injection, misses cache across regions, changes token accounting, streams forever, returns a provider-specific error, or silently regresses one workflow while improving another.

AI interfaces today are still too fragmented for the amount of confidence people are placing in them. We are building production systems on unstable runtime surfaces and pretending the abstraction is mature because the JSON shape looks familiar.

That is not engineering maturity. That is hope with headers.

So maybe not every demo belongs in prod yet

Maybe it is not yet time to bring every AI demo to production. Or more precisely: maybe it is not time to bring demos to production without first building the missing runtime layer around them.

Not another wrapper. Not another “universal SDK” that hides provider differences until they explode. A real layer. One that treats each provider as a different runtime with different semantics.

One that records traces. Replays production samples. Compares quality. Measures cost after caching. Tracks token deltas. Normalizes errors. Separates timeout budgets. Tests fallback paths. Pins model versions. Detects serialization drift. Audits structured output behavior. Makes provider migration observable before it becomes an outage.

Because changing provider is not changing a base URL. It is migrating the runtime contract of your AI system.

And if your system does not know what that contract is, then the provider switch is not a migration. It is an experiment in production.

Very innovative, yes. Also known in some older engineering traditions as a bad idea.

Am I Becoming Too Slow for the AI World?

marcosomma — Wed, 03 Jun 2026 17:30:38 +0000

The AI world is full of old infrastructure with stochastic organs.

That sentence probably explains better than anything why I feel slow lately. Not because I stopped caring about AI. Not because I cannot build anymore. Not because the tools moved beyond me. If anything, the tools moved in the opposite direction: they make me faster at generating code, faster at prototyping, faster at touching layers I would normally approach one by one.

And still, inside the work, I feel slower.

This is the uncomfortable part. AI gives me the sensation that everything should move faster, but the more I use it seriously, the more I end up spending time in the parts that do not accelerate cleanly. The code appears quickly. The draft appears quickly. The workflow appears quickly. But then I need to understand what it actually does. I need to test the boundary between components. I need to verify that the result is not just plausible, but correct enough to survive contact with reality.

Maybe this is the first real trap of AI development:

Creation became cheap. Verification did not.

That sounds simple, almost too obvious, but I think it is the reason many of us feel this strange mismatch between speed and exhaustion. We can now produce more surface area than we can comfortably inspect. A feature that would have taken days to sketch can appear in hours. A backend route, a frontend component, a prompt chain, a test, a deployment script, a workflow diagram: all of it can be generated quickly enough to create the illusion that the whole process compressed.

But the whole process did not compress.

The expensive part moved.

You still have to understand the system. You still have to validate the assumptions. You still have to test the end-to-end behavior. You still have to ask whether the thing is stable, maintainable, safe, observable, and aligned with the original intention. AI made the first draft cheaper, but it also made it easier to produce first drafts across more layers at once. So the final burden often becomes larger, not smaller.

Before AI, there was a natural friction in development. You wrote more slowly, so production and understanding were closer together. Now production can sprint ahead of understanding. You can build faster than you can digest. And once that happens, the bottleneck becomes obvious.

It is not typing.

It is not even coding.

It is judgment.

This is where my feeling of slowness begins. I am not slow in the part that AI is good at accelerating. I am slow in the part that matters after acceleration. I am slow when I need to decide whether a generated thing deserves to exist inside a system. I am slow when I need to move from “this works once” to “this is trustworthy enough to become infrastructure.”

That kind of slowness does not look good in a noisy field.

The AI world rewards motion. It rewards people who react quickly, rename quickly, package quickly, comment quickly, and post before the concept has cooled down. Every week there is a new model, a new benchmark, a new agent framework, a new “this changes everything” moment, a new tool that is apparently going to replace half the industry and then disappear into a GitHub archive two weeks later.

At some point, I became tired of chasing it.

Not completely. I still follow the field. I still care about what matters. But I no longer have the energy to treat every release, every demo, every thread, and every AI product with a gradient background as if it deserves my full attention. A proof of concept is not a product. A prompt chain is not cognition. A wrapper is not infrastructure. A dashboard is not an operating system for intelligence just because someone wrote “agentic” in the hero section.

After a while, the noise becomes expensive.

And when I stopped chasing every update, something strange happened. I did not become less interested in AI. I became more interested in older things.

Distributed systems. Permissions. Control loops. Network optimization. Separation of concerns. Routing. Handshakes. Feedback. Biological systems. Ant colonies. Viruses. Evolution. Complex adaptive systems.

The more I look at AI, the more I see old problems returning in a new substrate. Not copied perfectly. Not solved automatically. But returning. The same families of problems keep appearing under newer language. How do parts coordinate? Who is allowed to access what? Where does a decision happen? What happens when a component fails silently? How do you stop local uncertainty from becoming global corruption? How do you keep a system observable when some of its organs speak in probabilities?

That is why I keep saying that AI infrastructure often feels like old infrastructure with stochastic organs. The body is familiar. The organs behave differently.

And this is where I need to be more precise, because vague depth is too easy. Saying “old principles return” is not enough. It risks becoming another elegant sentence that avoids doing the actual work.

Take orchestration.

A lot of what people now call AI orchestration is not conceptually new. We already had coordination, routing, permissions, queues, retries, fallbacks, handshakes, separation of concerns, and validation boundaries. None of those appeared because LLMs arrived. They were already part of software, distributed systems, automation, and infrastructure engineering.

But the component changed.

A deterministic service fails in ways we can often reason about. A request times out. A schema breaks. A permission check rejects access. A queue stalls. A dependency returns an error. The failure may be painful, but at least it often announces itself.

A generative component can fail while sounding successful.

It can return a clean boolean and still be wrong. It can pass a check while carrying uncertainty underneath the return type. It can produce a fluent answer that looks like completion but is actually drift. It can say “yes” with confidence because the prompt, the model, and the input distribution all lined up toward the same blind spot.

That is the part that changes the orchestration problem.

The old principle still matters: boundaries are useful. Checks are useful. Separation of concerns is useful. Permissions are useful. But the error model under the boundary is different. A handshake with a stochastic component is not the same as a handshake with a deterministic one. The interface may look clean, but the uncertainty has not disappeared. It has been compressed.

This is why I do not think the right adaptation is simply “use AI, then check AI.” That is too soft. It sounds responsible, but it hides the important question: what kind of check, under what error model, with what independence assumptions?

Imagine a pipeline like this:

A > B > C > final check

If the final check passes, the system continues. If it fails, the system routes somewhere else. This is simple. It is also risky, because an early hallucination can travel through the whole chain before being inspected.

So we make the process more granular:

A > check > B > check > C > check > evaluate checks

That feels better, and in many cases it is better. Granularity gives the system a higher sampling rate. It interrupts compounding. It catches problems earlier. It lowers the impact of one local failure because the system becomes observable and interruptible at more points.

But it does not magically lower the uncertainty of the model.

It lowers propagated uncertainty. It lowers blast radius. It lowers the chance that one bad step contaminates everything downstream. Those are real gains.

But the atomic uncertainty remains.

And here is the part I think matters more than the usual AI safety slogan: more checks do not help much if all the checks share the same blind spot.

Classical retry logic quietly assumes some degree of independence. If a service call fails because of a transient network problem, trying again may work. If a worker crashes because of temporary load, retrying elsewhere may work. The same idea often gets imported into AI workflows without being inspected: ask again, check again, validate again, add another gate.

But generative errors are often correlated.

The same model, with the same prompt family, reading the same kind of input, can reproduce the same wrong conclusion several times. A pipeline can collect many green checkmarks that all share the same flaw. At that point, granularity does not create safety. It creates high-resolution false confidence.

That is the difference between variance and bias.

Granular checks help with variance. They catch random, local, one-off deviations. They make the system less fragile against isolated mistakes.

They do not fix bias. If the checker is systematically wrong, adding more instances of the same checker mostly multiplies the wrongness. It creates a beautiful row of confirmations over the same error.

This is where the old infrastructure metaphor starts breaking, and where another metaphor becomes useful.

The repair is not just retry.

The repair is decorrelation.

Different models. Different prompts. Different evaluation angles. Different representations of the same task. Different failure assumptions. Sometimes even different modalities of checking, where one component evaluates structure, another checks factual grounding, another verifies constraints, and another looks for contradiction.

That is not classical retry anymore.

That is closer to speciation.

You do not make the system robust by repeating the same organism. You make it robust by introducing enough variation that one blind spot does not become a colony-wide disease. The same way biological systems survive not because every unit is perfect, but because diversity changes how failure propagates.

This is the bridge I keep finding between old engineering and the older biological material I have been reading for years.

I spent almost three years reading Ant Encounters. Not because the book was impossible to read faster, but because every page kept connecting to something else. A small observation about ants was not just about ants anymore. It became a question about local decisions, global behavior, task allocation, distributed coordination, and how a system can stabilize without one central source of truth owning every decision.

Now I am reading about viruses as complex adaptive systems, and the same thing happens. One page becomes a week of thinking. Adaptation, persistence, mutation, failure, survival under pressure, local variation, global behavior. Suddenly this is not only biology. It becomes a way to think about AI systems that cannot rely on perfect deterministic components but still need to produce reliable behavior.

Compared with the rhythm of the AI world, this looks absurdly slow.

People publish five takes about five new tools before lunch, and I am still stuck on one biological analogy from a book that is not even about AI.

But maybe “stuck” is the wrong word.

Maybe this is not reading. Maybe this is compilation.

The page is not being consumed. It is being linked. It enters a context made of old work, unfinished ideas, technical scars, software architecture, biological curiosity, and frustration with shallow AI products. The result is not speed. The result is compression. A small input creates a large internal reorganization.

That is valuable, but it has a serious problem.

It is invisible.

And maybe this is the real fear behind the question “am I slow?” Not that I am actually slow. Not exactly. The fear is that while I am connecting dots, the field will move on without seeing any of it. The fear is that depth without visible output becomes indistinguishable from absence. The fear is that the AI world is so loud, so accelerated, and so addicted to fresh vocabulary that if I do not constantly produce something visible, I will disappear inside the buzz.

That fear is not irrational.

The field rewards fluency in the language of the week. If the word is “agents,” everyone builds agents. If the word is “reasoning,” everything becomes reasoning. If the word is “memory,” every cache becomes memory. If the word is “workflow,” every sequence of API calls becomes a platform.

I understand why this happens. Attention is scarce. Timing matters. If you arrive too late, the conversation has already moved somewhere else.

But there is a cost to always moving at that rhythm. You risk becoming synchronized with noise. You start optimizing for being current instead of being correct. You learn how to speak the new vocabulary faster than you understand the old problem underneath it. You become responsive, but not necessarily thoughtful.

And I do not want that.

At the same time, I cannot use depth as an excuse forever.

This is the uncomfortable part, and I should not escape it with a nice sentence.

Sometimes I am not slow. I am filtering. Sometimes I am not slow. I am connecting. Sometimes I am not slow. I am refusing to spend cognitive energy on hype that will disappear in two weeks.

But sometimes I am hiding behind depth.

Not theoretically. Not as a universal writer problem. Me, now, in this exact pattern.

I can feel it when a connection stays private longer than it should. I can feel it when a thought keeps becoming more complex in my head because publishing it would make it smaller, exposed, and easier to criticize. I can feel it when “I am still thinking about it” starts as discipline and slowly becomes shelter.

That is the failure mode I need to catch.

Because slow thinking is valuable only if it eventually becomes visible, testable, shareable, or executable. Otherwise it is just private complexity. It may feel profound internally, but from the outside it has no weight.

This does not mean every thought needs to become a polished theory. That would create another paralysis. But the intermediate steps need to leave traces. The note after reading one page matters. The connection between ant encounters and AI routing matters. The observation that a model check is a handshake with uncertainty hidden under the return type matters. The idea that decorrelated evaluators are closer to speciation than retry matters.

Not because each fragment is complete.

Because the fragments show the work.

That is probably the artifact I keep underestimating: the process of connecting old principles to new systems while the connection is still messy.

The current AI discourse is full of people saying “look at this new thing.” Maybe there is space for someone saying “look at this old principle returning in a strange form, and look carefully at where the analogy breaks.”

That is not slower.

It is a different rhythm.

A rhythm that does not compete well with hype in the short term, but maybe ages better.

And maybe that is what I actually want. I do not want to win the weekly AI vocabulary race. I do not want to rebuild my thinking every time the market chooses a new word. I do not want to become another person who confuses speed with direction.

I want to understand what remains true after the buzzword moves away.

That kind of work is slower by nature. You cannot connect biology, distributed systems, software architecture, and AI orchestration at the speed of a product launch thread. You cannot build a durable mental model by reacting to every notification. You cannot understand a field only by consuming its newest claims.

But you can disappear while doing deep work silently.

That is the warning I take seriously.

Not “you are too slow.”

More like:

Your slowness needs output.

Slow and invisible is dangerous. Slow and traceable is different. Slow and executable is different. Slow and published is different. Slow and connected to experiments, code, diagrams, arguments, failures, and public reasoning becomes a body of work.

So maybe the answer is yes, I am slow.

But I am not slow because I am lost.

I am slow because I am trying to understand the machinery instead of just repainting the dashboard. I am slow because every new AI idea seems to drag behind it a much older question. I am slow because I do not trust speed when speed is mostly social pressure. I am slow because I keep finding useful ghosts from older fields inside the newest buzzwords.

The risk is not being slow.

The risk is letting the work stay trapped inside my head until the world has no way to distinguish depth from silence.

So I probably do not need to chase more.

I need to expose more.

I need to turn the reading into notes, the notes into arguments, the arguments into experiments, and the experiments into artifacts. Not perfectly. Not only when the whole theory is clean. Earlier. Messier. More honestly.

Because maybe, in this AI world, reacting to every buzzword is not the same thing as adapting.

Maybe the harder part is still being able to think when the buzzword is gone.

Orchestrated Multi-Agent Safety & Test Oversight - AKA "`O MASTO"

marcosomma — Mon, 18 May 2026 21:01:11 +0000

I am building a small experiment inspired by Stripe Minions. Not related to OrKa. This is a different playground. But apparently I have a recurring problem: I do not trust agents enough to let them freely touch a codebase, and I do not trust humans enough to believe they will always review AI output properly when they are tired, rushed, or already late for another meeting.

So the question became simple. Can we automate small development tasks without pretending the coding agent is the adult in the room?

Because yes, AI can write code! We know that. Sometimes it writes useful code. Sometimes it writes code that looks clean, passes the first glance, and then you realize it quietly moved business logic into the wrong layer because it had “a better idea.” Classic junior developer energy, but with infinite confidence and no coffee breaks.

The interesting part of Stripe Minions, at least for me, is not that agents can open pull requests. The interesting part is the machinery around them. The task definition, the constraints, the review process, the checks, the fact that the agent is not just sitting there with a keyboard and divine permission to refactor your production system.

That is the part I want to explore!

In my experiment, GitHub access starts as read-only. The system can inspect the codebase, understand structure, look at existing patterns, and generate a candidate issue. But it cannot immediately modify anything. Before planning even starts, the task needs to pass a semantic gate: is it scoped, is it testable, is it clear enough, and is it safe enough to continue? Only after that does the workflow move into planning, architecture, execution, PR creation, review, and final merge validation.

I am calling this orchestration ’O MASTO.

In Neapolitan, ’o masto is the master craftsman. The person who looks at the work and decides if it is actually good enough. Not if it looks good in a demo. Not if the agent says it is done. Actually good enough.

In this experiment, it also stands for Orchestrated Multi-Agent Safety & Test Oversight. Yes, the acronym is a bit forced. No, I do not care. It makes me laugh, and naming things is half of software engineering anyway.

The idea is that ’O MASTO is the layer that does not trust the agent. It checks the task, the plan, the implementation, the PR, the tests, the regression risk, and the final merge conditions. It is not there to be impressed. It is there to say “no, this is not good enough, go back.”

That is the core idea I keep coming back to. The executor is not the boss. The reviewer is not the boss. The LLM is definitely not the boss. The gate is the boss!

I think this is where AI coding workflows need to go. Not toward bigger chat windows where we ask the model to “please be careful.” Toward systems that assume the model will be wrong sometimes and are designed to catch that before the damage reaches main.

AI will not remove engineering discipline. It will expose who actually had it.

If a project has no tests, no review culture, no stable patterns, no definition of done, and no clear ownership, an AI coding agent will not magically fix it. It will just produce chaos faster, with better formatting.

My bet is that the next serious layer of AI development tooling will be trust infrastructure. Not just generation. Validation. Rejection. Retry. Traceability. Merge control. Basically "old school" software engineering.

The Real Token Economy Is Not About Spending Less. It Is About Thinking Smaller.

marcosomma — Sun, 26 Apr 2026 22:46:01 +0000

I saw a video today that made me laugh, then made me a bit worried.

It was one of those jokes that is not really a joke because you can already see some company doing it six months from now. A manager was basically complaining because an employee was not spending enough AI tokens. Not enough tokens. As if tokens were steps on a fitness tracker.

"You only burned 2,000 tokens today, Susan. Are you even working?"

It sounds absurd, but we are not that far from it. Companies are already starting to measure AI adoption through number of prompts, number of tool calls, input tokens, output tokens, cost per user, cost per team, cost per workflow. And to be clear, I do not think this is automatically wrong. Measuring token usage makes sense. Tokens are cost. Tokens are latency. Tokens are context. They are also a trace of how people and systems are using AI.

The problem starts when we confuse the metric with the objective. We did this with hours worked. We did this with tickets closed. We did this with meetings attended. We did this with leads, where 1,000 unqualified leads looked better than 10 serious conversations because the spreadsheet was having a great day and nobody wanted to ruin the mood with reality.

Now we risk doing the same with tokens.

More tokens does not mean better work. Fewer tokens does not mean smarter work. The interesting signal is not the raw number. The interesting signal is the relationship between what you put into the model, what you ask it to do, and what comes out. That is where I think the real token economy starts. Not as a cost saving obsession, but as an architectural signal.

Tokens are not just money

The first way people talk about tokens is cost, and that is understandable. If you use hosted LLM APIs, tokens map quite directly to money. Input tokens cost something. Output tokens cost something. Larger models cost more. Long contexts cost more. Retries cost more. Bad prompts cost more. Bad architecture costs a lot more, but usually in a way that arrives later and looks like a reliability problem.

So the first instinct is to optimize token consumption. Compress prompts. Summarize context. Pick cheaper models. Cache responses. Reduce unnecessary output. All of that is useful, but I think it is only the shallow layer of the problem.

The more interesting question is not "how many tokens did this task consume?" The more interesting question is "what cognitive operation did those tokens represent?"

Because input tokens and output tokens are not the same thing. Input tokens usually buy context. They are the material you ask the model to look at. Output tokens usually buy generation, explanation, structure, synthesis, or action. If I send 10,000 input tokens to a model and get back 10 output tokens, that could be terrible. It could also be exactly right.

If the task is to read a long error log and return whether the failure is caused by authentication, a tiny output may be valid. If the task is to classify a product review as positive, neutral, or negative, a small answer is not a failure. It is the point. If the task is to route a bug report to the correct engineering queue, I do not need a novel. I need the right route.

So no, high input and low output is not automatically bad. But it is a signal. And I think that signal deserves a lot more attention than it currently gets.

Balance does not mean symmetry

When I talk about token balance, I do not mean that input tokens and output tokens should be equal. That would be a very silly metric, and we already have enough silly metrics trying to cosplay as management science.

By balance, I mean the relationship between the size of the input, the size of the output, and the value of the decision produced. A large input with a tiny output usually means the model is doing some kind of compression, classification, extraction, routing, filtering, moderation, scoring, validation, or decision making. A small input with a large output usually means the model is doing generation, expansion, explanation, drafting, or ideation. A large input with a large output usually means synthesis, transformation, summarization, comparison, or multi-step reasoning. A small input with a small output is usually a narrow atomic task.

None of these patterns are good or bad by themselves. They tell you something about the shape of the work. And sometimes the shape of the work is screaming.

Imagine you send a giant prompt containing a full meeting transcript, a product description, usage logs, a bug report, five examples, a JSON schema, tone guidelines, safety instructions, and a final line saying "be concise" because apparently we enjoy irony. Then you ask the model to return this:

{
  "priority": "high"
}

Maybe that is fine. Maybe the classification really required all of that context. But maybe you just built a cognitive washing machine to clean one spoon.

The point is not that the token ratio is wrong. The point is that the ratio invites questions. Did the task need all of that context? Could the context have been retrieved more narrowly? Could the classification have been separated from the extraction? Could a smaller model do part of the work? Could a deterministic rule do part of it? Could the final output be validated separately instead of trusting one giant model call?

That is where token metrics become useful. Not as a scoreboard. As a diagnostic tool.

The real problem is overloaded cognition

A lot of AI workflows are not expensive because the model is expensive. They are expensive because the task design is confused. We ask one model call to do too many things at once, then we act surprised when the model behaves like a very intelligent intern who received eight contradictory Jira tickets in one message.

Read this long input. Understand the domain. Extract twenty fields. Normalize them. Infer missing values. Respect the schema. Apply business rules. Avoid hallucinations. Explain your decision. Be concise. Be deterministic. Also, please do it in one call because we saw a demo once and now we think architecture is a prompt template.

This is where things become fragile. One big prompt. One big model. One fragile JSON output. One retry loop when it fails. One annoyed engineer staring at a malformed comma at 1:12 AM wondering why they studied data structures.

The problem is not only cost. The problem is that the reasoning surface is too large. Every additional instruction increases the model's degrees of freedom. Every unrelated piece of context adds noise. Every extra output field increases the chance of format drift. Every hidden dependency between fields makes validation harder. And when the output fails, you often do not know why.

Was the context too long? Was the instruction ambiguous? Was the schema too complex? Was the task logically overloaded? Was the model too weak? Was the model too creative? Was Mercury in retrograde? At some point, debugging a giant prompt starts to feel like debugging a dream.

This is why I think the unit of optimization should not be the prompt. The unit of optimization should be the cognitive task.

Think smaller, not just cheaper

When people hear "token economy", they often think about saving money. I think that is incomplete. The better version is this: design AI workflows so each model call has the smallest reasonable cognitive surface.

Not the smallest prompt. Not the cheapest model. The smallest cognitive surface.

A task has a cognitive surface when it asks the model to consider a certain amount of context, make a certain type of judgment, and produce a certain kind of output. A wide cognitive surface is something like this: read a conversation, infer the user's emotional state, detect all action items, classify the sales opportunity, extract objections, score urgency, summarize the call, generate a follow-up email, and return a perfect JSON object with 28 fields.

That is not one task. That is a small village.

A narrower cognitive task is different. Given this segment of a product feedback thread, identify whether the user mentions pricing as a blocker. Return true or false. Or extract only the next meeting date from this text and return null if absent. Or given these three already extracted signals, choose the priority level from low, medium, or high.

Those tasks have narrower inputs and narrower outputs. They are easier to validate. They are easier to retry. They can often run on smaller models. Some can be replaced by deterministic code. Most importantly, they reduce ambiguity.

This is the part that matters. The best token optimization is not always compression. Sometimes the best token optimization is decomposition.

The 20 field JSON problem

Let us take a simple example. You have a large input document and you need a structured output with 20 values. The obvious modern AI approach is to send the full document to a model and ask it to extract everything in one JSON object. Add a schema, add "do not hallucinate", add "use null when unknown", maybe add three examples, and hope the model behaves.

Sometimes this works. Sometimes it works very well in the demo. Then production arrives, wearing boots.

The model misses a field. It invents a value. It mixes two fields. It returns invalid JSON. It follows the schema but puts the wrong value in the right place, which is worse because it looks correct. It explains itself inside a field because apparently JSON needed feelings.

So you add more instructions. Then stricter schema language. Then validation. Then retry. Then a stronger model. Then a more expensive model. Then someone says, "Maybe we should fine-tune it." And now your simple extraction pipeline has become a small national infrastructure project.

A different approach is to ask a boring but useful question: are these 20 values actually one cognitive task?

Maybe not. Maybe five fields are direct extraction. Maybe three require classification. Maybe four depend on dates. Maybe two require numerical normalization. Maybe six are only relevant if a previous condition is true. In that case, one big prompt is not simpler. It is only hiding the complexity inside the model call.

You may get a better system by clustering the fields by semantic dependency. For example, direct identifiers can be one batch. Dates and temporal constraints can be another. Risk indicators can be another. Obligations and responsible parties can be another. The final normalized summary can be built only after the previous signals exist.

Each batch can have a smaller prompt, a smaller schema, and a narrower validation rule. Some batches may not need an LLM. Some can use regex, parsers, lookup tables, embeddings, or deterministic checks. Some can use a small local model. Only the genuinely difficult parts need the expensive model.

This is where the cost savings come from, but cost is only one part of the win. You also get better observability. If the final output is wrong, you can inspect which subtask failed. You can measure field-level accuracy. You can retry only the failing part. You can swap models for one stage without touching the rest. You can cache intermediate outputs. You can add deterministic validation at the boundary.

That is a real token economy. Not "use fewer tokens". Spend tokens where cognition is actually needed.

Smaller prompts reduce variance

I want to be careful with the word deterministic. LLMs are not truly deterministic systems in the classical engineering sense, even when you reduce temperature and constrain output. They are probabilistic systems. But workflow design can make their behavior more stable, more reproducible, and more controllable.

Smaller prompts with narrower objectives usually reduce the degrees of freedom of the model. If the model has one job, a small output space, and a strict schema, there are fewer ways to fail. If the model has twenty jobs, a large input, competing instructions, implicit dependencies, and a complex schema, you should not be surprised when it occasionally decides to express itself like a haunted spreadsheet.

This is why task decomposition can improve consistency. Not because small calls magically make the model deterministic, but because small calls make the system around the model easier to control. The output space is narrower. The validation is simpler. The retry logic is cheaper. The failure modes are easier to classify. The model choice becomes more flexible. The prompts become easier to test.

And the orchestration becomes explicit.

That last point matters a lot. When everything happens inside one prompt, the process is invisible. When you split the work into stages, the process becomes inspectable. This is the difference between hoping the model thinks correctly and designing a system where each step can be observed.

Where OrKa fits into this

This is one of the reasons I have been building OrKa, an orchestration framework for AI agents and reasoning workflows. The point of OrKa is not "use more agents because agents are cool". Honestly, if adding agents makes your system less understandable, congratulations, you have invented distributed confusion.

The point is different. Make cognitive work explicit. Define the flow. Split reasoning into smaller units. Route tasks. Log execution. Validate outputs. Keep memory and context under control. Make the system inspectable instead of praying over a large prompt.

In this view, an LLM is not the application. It is one component inside a system. Sometimes the LLM extracts. Sometimes it classifies. Sometimes it rewrites. Sometimes it evaluates. Sometimes it should not be called at all. The orchestration layer decides how work moves between these pieces.

That is where token economy becomes architecture. You are no longer asking only how to reduce a prompt by 20 percent. You are asking which cognitive step actually needs this context.

That question changes everything. Maybe the first model call only needs the user message. Maybe the second needs the relevant log snippet. Maybe the third needs only three extracted fields. Maybe the final formatter needs no model at all. If you send the full context to every step, you are not designing an AI system. You are photocopying the universe and asking a model to find the invoice number.

It may work. It is not a strategy.

Token metrics should trigger questions

So how should teams use token metrics? Not as productivity surveillance. Not as a way to shame people for using too many or too few tokens. Not as a leaderboard where the person with the most prompts wins some cursed office trophy.

Token metrics should trigger engineering questions.

When input tokens are very high and output tokens are very low, ask whether the task is intentionally compressive or accidentally overloaded. When output tokens are very high, ask whether the model is generating useful structure or just producing expensive fog. When the same context is repeatedly sent across multiple calls, ask whether retrieval, caching, or state passing could reduce duplication. When a large model is used for simple extraction, ask whether a smaller model or deterministic rule would work. When retries consume a lot of tokens, ask whether the schema, validation, or task boundaries are wrong.

This does not mean splitting tasks is automatically better. If you send the same 10,000 token input twenty times to extract twenty fields, you may have made the system more expensive and slower. You have not built architecture. You have built a very complicated way to duplicate context.

The win comes when decomposition is paired with context narrowing. Extract the relevant segment once. Reuse intermediate state. Cluster fields that share dependencies. Route only the necessary context. Validate locally. Use smaller models where possible. Stop calling the model when code can do the job.

This is not anti-LLM. It is pro-system.

A simple mental model

Here is the mental model I keep coming back to. Input tokens are attention budget. Output tokens are commitment surface.

The more input you provide, the more the model has to attend to. The more output you request, the more opportunities the model has to drift. A workflow becomes more stable when the attention budget and the commitment surface are aligned with the actual cognitive task.

If the model needs to classify one thing, do not ask it to also summarize, extract, explain, normalize, and format a complex object. If the model needs to generate a long answer, do not overload it with irrelevant context that only increases noise. If the model needs to extract structured fields, do not assume all fields belong in the same call. If the model needs to make a decision, make the decision boundary explicit.

The goal is not minimal tokens. The goal is minimal unnecessary cognition.

That distinction is important. Some tasks deserve many tokens. A long research synthesis may need a lot of context. A technical incident summary may need careful source retention. A product comparison may need long input and long output. A multi-document comparison may be legitimately expensive.

The problem is not spending tokens. The problem is spending tokens without knowing what they are buying.

This is also a model selection problem

Once you split cognitive tasks, model selection becomes much more interesting. In a one-prompt architecture, you usually choose the strongest model you can afford because the task is messy. The model has to handle everything. It has to read long context, reason, extract, format, validate, and recover from ambiguity.

But if you split the workflow, you can choose models per cognitive step. A small model can do simple classification. A local model can extract obvious fields. A deterministic parser can normalize dates. A rules engine can validate constraints. A stronger model can handle the genuinely ambiguous reasoning.

This is where the economics change. Not because you begged the prompt to be shorter, but because you changed the shape of the work. The expensive model becomes a specialist instead of a landfill.

And yes, I know "landfill" sounds harsh. But many AI systems today are exactly that. They throw all context into one place and hope the biggest model will recycle it into something useful. This works surprisingly often, which is the dangerous part. It works enough to ship a demo. It fails enough to punish you in production.

Token economy as observability

A mature AI system should not only log the final response. It should log the token shape of the workflow.

Which step consumed the most input? Which step produced the most output? Which step retried the most? Which step had the most schema failures? Which step required the strongest model? Which step could be cached? Which step could be replaced by code? Which step actually improved the final decision?

This is not accounting. This is observability.

You are not only tracking spend. You are tracking cognitive pressure inside the system. A sudden increase in input tokens may mean your retrieval is bringing too much context. A sudden increase in output tokens may mean the model started explaining instead of structuring. A high retry cost may mean your schema is too complex or your prompt is ambiguous. A high token cost on a low-value decision may mean the workflow needs decomposition. A low token cost with poor quality may mean you compressed away necessary context.

Again, the metric is not the answer. The metric is the signal. The engineer still needs judgment, which is very inconvenient. We were promised automation and somehow we still need thinking. Rude.

The wrong future

The wrong future is easy to imagine. Teams get AI dashboards. Managers see token usage per employee. People are encouraged to "use AI more". Token consumption becomes proof of adoption. Employees learn to generate more prompts because the dashboard rewards activity. Everyone looks productive, costs go up, and quality does not.

Then leadership announces an AI efficiency initiative. Now everyone must reduce token usage. People use smaller prompts. Quality drops. Nobody knows why. Another dashboard is created. A consultant appears. The circle of life continues.

This is what happens when the metric becomes the goal. Token usage by itself tells you almost nothing about quality. A great engineer may use fewer tokens because they decomposed the problem properly. Another great engineer may use more tokens because the task genuinely required context. A bad workflow may use few tokens and produce garbage. A good workflow may use many tokens and produce a high-value decision.

So measuring tokens is not wrong. Judging work by raw token volume is wrong.

The better future

The better future is more boring, which is usually a good sign in engineering. Teams treat token metrics as workflow diagnostics. They look at input-output patterns. They identify overloaded prompts. They split tasks where it makes sense. They route context more carefully. They use smaller models for smaller cognitive jobs. They validate structured outputs separately. They measure retries, drift, and failure modes.

They do not ask "how much AI did you use?" They ask "where did the AI actually add decision value?"

That is the mindset shift. Tokens are not just a bill. Tokens are a trace of cognitive architecture. They show where a system is bloated. They show where context is duplicated. They show where outputs are too ambitious. They show where models are being used as glue because nobody wanted to design the pipeline. And yes, sometimes they show that the expensive model was actually justified.

That is fine. The goal is not to make everything cheap. The goal is to make the system honest.

Final thought

I think the next stage of AI engineering will not be about who writes the cleverest prompt. It will be about who designs the clearest cognitive pipeline.

The prompt is not the unit of architecture. The cognitive task is.

Token balance matters because it gives us a way to inspect that task. Not perfectly. Not automatically. Not as a KPI to punish or reward people. But as a signal that says: maybe this workflow is overloaded, maybe this context is too broad, maybe this output is trying to do too much, maybe this model is stronger than necessary, maybe this task should be split, maybe this step should not use an LLM at all.

That is where the real token economy lives. Not in spending fewer tokens, but in spending attention where attention is needed.

If we do that well, the benefits go beyond cost. Lower latency. Smaller models. Cleaner validation. Less format drift. More stable outputs. More inspectable workflows. Systems that are closer to engineering and less close to whispering wishes into a very expensive autocomplete machine.

Which, to be fair, is still fun.

But maybe not the future we should build production systems on.

Claude! Stop Burning Tokens on Your Agent's Tool Output!

marcosomma — Tue, 21 Apr 2026 09:39:42 +0000

A Two-Stage Curator That Pays for Itself

I watched Claude Code feed 108,894 bytes of seq 1 20000 back into its own context window. That output contained 20,000 integers.
No errors. No signal. No insight. Just counting.

And yet the system still had to tokenize it, send it back to the model, and bill for it. This is not an edge case. It is the default failure mode of agent tooling.

Tools produce output. The output goes back to the model. You pay for it. Logs, test runs, ps listings, git history, build spam, progress bars, boilerplate, decorative separators, repeated warnings, repeated success lines, repeated everything. A depressing amount of it is useless.

A lot of agent users are quietly paying premium model rates to process terminal confetti. That is the real problem!

My first fix was the obvious one. I added a PreToolUse hook and pushed large Bash output through a cheaper model before it reached Opus.

That worked, technically. Then I noticed I was still being stupid, just in a more optimized way.

On seq 1 20000, I was paying Haiku to read 20,000 integers and tell me they were 20,000 sequential integers.

Yes, that is cheaper than letting Opus read them.

No, that is not a good design.

If a 40-line awk script can identify the pattern for free, paying any model to summarize it is already waste. So the architecture changed. Not “small model before big model.” That idea sounds clever, but by itself it is just cost reshuffling.

The real pattern is simpler and better: extract free signal first, and only pay for a model when deterministic tools run out of leverage.

That led to a two-stage curator.

Stage 1 is deterministic cleanup. It strips ANSI escape sequences, removes carriage-return junk from progress bars, collapses consecutive duplicate lines, and compresses monotonic integer runs. It is effectively free.

Stage 2 is LLM extraction, but only if stage 1 still leaves too much output. That is where tokens are spent. That means it should fire rarely, and only when stage 1 could not do enough.

That distinction matters! Because once you actually measure it, a lot of tool output turns out to be compressible by embarrassingly simple logic.

The benchmark

Here is the benchmark across five scenarios, using the pricing assumptions from the benchmark runner: Opus input at $15 per million tokens, Haiku input at $1 per million, Haiku output at $5 per million, and a rough estimate of 4 bytes per token.

Scenario	Raw bytes	Stage 1	Final	LLM?	Tokens saved	Haiku cost	Net savings
`seq 1 20000`	108,894	37	103	no	27,197	$0.000	+$0.408
5,000 repeated log lines	145,000	38	104	no	36,224	$0.000	+$0.543
ANSI + progress-bar spam	54,000	27	92	no	13,477	$0.000	+$0.202
`ps auxww` (unique lines)	213,230	213,230	1,008	yes	53,055	$0.055	+$0.741
`echo hello world`	12	12	12	no	0	$0.000	$0.000

The pattern is blunt.

Three of the four large-output cases were handled for free.

seq collapsed from 108,894 bytes to 37.
Repeated log spam dropped from 145,000 to 38.
ANSI and progress-bar noise fell from 54,000 to 27.

No LLM call was needed in any of those cases.

The only scenario that needed stage 2 was ps auxww, which is exactly what you would want. That output is genuinely varied. There is not much for awk to compress. That is the moment when paying a smaller model to extract the useful facts is justified.

Small output remained untouched, which is also correct. If the command only produced hello world, the system paid nothing and moved on.

This is the whole point.

A cheap LLM is not the first line of defense.

Deterministic cleanup is.

The LLM should be the escalation path, not the reflex.

Stage 1: deterministic cleanup

This is the part that does the real work more often than people expect.

#!/usr/bin/awk -f

function flush_int_run() {
    if (int_count >= 3) {
        printf "[%d sequential integers %s..%s]\n", int_count, int_start, int_end
    } else if (int_count > 0) {
        for (i = int_start; i <= int_end; i++) print i
    }
    int_count = 0
}

function flush_dupe() {
    if (dupe_count > 1) {
        printf "%s [×%d]\n", dupe_line, dupe_count
    } else if (dupe_count == 1) {
        print dupe_line
    }
    dupe_count = 0
}

{
    gsub(/\033\[[0-9;]*[a-zA-Z]/, "", $0)
    gsub(/\r/, "", $0)

    if ($0 ~ /^-?[0-9]+$/) {
        n = $0 + 0
        if (int_count > 0 && n == int_end + 1) {
            int_end = n
            int_count++
            next
        }
        flush_int_run()
        flush_dupe()
        int_start = n
        int_end = n
        int_count = 1
        next
    }

    flush_int_run()

    if (dupe_count > 0 && $0 == dupe_line) {
        dupe_count++
    } else {
        flush_dupe()
        dupe_line = $0
        dupe_count = 1
    }
}

END {
    flush_int_run()
    flush_dupe()
}

There is nothing magical here.

It strips terminal paint.
It collapses repeated lines.
It compresses obvious integer sequences.

That is enough to destroy huge amounts of waste.

This is a useful reminder for AI tooling in general. A lot of expensive “reasoning” problems are not reasoning problems. They are preprocessing failures.

Stage 2: only escalate if stage 1 failed to shrink enough

The wrapper runs the command, checks the raw size, and passes small output through untouched.

If the raw output is large, it runs the deterministic cleaner.

If the cleaned output is now small enough, it returns that cleaned output and stops.

Only if the cleaned output is still large does it call Haiku.

#!/usr/bin/env bash
set -o pipefail

RAW_THRESHOLD="${CLAUDE_BASH_SUMMARIZE_THRESHOLD:-8000}"
LLM_THRESHOLD="${CLAUDE_BASH_LLM_THRESHOLD:-8000}"
MODEL="${CLAUDE_BASH_SUMMARIZE_MODEL:-claude-haiku-4-5}"

cmd="$1"
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &>/dev/null && pwd)"
CLEAN_AWK="$SCRIPT_DIR/deterministic-clean.awk"

raw=$(mktemp); cleaned=$(mktemp)
trap 'rm -f "$raw" "$cleaned"' EXIT

bash -c "$cmd" >"$raw" 2>&1
rc=$?

raw_size=$(wc -c <"$raw" | tr -d ' ')

if [ "$raw_size" -le "$RAW_THRESHOLD" ]; then
    cat "$raw"
    exit "$rc"
fi

awk -f "$CLEAN_AWK" <"$raw" >"$cleaned"
cleaned_size=$(wc -c <"$cleaned" | tr -d ' ')

if [ "$cleaned_size" -le "$LLM_THRESHOLD" ]; then
    printf '=== CURATED %d→%d bytes (stage 1 deterministic, no LLM) ===\n' \
        "$raw_size" "$cleaned_size"
    cat "$cleaned"
    exit "$rc"
fi

summary=$(claude -p --model "$MODEL" \
    "Extract signal from this command output. KEEP: errors, warnings, stack traces, file paths with line numbers, numeric results, unique events, final status. DROP: decorative separators, boilerplate. Preserve exact error text verbatim. Be terse but faithful on key facts. Plain text only." \
    <"$cleaned" 2>/dev/null)

summary_size=${#summary}
printf '=== CURATED %d→%d→%d bytes (stage 1 + %s extraction) ===\n' \
    "$raw_size" "$cleaned_size" "$summary_size" "$MODEL"
printf '%s\n' "$summary"
exit "$rc"

That second threshold check is the entire point.

Without it, the “cheap model” becomes a permanent tax on output that deterministic logic had already made cheap.

With it, the LLM only gets called when the dumb tools genuinely ran out of leverage.

That is how this stops being a cute hack and starts becoming a sensible pipeline.

Hooking it into Claude Code

I wired it into Claude Code with a PreToolUse hook on Bash. The hook rewrites the original command so it runs through the wrapper first.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "/path/to/.claude/scripts/bash-wrap-hook.sh",
        "timeout": 5
      }]
    }]
  }
}

The hook script itself is tiny. It reads the incoming JSON, extracts tool_input.command, and swaps in the wrapped version. Nothing here is conceptually hard. That is precisely why it is worth doing. Too much agent engineering right now is really just people tolerating waste because it looks sophisticated once wrapped in model calls.

The cost math

Here is the clean version. Let the raw output be N tokens.
If you send it directly to Opus, the input cost is:

15N / 1,000,000

Now suppose stage 1 reduces that output to K tokens. If K is still above threshold, stage 2 fires. Haiku reads K tokens, emits a summary of M tokens, and then Opus receives those M tokens.
So the escalated path costs:

(1K + 5M + 15M) / 1,000,000 = (K + 20M) / 1,000,000

Break-even is therefore:

15N > K + 20M

That is the actual condition for the two-stage system. If stage 1 barely helps, then K ≈ N, and the inequality becomes:

15N > N + 20M

which simplifies to:

14N > 20M

or:

M < 0.7N

So in the worst case, where deterministic cleanup did almost nothing, the LLM stage still pays off if it compresses the remaining content by roughly 1.43x or better. That is not a demanding threshold.

And in the real pipeline, stage 1 often shrinks the input before the LLM ever sees it, which makes the economics even more comfortable.
This is why the design works. Not because “small model then big model” is automatically clever. Because the model is only invited in after cheap tools have already done what they can.

What I would change next

This version already works, but there are obvious next steps.

Latency should probably be part of the gate, not just bytes. Saving a few cents is not impressive if it adds a few seconds to every interactive tool call.

Stage 1 could be extended to catch more patterns, especially timestamp-heavy logs where the message repeats but the prefix changes.

The system should probably hard-cap verbose LLM summaries, because “cheap extraction” can still become noisy if the prompt drifts.

And the current implementation buffers until the command finishes. That is fine for benchmarking, but worse for real long-running workflows. A streaming version would be much better.

But none of that changes the core lesson.

The actual lesson

The interesting idea here is not “use an LLM to compress LLM inputs.” That is the shallow reading. The more useful pattern is this:

before you spend tokens to extract signal, try extracting signal for free.

A lot of the mess we hand to expensive models is not difficult. It is just noisy. And noisy is not the same as complex. That distinction matters. Because once you see it clearly, the same pattern starts showing up everywhere.

Retrieval pipelines that rerank garbage before filtering it.
Scrapers that pass repeated boilerplate into embeddings.
Log processors that ask a model to summarize progress-bar sludge.
Agent systems that burn premium tokens on output a shell one-liner could have collapsed immediately.

Cheap filter first.
Expensive model second.
Measure the break-even.
Then stop paying premium rates for repetition, boilerplate, terminal paint, and counting.

That is not an AI breakthrough.

It is just basic engineering discipline, which is exactly why so many agent stacks are currently missing it.

I Ran 500 More Agent Memory Experiments. The Real Problem Wasn’t Recall. It Was Binding.

marcosomma — Mon, 13 Apr 2026 09:19:39 +0000

This is a follow-up to I Tried to Turn Agent Memory Into Plumbing Instead of Philosophy. If you haven't read that one, the short version: I built a persistent memory system for AI agents called OrKa Brain, ran 30 benchmark tasks, got a 63% pairwise win rate and a +0.10 rubric improvement, and concluded that "the model already knew most of what the Brain was recalling." Then I got some very good comments that made me uncomfortable. This is what happened next.

The Comfortable Lie I Told Myself

After the first benchmark, I had a narrative that felt reasonable: the memory system works, the numbers are positive, the confounds are acknowledged, and more data will clarify things.

That last part, "more data will clarify things", is what engineers say when they don't want to admit they might be wrong. I said it too. And then I went and got more data.

250 tasks. Five specialized tracks. 500 total runs (brain vs. brainless). A separate judge model so the LLM wasn't grading its own homework. Eleven code changes addressing five root-cause problems I'd identified from the first round.

The results came back. They didn't clarify things. They made them worse.

What I Fixed Before Running Again

I'm not going to pretend I just blindly re-ran the same experiment. I did real work between benchmark v1 and v2. The first article's comments called out several things, and I addressed them:

Problem 1: Skills were storing verbatim LLM output, not abstract patterns.

This was the big one. When the Brain learned a skill from a data engineering task, it stored the literal steps: "Load CSV files into staging tables using pandas read_csv with error handling." That's not transferable knowledge, it's a paraphrase of what the model already knows. I rewrote the abstraction layer (orka/brain/constants.py, brain.py, brain_agent.py) to extract verb-target patterns: "implement [target]", "validate [component]", "trace [target]". The idea was that abstract patterns would transfer better across domains.

Problem 2: The recall threshold was zero.

min_score=0.0 meant any vaguely related skill could get recalled. I raised it to 0.5 and added a semantic floor in the transfer_engine.py, if the embedding similarity is below 0.1 AND structural match is below 0.6, the candidate gets rejected entirely.

Problem 3: The model was judging its own output.

v1 used the same LLM for execution and evaluation. v2 uses a separate judge model (qwen/qwen3-coder-30b) with dedicated rubric and pairwise workflow YAMLs. Execution and judgment are completely decoupled, different scripts, different models, different runs.

Problem 4: Track diversity.

v1 had one track. v2 has five:

Track	Focus	Why It Matters
A	Cross-domain transfer	Does a data engineering skill help with cybersecurity?
B	Ethical reasoning	Do anti-pattern detection skills transfer?
C	Routing decisions	Hardest track, complex multi-path choices
D	Multi-step reasoning	Do procedural patterns help new reasoning chains?
E	Iterative refinement	Do improvement patterns compound?

50 tasks per track, 250 total. All available in the benchmark dataset.

Problem 5: Single-pass baselines.

The brainless condition now runs through a properly equivalent pipeline, same structure, same number of agents, just without the Brain recall/learn steps. No more two-pass advantage that could inflate brainless scores. Baseline workflows: baseline_track_a.yml, baseline_track_b.yml, etc.

I also split the pipeline into three standalone scripts, execution, judging, aggregation, so you can re-run any phase independently. Eleven code changes total, all committed and tested. 3,014 unit tests passing. You can verify everything in the results directory.

I felt good about this. I'd addressed every valid criticism. Time to re-run.

The Numbers

Here's the overall aggregate from 250 tasks, brain vs. brainless:

Rubric Scores (1–10 scale, six dimensions)

Dimension	Brain	Brainless	Delta
Reasoning Quality	9.51	9.52	−0.01
Structural Completeness	9.87	9.83	+0.04
Depth of Analysis	8.79	8.74	+0.05
Actionability	9.67	9.64	+0.03
Domain Adaptability	9.85	9.82	+0.03
Confidence Calibration	9.38	9.39	−0.01
Overall	9.37	9.31	+0.06

A +0.06 rubric delta across 250 tasks.

For reference, v1 was +0.10 across 30 tasks. So the effect got smaller with more data, not larger. That's not what you want to see.

Pairwise Comparison (245 head-to-head comparisons)

Question	Brain Wins	Brainless Wins	Tie
Stronger reasoning	152	91	2
More complete	149	92	4
More trustworthy	151	92	2
Overall	151	92	2

Brain win rate: 61.6%

Here's where it gets uncomfortable. The pairwise judge says brain wins 62% of the time. The rubric judge says brain is +0.06 better, which is noise at a 9.3/10 baseline. These two metrics should agree. They don't.

I've seen this pattern before. It's length/position bias. Brain responses tend to be longer because the pipeline has more agents in the chain, which means more context, which means more text. Pairwise judges prefer longer answers. The rubric doesn't care about length, it scores each dimension independently.

Per-Track Breakdown

This is where the story gets interesting:

Track	Focus	Rubric Δ	Pairwise Win%	Brainless Baseline
A	Cross-domain transfer	−0.02	60%	9.33
B	Ethical reasoning	+0.00	52%	9.54
C	Routing decisions	+0.40	60%	8.12
D	Multi-step reasoning	+0.08	60%	9.49
E	Iterative refinement	+0.06	76%	9.61

Track C stands out. It's the hardest track, brainless only scores 8.12, nearly a full point below every other track. And it's the only track where brain shows a meaningful rubric gain: +0.40 across six dimensions.

Track E has the highest pairwise win rate (76%) but the smallest rubric gain (+0.06). That's the length bias signature, the pairwise judge loves brain's longer outputs, but the rubric says they're not actually better.

Track B is essentially a coin flip. 52% pairwise, +0.00 rubric. The Brain adds nothing to ethical reasoning tasks.

The Ugly Detail: Skill Usage

Here's what really killed me. I dug into the individual results to see how many tasks actually used their recalled skill:

Tasks with skill recall attempted: 51 / 250 (20%)
Tasks that actually used the recalled skill: 0 / 250
Average semantic match score: ~0.02 (near zero)

Zero. Not one single task out of 250 used the recalled skill. The model read the skill, evaluated it, and decided every single time that it wasn't helpful. And the semantic similarity between the abstract skill and the actual task was essentially random noise.

The abstraction layer I was so proud of, the one that converts "Load CSV files into staging tables using pandas" into "implement [target]", produced skills so abstract they were vacuous. Two words of content. The embedding model sees no relationship between "implement [target]" and any real task. The execution model correctly recognizes that "implement [target]" tells it nothing it doesn't already know.

I had gone from skills that were too specific (literal LLM paraphrases) to skills that were too abstract (empty shells). The sweet spot, actual transferable knowledge, was somewhere I hadn't found.

Sitting with the Discomfort

I'm going to be honest about what went through my head at this point. I've been working on OrKa for over a year. Forty blog posts. A research paper about the Agricultural Threshold for machine intelligence. An open-source framework that allow me to test and experiment and explore my idea with real AI runs. And the core thesis, that persistent memory makes agents better, keeps failing to show up in the numbers.

I considered dropping the whole Brain system. Making OrKa just an orchestration framework. Simpler. Easier to explain. No embarrassing benchmarks.
But then I looked at Track C again.

*Track C **is the only track where brainless *struggles. It scores 8.12, good, but not great. The tasks involve complex routing decisions where the model has to consider multiple paths and trade-offs. This is the only track where the model actually needs help.

And it's the only track where brain provides meaningful help. +0.40 rubric delta is not noise. Across 50 tasks and six scoring dimensions, that's a consistent, measurable improvement.

The pattern is simple: the Brain helps when the model needs help, and doesn't help when the model doesn't need help.

That sounds obvious in retrospect. But it means the thesis isn't wrong, it's just being tested in the wrong conditions. You wouldn't evaluate a life jacket by putting it on people standing on dry land and measuring whether they're drier.

The Real Problem: What Is a Memory?

This is where the story changes. Because instead of asking "does memory help?" I started asking "what is a memory, actually?"

Think about how you remember how to drive a car. What fires in your brain when you approach an unfamiliar intersection?

It's not one thing. It's not "turn the wheel, press the gas." That's the procedural part, and yes, it's there. But it's bound together with other things:

The time you nearly got T-boned because you assumed a green light meant it was safe without checking cross traffic. That's episodic memory, a specific event with emotional weight.
"Right of way doesn't mean right of safety", That's semantic memory. A general fact you learned, maybe from a driving instructor, maybe from experience.
"Checking mirrors BEFORE entering the intersection prevents blind-spot collisions BECAUSE turning reduces your field of vision", That's causal reasoning. You know why the sequence matters, not just that it matters.

When you encounter the intersection, all of these fire together. The procedure tells you what to do. The episode tells you what happened last time. The semantic fact tells you a principle. The causal link tells you why. That combination, that binding, is what makes the memory useful. Any single component alone is much less helpful.

Now look at what OrKa Brain currently stores as a "skill":

implement [target]
trace [target]

That's it. No episodes. No semantic context. No causal reasoning. Just two abstract action verbs. No wonder the model ignores it. It's like handing a driver a note that says "steer [vehicle]" and expecting it to help at the intersection.

The Memory Binding Problem

I went down a rabbit hole into cognitive science literature on this. What I found is that neuroscientists have been arguing about this exact problem for decades. They call it the binding problem, how does the brain take separate memory traces stored in different systems and combine them into a unified experience?

The hippocampus doesn't store the memory. It stores the index, the binding that links the procedural memory in the motor cortex, the emotional trace in the amygdala, the spatial context in the parietal cortex, and the semantic facts in the temporal lobe. When you recall one, you recall all of them, because they're bound together.

I had built the hippocampus and the motor cortex as two separate systems that had never met.

Here's what actually exists in OrKa today:

The Skill system (fully operational, used in benchmarks):

Abstract procedure steps
Preconditions and postconditions
Transfer history and confidence scores
Structural/semantic matching for recall

The Episode system (fully built, tested, never used in any benchmark):

Specific task input and outcome
What worked and what failed
Root cause analysis for failures
Actionable lessons learned
Resource metrics (tokens, latency)
Links to related episodes

Both systems are production-ready. Both have full test coverage. Both are integrated into the Brain class. I wrote record_episode(), recall_episodes(), EpisodeStore, EpisodeRecall, all of it. Complete with semantic search, retention policies, and four-dimensional scoring.

And then I never connected them together.

The Skill has no episode_id field. The Episode has no skill_id field. brain.learn() creates a Skill but not an Episode. brain.recall() returns Skills but not Episodes. The benchmark workflows run brain_learn and brain_recall, but never brain_record_episode or brain_recall_episodes.

Two complete memory systems, sitting in the same codebase, sharing no information.

When I saw this, I felt stupid. But I also felt something else: the architecture was already 80% there. The hard parts, embedding storage, semantic search, decay policies, scoring systems, were done. The missing piece wasn't a new system. It was the wiring between existing systems.

What a Memory Should Actually Look Like

Here's the concept I'm now calling a Memory Bundle:

┌─────────────────────────────────────────┐
│            MEMORY BUNDLE                │
│                                         │
│  ┌───────────┐  ┌──────────────────┐    │
│  │ Procedure │  │ Episodes (1..N)  │    │
│  │ (steps)   │──│ what worked      │    │
│  │           │  │ what failed      │    │
│  └───────────┘  │ lessons          │    │
│                 │ "X+Z → Y"        │    │
│  ┌───────────┐  └──────────────────┘    │
│  │ Semantic  │                          │
│  │ (domain   │  ┌──────────────────┐    │
│  │  facts)   │  │ Causal Links     │    │
│  │           │  │ "A because B"    │    │
│  └───────────┘  └──────────────────┘    │
│                                         │
│  transfer_score = f(all_components)     │
└─────────────────────────────────────────┘

When the system learns from an execution, it creates both a skill AND an episode, linked by ID. The skill stores the abstract procedure. The episode stores what actually happened, the specific outcome, what worked, what failed, and crucially, the lessons: "Running validation before deduplication caught 30% of bad records that would have been duplicated, always validate first."

When the system recalls, it returns the skill with its episodes attached. The prompt to the model isn't "implement [target]", it's:

Here's an abstract procedure: implement [target] → validate [component] → trace [target].

This skill has been applied 3 times before:

Data engineering (ETL): Validation before dedup caught 30% of dirty records. Lesson: always validate before any deduplication step.

API integration: Target implementation worked, but tracing missed async callbacks. Lesson: tracing needs to account for async execution paths.

Log analysis: Pattern worked well. Filtering noisy entries before analysis reduced false positives by 40%.

That's a memory a model can actually use. It has the abstract pattern (transferable) AND the concrete evidence (grounding). The model can decide whether the pattern applies here based on real outcomes, not just structural similarity.

The transfer scoring changes too. A skill backed by five successful episodes with clear lessons should score higher than a skill backed by zero episodes. The episode quality becomes part of the transfer decision.

And feedback updates both, the skill's confidence changes, AND a new episode gets recorded for this application. The episode chain grows over time, and future recalls get richer context.

Why This Is Actually About the Thesis

My research paper argues that intelligence becomes civilization-scale only through recursive environmental control loops, project, act, observe, revise, compound. Agriculture was the first time humans did this at scale. The agricultural threshold.

The current Brain system doesn't cross that threshold. It projects (learns a skill), acts (recalls it), but doesn't truly observe or revise. The skill never learns from its own application. It just accumulates abstract patterns with no connection to real outcomes.

The Memory Bundle changes this. Each episode is an observation. Each lesson is a revision. Each future recall that includes those lessons is compounding. The loop closes:

Learn: Execute a task → create skill + record episode (with what worked/failed)
Recall: Find matching skill → include its episodes as evidence
Apply: Model uses the procedure + the concrete lessons
Feedback: Record a new episode for this application → update skill confidence
Compound: Next recall is richer, it has more episodes, more lessons, more evidence

That's the recursive loop. That's the agricultural threshold. And the architecture for it already exists, it just needs the binding.

What About Track C?

This also explains why Track C was the only track that showed improvement. Track C tasks are routing decisions, complex, multi-path choices where the model has to weigh trade-offs. These are exactly the kind of tasks where episodic evidence would help most.

When someone says "last time we tried path A for a similar routing problem, it failed because of X, path B worked because of Y," that's genuinely new information. The model can't derive it from its weights. It's system-specific, run-specific, outcome-specific.

The current brain helped Track C even without episodes because the tasks are hard enough that any additional context, even a vague abstract skill, provides a useful scaffold. But imagine Track C with Memory Bundles, the model would get both the abstract pattern AND the specific outcomes from previous routing decisions.

Tracks A, B, D, and E didn't improve because the model already scores 9.3+/10 on them. It doesn't need help. No amount of memory, procedural, episodic, or otherwise, will improve a 9.5/10 response to a 10/10 response. The tasks aren't hard enough to require accumulated knowledge.

This isn't a failure of the memory system. It's a boundary condition. Memory helps when the task exceeds single-shot capability. It doesn't help when the model is already near-perfect without it.

What I'm Not Claiming

I want to be careful here, because I've been burned before by getting ahead of my own evidence.

I'm not claiming that Memory Bundles will definitely show large improvements. I'm claiming that the current system stores memories that are too impoverished to be useful, and I now understand what richer memories should look like.

I'm not claiming the ceiling effect is the only problem. The pairwise-rubric disagreement at 62% vs +0.06 suggests position/length bias is still contaminating the pairwise results. That confound exists regardless of memory architecture.

I'm not claiming this is a new idea. Cognitive scientists have written about memory binding for decades. What's new (maybe) is applying it to agent memory systems where the default assumption seems to be that one type of memory, usually RAG-style document retrieval, is sufficient.

And I'm not pretending the community feedback didn't shape this thinking. When TechPulse Lab wrote that episodic and institutional memory matters more than procedural memory, they were describing exactly the gap I ended up finding. When Nova Elvaris pointed out that skills can only grow, never decay, that's the absence of failure episodes. When Kuro said memory maintenance matters more than storage, that's about binding quality, not storage quantity.

I just didn't understand what they were telling me until the numbers forced me to look harder.

What Happens Next

The code changes needed are surprisingly small. The Episode system is already built, episode.py, episode_store.py, episode_recall.py are all production-ready with tests. What's needed:

Binding: Add episode_ids[] to Skill, add skill_id to Episode. When brain.learn() fires, it creates both and links them.
Unified recall: When brain.recall() finds a matching skill, it fetches the associated episodes automatically. The prompt template includes both the abstract procedure and the concrete lessons.
Transfer scoring: Episode quality becomes a component of the transfer score. Skills with successful episodes score higher.
Feedback loop: brain.feedback() records a new episode for the current application, so the skill's evidence base grows over time.

Then re-run the benchmark. Specifically on Track C-difficulty tasks, where the model actually needs help.

I'm not going to promise the numbers will be different this time. I've been wrong before, twice now, measured against my own benchmarks, published for everyone to see. But I understand something I didn't understand before: a memory without experience is just a note. A memory with experience is a skill.

The plumbing metaphor from the first article still holds. But I was plumbing one pipe when the system needs at least four, all flowing into the same tap.

All benchmark data, scripts, and results are publicly available in the OrKa repository. The full result files include every individual task response, judge score, and pairwise comparison. If you want to re-run the analysis: python aggregate_benchmark.py --judge-tag local.

If you've worked on agent memory systems and found similar walls, or found ways through them, I'd genuinely like to hear about it. The comments on the first article were more useful than most papers I've read on the topic.

This is part of an ongoing series about building OrKa, an open-source YAML-first agent orchestration framework. Previous installments: Part 1: Plumbing Instead of Philosophy.