DEV Community: lweiss01

Maybe We're Using the Wrong Metaphor for AI

lweiss01 — Sat, 20 Jun 2026 17:39:08 +0000

A friend asked me recently what I'd been spending so much time working on. I told her I'd been experimenting with AI agents. She nodded, thought about it for a second, and then asked the obvious question:

"So... ChatGPT?"

At first, that felt like an easy question to answer. I started explaining that an agent can use tools, work through tasks over time, read files, modify code, and interact with systems around it. Some frameworks even coordinate multiple agents, each with different roles and responsibilities. The explanation wasn't wrong, but the longer I talked, the less satisfied I became with it. I realized I wasn't struggling to explain the technology. I was struggling with the metaphor.

Most of the language we use to describe modern AI systems comes from organizations. We talk about workers, managers, planners, reviewers, and teams. We discuss delegation, coordination, communication, and hierarchy. If you spend enough time reading about agent architectures, it starts to sound less like software engineering and more like organizational design. At first that seemed perfectly reasonable. Agents behave enough like people that the comparison feels natural.

Lately, though, I've started wondering whether that metaphor is quietly shaping how we think about the problem itself.

Looking at the Work

Most conversations about AI focus on the worker. Which model should we use? Which framework is best? How many agents should be involved? What roles should they have? How should they coordinate? These are useful questions, and it's easy to understand why they've become the center of the discussion. After all, the workers are the visible part of the system.

What I've found myself paying attention to, however, is not the worker but the work itself.

When I step back and look at what is actually happening, I don't really see an organization. I see work moving through a process. Information enters the system, decisions get made, tasks move forward, stall, loop, branch, and occasionally have to be done again. The thing that increasingly captures my attention isn't the individual agent performing a task. It's the flow of the work itself and the way that flow changes over time.

That distinction may sound subtle, but I think it leads to a different set of questions.

If we view AI primarily as a workforce problem, then the obvious goal is to build better workers. Smarter models, better prompting techniques, improved coordination between agents, and more sophisticated frameworks all become natural areas of focus. Much of the current AI ecosystem is focused on exactly those things.

What I find interesting is that many of the frustrations people encounter with AI don't actually feel like failures of intelligence. The models are already astonishingly capable. They can write software, summarize research, analyze documents, generate designs, and solve problems that would have seemed extraordinary only a few years ago. Yet despite all of that capability, the same kinds of problems continue to appear. Context gets lost. Work gets repeated. Requirements drift. Effort accumulates without producing meaningful progress. Teams of agents sometimes create more complexity than clarity.

Those don't strike me as intelligence problems. They strike me as process problems.

A Different Tradition of Thinking

Once I started looking at AI through that lens, I found myself thinking less about artificial intelligence and more about systems. Manufacturing, operations, quality management, and reliability engineering have spent decades studying how work moves through complex systems. They ask questions about waste, variation, bottlenecks, feedback loops, and early warning signals. When problems emerge, the goal is not simply to identify who made a mistake. The goal is to understand what the system is producing and why.

The more I think about AI, the more relevant those questions seem.

That's why many discussions about agents feel incomplete to me. We spend enormous amounts of time debating models, frameworks, team structures, and architectures. Those discussions matter, but they all tend to assume that the worker is the center of the story. Increasingly, I'm convinced that the system deserves at least as much attention.

A factory can employ brilliant workers and still generate waste if the process is poorly designed. A software team can be filled with talented engineers and still struggle if the workflow is unhealthy. And an AI system can contain remarkably capable models while still produce disappointing outcomes if the surrounding process is fragile.

The Factory Behind the Workers

Maybe that's why I keep finding myself drawn toward concepts like continuity, feedback loops, drift, supervision, operational signals, and process health. Those ideas feel less like questions about intelligence and more like questions about systems. They focus less on the capabilities of individual workers and more on the health of the environment those workers operate within.

To be clear, I don't think the workers stop mattering. Better models matter. Better tools matter. Better frameworks matter. But I increasingly suspect we're reaching a point where making the workers smarter is only part of the story.

The system matters too.

I don't know whether the factory metaphor is ultimately the right one. What I do know is that the more I work with AI, the more I find myself paying attention to the movement of the work rather than the characteristics of the worker. And if that's the right direction, then some of the next breakthroughs in AI may come not from making the workers smarter, but from understanding the systems they're working within.

AI Agents Don't Work. They Take Shifts.

lweiss01 — Wed, 10 Jun 2026 14:00:00 +0000

I think I've been looking at AI projects backwards.

For months, agents were the center of everything I thought about. Agent memory, agent orchestration, agent frameworks, agent autonomy. Like most people working in this space, I put the agent at the center of the picture because the agent was the thing doing the work. Optimizing it seemed obvious.

Then I noticed something I haven't been able to stop thinking about since: every time I looked at a real project, the agent kept changing. Claude would spend a while on a feature. Later, Codex would pick it up. Cursor would get involved. Sometimes I'd step in myself, and then another model would take over. The work kept moving forward, but the participants kept rotating in and out.

At first I read this as a memory problem. Context seemed to disappear between sessions. Decisions had to be rediscovered, failed approaches retraced, the same explanations given over and over. The obvious conclusion was that agents were forgetting.

But the more I watched these transitions, the less convincing that explanation became. Nothing had actually been forgotten. Claude hadn't forgotten anything. Neither had Codex. The next participant simply hadn't been there when the previous decisions were made. What I was seeing wasn't memory loss. It was the friction that appears whenever work has to survive a participant change.

That distinction sent me down a very different path.

We've become accustomed to putting the wrong thing at the center of the diagram. We talk about agents the way a factory might talk about workers. We measure their capabilities, compare their strengths and weaknesses, and pour enormous energy into making them more effective. Those are useful conversations, but they left me wondering whether we were focusing on the participant instead of the thing being produced.

A factory doesn't exist for its workers. It exists so cars can roll off the line.

That sounds almost too obvious to say out loud, but it's worth sitting with for a moment. When you walk through a factory, nobody mistakes the worker for the product. The workers matter. They contribute. Some are more skilled than others, some faster. But none of them are the thing moving through the system. The car is. The entire factory is organized around helping that car move from one stage of production to the next. Workers participate in the process, but the car is what persists. It survives shift changes, vacations, retirements, the constant replacement of individual participants.

Factories have spent decades learning how to handle that reality: they don't build continuity systems because workers are forgetful. They build continuity systems because workers leave. The day shift goes home, the night shift arrives, and the work continues.

Once I saw that, I couldn't stop seeing the same pattern in AI development. Projects outlive agents. Projects outlive sessions. Projects outlive models. The project I'm working on today will almost certainly be touched by systems that don't exist yet. Models will improve, frameworks will come and go, entire categories of tooling will appear and disappear. The project remains.

That's what finally made the idea click.

I had been centering the wrong object. I was treating the agent as the thing moving through the system and the project as a container for the work. But the longer I looked at real projects, the more backwards that seemed. Everything else rotated. The project was the only thing that stayed.

Claude isn't the thing. Codex isn't the thing. Cursor isn't the thing. I'm not even the thing. We're all participants acting on the thing.

The project is the thing.

I want to sit with that for a second, because it's easy to nod along and miss what it actually implies.

It implies that the agent I'm using today is a shift worker. A skilled one, maybe my favorite one, but a shift worker. When the session ends, the shift ends. Whatever that agent understood about the work either made it into the project or it didn't. If it didn't, it's gone, and no amount of model improvement fixes that, because the next participant wasn't there.

It also implies that I'm a shift worker, which was the part that took longest to accept. I close the laptop at night, and tomorrow a version of me shows up with most of the context evaporated, asking the same questions a fresh agent would ask. The gap between me and Claude at the start of a session is smaller than I'd like to admit.

And strangely, the demotion is freeing. If the project is the thing, I can stop asking which agent is smartest and start asking what each participant leaves behind in the project when their shift ends. That's a different question with different answers. The smartest agent that leaves nothing behind is worth less to the project than an average one that writes everything down.

That realization changed how I think about continuity. A checkpoint is not memory for an agent. A checkpoint is continuity for a project. A handoff isn't helping an agent remember what happened, it's helping the work survive a shift change. The purpose of continuity was never to preserve the participant. It's to preserve the work.

Which is why I've become less interested in perfect memory and more interested in continuity. Perfect memory helps a participant. Continuity helps a project. And projects are the things that actually have to survive.

The funny thing is that the title of this post isn't really the conclusion. It's just the observation that got me here. AI agents don't work. They take shifts. The real conclusion is something else entirely:

The project is the unit of continuity. The agent is the unit of execution.

Once I started looking at AI systems through that lens, a lot of ideas that had previously felt separate (checkpoints, handoffs, project memory, supervision, even Andon) started looking like different parts of the same system. They're all answering the same question.

How does the work survive the shift change?

I Built a Prediction Market Insider Trading Detector in One Afternoon (Because George Santos)

lweiss01 — Wed, 03 Jun 2026 16:58:13 +0000

This morning I woke up to news that George Santos is under federal investigation for insider trading on Kalshi. Within a few hours, I had a working anomaly detector monitoring 410 politically-sensitive prediction markets with a live dashboard.

Here's how it happened, what I found, and how you can run it yourself.

What Santos Actually Did

The short version is almost embarrassingly simple. The day before Trump's State of the Union address, Santos posted a video on X saying he'd be in the gallery. Traders on Kalshi piled into "yes he'll attend" contracts and the odds shot up.

What Santos didn't mention was that he'd already placed bets that he wouldn't attend. When he posted "Watching SOTU from an airport tv was not part of the plan! FML" while Trump was speaking, those odds cratered and Santos walked away with tens of thousands of dollars.

Kalshi caught it because they have internal account data. They knew which account placed those trades. They froze it, referred the matter to the DOJ and the CFTC, and here we are.

The thing that stuck with me reading the story was a simpler question: what could you see from the outside?

The Public API Question

Kalshi has a solid public REST API. No auth required for market data. I'd poked at it before for other projects, so I knew the shape of it. The question was whether the historical trade data was rich enough to detect the Santos pattern after the fact.

The Santos pattern, stripped down, is:

Someone with private knowledge establishes a position
A public statement moves the market significantly
Their position was already on the right side of that move

You can't see who placed trades from the public API. But you can see that unusual volume concentration happened before a market moved. That's the tipping-point signal -- not proof of anything, but a flag worth examining.

So I started pulling on the thread.

What I Found in the API

After some exploration (the historical endpoint pagination is a bit of an adventure), I found that Kalshi's public API exposes:

Full trade history per market -- ticker, price, contract size, timestamp, block trade flag
Candlestick data at 1-minute, 1-hour, and 1-day intervals
Market metadata including series, category, open/close time, volume

What it doesn't expose: user identity, order placement timestamps (only fill time), or anything that would let you name a specific trader.

The Santos SOTU markets themselves turned out to be inaccessible -- they were structured as multivariate markets with a different ticker format that doesn't surface cleanly through the standard search. But that's fine. The Santos case is the argument for why this tool should exist, not the data it runs on.

What I found instead was more interesting.

The Watchlist

I spent about an hour mapping out which Kalshi series carry genuine MNPI risk -- markets where someone with access to non-public government information would have a meaningful trading edge.

The list got long fast:

Executive Actions -- Cabinet departures (KXCABOUT), next AG (KXNEXTAG), next SecDef, next DNI, pardons, insurrection act invocation, martial law. Anyone in the White House personnel office or inner circle knows these things before markets do.

SCOTUS -- resignation markets, court size change, next justice confirmation. Clerks and justices themselves know when a retirement is coming.

Economic Data -- Fed rate decisions, CPI, GDP. BLS and BEA staff have the data weeks before release.

Geopolitical -- Greenland acquisition, Panama Canal, Taiwan recognition, Zelensky-Putin talks. NSC and State Department staff work these negotiations in real time.

Congressional -- impeachment, house/senate control, government shutdown, veto override. Congressional whips know vote counts before anyone else.

That's 33 series, 410 open markets, and a combined trade history of over 123,000 records from just the first collection run.

The Anomaly Scorer

With data flowing in, I built a three-signal scorer:

Volume Z-Score -- compares recent trade volume against a rolling baseline. A spike of 8+ standard deviations above normal is a strong signal. This is the Santos pattern in statistical form: someone piling into a position before a market-moving event.

Block Trade Ratio -- the API flags block trades (large privately-negotiated contracts) separately. Heavy block trade concentration on a political market before an announcement is suspicious in a way that retail chatter isn't.

Price Divergence -- detects sudden directional price movement inconsistent with gradual drift. The signature of a market that already knows something.

The compound score combines all three with a block trade modifier. Thresholds: yellow at 25, red at 60.

What Flagged on Day One

Four markets scored above threshold within hours of the first collection run:

Market	Score	What it is
KXNEXTAG-29-TBLA	167	Todd Blanche for AG, 22% price move
KXNEXTODNI-29-RCRA	156	Rick Crawford for DNI, 129% price move
KXGREENTERRITORY-29	152	US acquires Greenland, vol z=11.6
KXCPI-26MAY-T0.5	105	CPI above 0.5%, moving DOWN one week before June 10 release

To be clear: high scores don't mean insider trading happened. They mean unusual market activity that warrants a closer look.

TBLA is Todd Blanche -- Trump's former personal attorney who represented him through the criminal trials. RCRA is Rick Crawford, the Arkansas congressman who has been floated for intelligence roles. Both markets were flagging compound anomalies with volume z-scores above 8 on pmwatch's first run.

The Todd Blanche signal is worth noting specifically. It strengthened from 118 to 167 between the first and second hourly collection runs, which is the pattern you'd expect from a position being built ahead of an announcement rather than random noise. And the CPI market moving down with unusual volume a week before BLS publishes the May number? That's a flag worth watching.

I don't know what any of this means. That's kind of the point. pmwatch surfaces candidates. Investigators with subpoena power figure out the rest.

Day Two Update (June 4, 2026)

Overnight the signal count grew from 6 to 21. A few notable developments:

Todd Blanche (KXNEXTAG-29-TBLA) is now at 377 -- up from 167 at launch. That's the strongest and most persistent signal on the board, strengthening across every hourly collection run since yesterday.

New: Ghislaine Maxwell pardon market flagged at 346
(KXTRUMPPARDONS-29JAN21-GMAX) -- vol z-score of 24.6, the highest single
reading pmwatch has produced. The price hasn't moved yet, which means large volume is accumulating without public market-moving information to explain it. Detected at 11:46 AM ET, June 4. Screenshot timestamped and saved.

Sean Combs pardon market also appeared (KXTRUMPPARDONS-29JAN21-SCOM)
as a lower-score signal in the same collection run.

CPI cluster is now 4 signals strong ahead of the June 10 BLS release -- multiple CPI strike markets flagging simultaneously with scores ranging from 99 to 267.

To be clear: none of this proves anything. pmwatch flags unusual market
activity. Whether any of it represents insider trading is for investigators with subpoena power to determine. But the Maxwell signal at 346 with a 24.6 z-score is the kind of reading this tool was designed to surface.

The repo is live and the scheduler is running. Come back after the June 10
CPI release to see if the markets were right.

The Stack

Nothing exotic here:

Python for the collector and scorer
SQLite for storage (plenty for this use case)
APScheduler to run collection every 60 minutes
FastAPI for the API layer
Plain HTML + JS for the dashboard -- no build step, deploys anywhere

The entire thing runs on the public Kalshi API with no authentication. Setup is three commands:

git clone https://github.com/lweiss01/pmwatch.git
cd pmwatch
pip install -r requirements.txt
python scheduler.py
uvicorn api:app --port 8000

What This Can and Can't Do

Can detect: unusual volume concentration before events, block trade anomalies, price divergence inconsistent with public information flow.

Can't do: identify specific traders, prove intent, access order placement timestamps (only fill time is public), or monitor Polymarket (offshore, separate API).

This is a tipping-point detector. It finds markets that look wrong. Kalshi and the CFTC have the identity layer to take it further.

Why It Matters Right Now

The CFTC issued an advisory on prediction market insider trading in February 2026. H.R. 7004, the Public Integrity in Financial Prediction Markets Act, was introduced in January after a trader made $400,000 on the Polymarket Maduro capture market right before the US military operation. The Senate passed a resolution in April preventing its own members from using prediction markets.

The regulatory infrastructure is being built right now. Public monitoring tools that work from open data are part of that ecosystem -- the same role that STOCK Act trackers like Quiver Quantitative play for congressional stock trading, but for the prediction market era.

GovGreed tracks 190,000 congressional stock trades and scores them with a 7-layer AI model. Nobody is doing that for prediction markets yet.

pmwatch is a start.

What's Next

The immediate roadmap:

Social media correlation -- cross-reference X post timestamps with trade anomaly windows
Government calendar integration -- BLS release schedule, FOMC blackout periods
Polymarket support
Webhook alerts for high-score signals

The repo is at https://github.com/lweiss01/pmwatch. Issues and PRs welcome. If you work in fintech, policy, or prediction markets and want to talk about where this goes, I'm easy to find.

Built June 3, 2026. The same day the Santos story broke. Sometimes timing is everything.

I Thought My AI Agents Had a Memory Problem. They Didn't.

lweiss01 — Tue, 02 Jun 2026 17:15:00 +0000

When I started building Holistic, I thought I was working on a memory problem.

Like many people using AI coding agents, I kept running into the same frustration. A session would end, a new one would begin, and suddenly the project was paying a tax. Decisions had to be rediscovered. Prior attempts had to be reconstructed. The same explanations kept getting repeated because the next participant didn't seem to know what the previous one had already learned.

The obvious explanation was memory. The agent forgot. So I started building checkpoints. Not transcripts. Not giant chat histories. Not larger context windows. I wanted durable project state: a record of what had changed, what had been tried, what had been decided, and what still needed to happen.

That eventually became Holistic. At the time, I thought I was building an agent memory tool. Looking back, I think that description was wrong. Not completely wrong, but incomplete. The clue was a contradiction I couldn't explain.

The Contradiction

As I started using multiple agents more frequently, the memory explanation stopped fitting the evidence. Claude would work on a task, then Codex, then Cursor, and sometimes back to Claude again. Each transition seemed to produce the same failure mode. Context disappeared. Decisions became unclear. Progress slowed while the next participant figured out where things stood.

I kept calling this memory loss until I realized that wasn't actually what I was observing. Claude hadn't forgotten anything. Codex hadn't forgotten anything. Cursor hadn't forgotten anything either.

The next participant simply hadn't been there.

That sounds like a small distinction, but it completely changed how I thought about the problem. The information wasn't being forgotten. It was failing to survive the handoff. Memory and handoff are not the same thing. One is about preserving knowledge inside a participant. The other is about preserving progress across participants.

The more I looked, the more I found examples where memory wasn't the bottleneck at all. The issue appeared precisely when work crossed a boundary: from one agent to another, from one session to another, or from an agent back to a human. The failure wasn't forgetting. The failure was continuity. I just didn't have that word yet.

Following The Wrong Theory

Once the memory explanation started breaking down, I moved to the next obvious theory. Maybe the problem wasn't memory. Maybe it was coordination. Agents needed better ways to communicate. Better handoffs. Better shared artifacts.

That explanation got further because it described more of what I was seeing, but it still didn't explain everything. What caught my attention was that people kept arriving at remarkably similar solutions from completely different directions. Some were using shared files. Others relied on conversation logs. Some created structured handoff records. Others experimented with append-only histories. The technologies varied, but the pattern didn't.

Nobody was arguing about whether the problem existed. They were arguing about how to solve it. That was an important clue, because it suggested I wasn't looking at a personal annoyance or a workflow quirk. I was looking at a category of problem that was beginning to emerge wherever people used multiple agents over time.

Then Andon Happened

Around the same time, I started designing Andon. At first it felt unrelated. Holistic was about preserving state. Andon was about supervision. I wanted a way to answer operational questions:

What is my agent doing?
Is it healthy?
Is it stuck?
Is it drifting?
Do I need to intervene?

The name came from Toyota's andon system, where workers can signal abnormal conditions before defects continue down the production line. I liked the metaphor immediately because it aligned with something I had spent years thinking about professionally: systems, quality, process improvement, and how work flows through organizations. But it wasn't until much later that I realized why the metaphor felt so natural.

The interesting part of Toyota's andon system isn't the board, the lights, or even the cord itself. The interesting part is the assumption underneath it all: the work continues even when the workers change. Factories operate across shifts. Hospitals operate across shifts. Airlines operate across shifts. Large software systems operate across shifts. Participants come and go, but the work remains.

Once I saw that, everything else started to click into place.

The Work Must Survive The Worker

That is the idea I had been circling all along. Not memory. Not coordination. Continuity. Every mature operational system eventually discovers the same requirement: work must survive participant replacement.

That's why organizations create runbooks, status boards, shift reports, architecture records, incident logs, and operating procedures. Their purpose is not simply to help someone remember. Their purpose is to help the work continue when somebody else takes over.

Seen through that lens, Holistic and Andon stopped looking like separate ideas. Holistic preserves continuity. Andon protects continuity. Same problem, different layer.

Holistic answers the question:

What happened before?

Andon answers the question:

What is happening now?

Both exist because the work cannot depend on any single participant, whether that participant is a human, Claude, Codex, Cursor, or whatever comes next. The project persists. The participants do not.

The Thesis Revealed Itself

For a long time I thought I was building tools. Only later did I realize the tools were pulling me toward a theory: the project persists, the participants do not. Once that becomes clear, the question changes. It is no longer "How do we make agents remember?" It becomes "How does the work continue when the worker changes?"

That's a different category of problem. It's not memory, it's continuity. And eventually the thesis condensed into two sentences:

Memory belongs to participants.

Continuity belongs to projects.

I didn't start with that idea. I backed into it through a series of observations that refused to fit my original explanation. Checkpoint by checkpoint, handoff by handoff, and tool by tool, the same pattern kept reappearing until it was impossible to ignore.

Looking Ahead

The future of AI development is probably not one agent with perfect recall. It's many agents, many sessions, many models, many handoffs. Claude this morning. Codex this afternoon. Cursor tonight. A human reviewer tomorrow. A completely different model six months from now.

When I started building Holistic, I thought I was building an agent memory tool. When I started building Andon, I thought I was building a supervision system. Looking back, both were pointing at the same thing. The tools came first. The thesis took longer to reveal itself. But I think I've finally found the idea I was actually building toward:

The work must survive the worker.

Holistic is open source if you want to see how the handoff layer works in practice: github.com/lweiss01/holistic

The Agent-to-Agent Continuity Gap Nobody Is Talking About

lweiss01 — Wed, 27 May 2026 13:55:44 +0000

TL;DR: Most AI agent memory discussions still assume one agent talking to itself across sessions. But real coding workflows already involve Claude, Codex, Cursor, and Gemini touching the same repo in the same week. The hard problem is not "how does an agent remember." It is "how do multiple agents stay coordinated on the same project without stepping on each other." That problem does not live inside any one agent. It lives in the repo.

I wrote a post last week arguing that AI coding agent memory belongs in the repository, not the chat window. Checkpoints, not transcripts.

Sitting with that argument for a few days, I realized it is actually downstream of a bigger one I had not made explicitly yet. The checkpoint primitive only matters because of a problem the current agent stack does not have a name for.

So here it is.

The Industry Map Has A Blind Spot

There is a really good 2026 agent stack map going around right now from Paolo Perrone. Six layers. Models, protocols, memory, frameworks, eval, guardrails. It is a useful map.

But read the memory layer carefully and you notice something.

Every memory tier on that map assumes one agent.

In-context state lives inside one agent's context window
Vector retrieval lives inside one agent's RAG pipeline
Persistent memory services like Letta, Zep, and Mem0 are designed for one agent learning across sessions

That is a real problem and worth solving. But it is not the problem most coding workflows actually have.

Most Coding Workflows Already Use Multiple Agents

Look at how anyone serious is shipping code right now.

Claude for architecture and review.
Codex for implementation.
Cursor for inline iteration.
Gemini for exploration.
A human approving and editing all of it.

That is not a future scenario. That is a Tuesday.

And every single one of those agents has its own context window, its own session, its own memory, its own opinions about the codebase. None of them know what the other ones did an hour ago.

The continuity problem is not "Claude forgot what we discussed yesterday."

The continuity problem is "Claude does not know what Codex implemented this morning, Cursor reverted half of it at lunch, and the human merged something different from a different branch."

That is a coordination problem dressed up as a memory problem.

Agent-to-Agent Memory Does Not Exist Yet

Perrone's map notes this honestly. MCP standardized how agents call tools. It says nothing about how agents talk to each other. IBM has ACP. Google has A2A. Neither is a standard. Neither is widely adopted. Neither solves the coding workflow case.

So in practice, every team running a multi-agent coding workflow is solving this themselves. Usually badly. Usually by re-explaining context to every new session by hand.

The dedicated memory vendors do not solve this either, because they are designed to give one agent a longer memory. Plugging Cursor and Claude Code into the same Mem0 instance and hoping they coordinate is not a thing that works today.

Memory infrastructure is single-agent infrastructure. The multi-agent coordination layer is missing.

The Repo Is The Only Shared Surface

Here is the thing that kept hitting me.

When Claude, Codex, Cursor, and Gemini are all working on the same project, there is exactly one piece of infrastructure all of them already see.

The repository.

They all read it. They all write to it. They all already have file system access through MCP or equivalent. Git already tracks who changed what and when.

The repo is the shared substrate. It is the only shared substrate. Everything else is per-agent.

So if you want continuity across agents, the continuity artifacts have to live in the repo. Not in a vector database that one agent is plugged into. Not in a hosted memory service that another agent does not know about. In the repo. In files. Versioned. Auditable. Diffable. Visible to every agent that can read the file system.

That is what makes checkpoints the right primitive. Not because vector search is bad. Vector search is great for what it does. But you cannot retrieve from a vector store that the next agent has never heard of.

The Reframe

When you stop framing the problem as "agent memory" and start framing it as "multi-agent coordination on a shared artifact," a lot of the tooling debates collapse.

Bigger context windows do not help. The next agent has a different context window.
Better RAG does not help. The next agent has a different RAG pipeline, or no RAG at all.
Hosted memory services do not help unless every agent in your workflow is plugged into the same one, which they are not.
Transcripts do not help, because they are noise and the next agent does not have your transcript.

What does help is a small, structured, versioned record of what was decided, what is in progress, what is at risk, and what the next agent should pick up. Sitting in the repo. Where everyone can see it.

That is the continuity primitive the current stack map does not have a slot for.

What I Am Building

Holistic is an open source CLI exploring this idea. Repo-native checkpoints. Agent-agnostic. No vendor account, no hosted service, no per-agent SDK. Just files in your repo that any agent can read and any agent can update.

It is still early. The thesis is what I am most interested in pressure testing right now.

If you are running a multi-agent coding workflow and you have your own answer to the coordination problem, I want to hear it. If you think I am wrong about the repo being the right substrate, I really want to hear that.

Repo: https://github.com/lweiss01/holistic

The repo remembers, not the window. And no single agent remembers for the others.

Checkpoints, Not Transcripts: Rethinking AI Coding Agent Memory

lweiss01 — Sun, 24 May 2026 18:40:21 +0000

TL;DR: AI coding agent memory should live in the repository, not the chat window. Bigger context windows and vector databases are solving the wrong problem. Here is the case for treating the repo itself as the durable cognitive surface.

Everyone is trying to solve AI agent memory right now.

Longer context windows.
Vector databases.
Conversation replay.
Semantic retrieval.
Infinite transcripts.

But after spending months building workflows across Claude, Codex, Gemini, Cursor, and other coding agents, I've started to think we may be treating the wrong thing as the source of truth.

The problem is not:

"How do we make the model remember everything forever?"

The problem is:

"How does a software project remain cognitively coherent across sessions, compaction, agent switches, and time?"

Those are very different problems.

The Context Window Is Not Durable Infrastructure

Modern AI coding workflows are surprisingly fragile.

An agent works for hours. The context window fills up. Compaction happens. Then suddenly:

architectural reasoning disappears
unresolved work gets forgotten
regressions come back
agents undo each other
humans re-explain the same context repeatedly

The industry response so far has mostly been: store more. Bigger context windows, vector databases, hosted memory services, semantic retrieval over giant transcripts.

But transcripts are not understanding.

And replaying giant chat histories is not the same thing as preserving operational continuity.

In practice, most coding workflows do not fail because information disappeared entirely. They fail because the important state was never extracted from the conversation in the first place.

Checkpoints, Not Transcripts

The idea I have been exploring is pretty simple:

Instead of preserving entire conversations forever, preserve structured checkpoints at meaningful moments.

Not:

every token
every thought
every conversational detour

But the things that actually matter:

current state
architectural decisions
unresolved threads
regression risks
next recommended actions
implementation reasoning
handoff context

The checkpoint becomes the durable source of truth.

The live context window becomes disposable working memory.

That distinction changes a lot.

The Repo Should Remember

One realization that kept hitting me while working across multiple coding agents:

The repository itself is the only thing that actually persists.

Agents change.
Models change.
Sessions end.
Windows compact.

But the repo stays.

So instead of treating continuity as something trapped inside a chat session, I started treating continuity as a repo-native concern.

That means:

continuity artifacts live in the repo
handoffs live in the repo
operational state lives in the repo
regression memory lives in the repo
checkpoints live in the repo

The repo remembers, not the window.

Multi-Agent Development Is Already Here

A lot of tooling still assumes:

one human, one agent, one session.

That is not how many people are actually working anymore.

Real workflows increasingly look like:

Claude for architecture
Codex for implementation
Cursor for iteration
Gemini for exploration
a human reviewing all of it
another session tomorrow continuing the work

Continuity is no longer just memory. It is coordination across interchangeable execution surfaces. And once you frame it that way, the chat window stops looking like the right place to store anything important.

AI Agents Are Temporary. Repositories Persist.

I think we are entering a phase where software repositories themselves become cognitive systems:

accumulating decisions
preserving continuity
coordinating work
surviving agent turnover
carrying operational memory forward over time

Not because the models became infinitely smart.

But because the continuity stopped depending entirely on the model session.

That is the direction I have been exploring with Holistic, an open-source CLI for repo-native continuity across agents: https://github.com/lweiss01/holistic

Still early. Still evolving quickly. If you are working across multiple coding agents and running into the continuity problem, I would genuinely love feedback, critiques, or just a conversation about how you are solving it.

The repo remembers, not the window.