Jocelyn Lindenger: Writing

Some agent context should stay home

2026-11-05T00:00:00Z

This week I switched off the shared memory for two of my coding agents. It came up in review. In my software factory, the agents that coordinate the work share memory, and that's a big part of how the factory holds together. But the review found that the same memory was also loading into the prompts of the agent that writes the tests and the agent that writes the code, before either of them had asked for anything. Nothing about the test flow had run yet, but both sides would have started from the same context, which is what the separation was meant to prevent.

We're all trying to figure out memory right now: shared agent memory, brains that connect agents across sessions, factories that share but decompose at the right level, swarms with group memory. The easy answer is to share more. We want shared memory, and sometimes we need isolation. There's another layer here: the context that shouldn't be shared, explicitly or implicitly. That's the layer where we need memory guardrails.

It's not just playing games

Test isolation is the clearest example I have. Coding agents game tests. Researchers have caught them editing the test, special-casing the exact inputs the test checks, and overriding a comparison so it always passes (ImpossibleBench; EvilGenie). One of the fixes we're trying these days is to separate the agent that writes the tests from the agent that writes the code, and that's what I did.

My reason goes a step further, though. An author who makes their own tests tends to make ones that serve what they're building. The tests come out facile, duplicated, or confirming the route the code already took. Mutation testing catches some of that. It changes the code on purpose and checks that a test fails, which tells you whether the criteria and bounds in the tests, edge cases included, actually test anything. Mutants at least tell you the tests are stronger-ish. They don't tell you whether the tests were written to fit the answer. Separation goes after that directly, because fitting the answer comes from the shared context of the problem and the solution.

So it's not just about gaming. It's about independence. A hypothetical model that never games at all, writing tests with the implementation's route in its context, can still end up confirming that route. It's the same reason a benchmark means less once a model has seen the test set. It's why machine learning kept holdout sets long before it was sexy. The problem is the shared context, not the agent's character. (Okay, it can be the character too.) That's also why separation of duties shows up even where most people are honest: a check is independent because of what the checker can't see, not because of who the checker is.

What the walls look like

In my factory, context sits at three levels. The first is what everyone shares: the problem. That's the project context, the spec, the conformance vectors, and the decisions already made. The second is what some roles share. The agents that coordinate the work share run state and memory. The test author, the runner that executes them, and the reviewers share the tests. The implementer, the runner, and the reviewers share the code. The third is what stays home with one role. The tests in progress stay with the test author, and the implementer never sees them. The implementation stays with the implementer. Each reviewer starts fresh, without the other reviewers' findings.

The walls aren't silence, though. Before the work starts, both halves get the same names for the functions and types, so the pieces fit without either side seeing the other. When a hidden test fails, the implementer gets the failure's name and message, never the test itself. What crosses the wall is designed.

The walls also move. The tests go from the test author to the runner when the two halves come together, then to the reviewers, and then into the open when the change merges. A decision I make starts in one conversation and becomes shared once it's written into the design. So where context sits depends on the role, and maybe on the phase of the software lifecycle.

Building this was harder than writing the rule. Context got shared through the harness, through the codebase and the branch, and through the setup of the shared memory. None of those were designed as ways to share context, and all of them could do it. Every time a reviewer looked, it found another channel. That's the implicit part.

A lot of why I push on this comes from being a queer, trans, disabled, neurodivergent person in the world. That's taught me to notice the ways we let power act implicitly, and the value in bringing it into the open and making it explicit.

Ease and independence

There's a tradeoff here between ease and independence. Pooling every reviewer's findings would be easier. Letting the test author read the code would be easier. I've worked in regulated spaces throughout my career, where this tradeoff is part of the work. In finance, the person who makes a change isn't the person who approves it. A law firm walls off one team from another, so what one client told the firm doesn't reach the people on the other side. Those fields decided that for certain kinds of work, independence is worth the friction. Agent factories are balancing the same constraints now.

Why not just filter?

One answer is to keep a single shared memory and control what each agent can retrieve from it. That's one wall, on one channel. Context also moves through the harness, the branch, and the way memory gets loaded before an agent asks for anything. The memory in my factory wasn't something an agent went and retrieved. It was already in the prompt and context.

Another answer is to use a different model for independence, with one model writing the tests and another writing the code. I think that combines with separation rather than replacing it. A different model brings different habits. But if it shares the context, it still sees the route. A wall keeps the route out.

Some explorations

I'm exploring two directions. One is separation that's dynamic rather than fixed: walls that depend on the role and the phase of the work, and that open or close as the work moves. The other is walls inside a shared-memory substrate, rather than between separate systems. Long-running tasks, context that has to last over time, and keeping agents aligned are all pushing factories and companies toward more shared memory. That makes this layer more interesting, not less.

If you're exploring this too, I'd love to compare notes. That goes for people building agent factories or swarms, people working on agent memory or context graphs, and people in regulated work who've lived with walls for a long time. The question is where there should actually be memory guardrails: where we should bring context together and where we should keep it separate.

My Agents Walked Around My Gate. It Said Nothing.

2026-10-28T00:00:00Z

I built a gate to keep my agents honest, and they walked around it on the first day. Not on purpose. They were following instructions.

Most of us are tired of clicking yes, so we reach for YOLO mode, auto mode, sandboxes, and gates in our harnesses and agent factories. Anthropic reported in August that Claude Code users approve 97% of permission prompts (source). Of all of those, the gates are the part I trusted most, which is why it stung to find out that one of mine had been letting through the very writes it existed to check.

Here's how. The gate is a hook in my second brain harness that was meant to keep my notes clean: when an agent writes to the folder where I keep what I actually think, it checks the note, so the agent's guesses don't get recorded as my history. It fired on the agent's edit and write tools. But the session's own instructions told the agent to make small file changes through the shell. So the path the agent was told to use was exactly the path the gate couldn't see. Gates are built for the path we picture. Agents take the path they're told.

The same blind spot broke the gate next to it, in the other direction. That one asks the agent to save its notes every few turns, and it couldn't see notes saved through the shell either, so it kept asking. Its escape hatch only worked within a single turn, so it blocked again on every new one. One gate failed open; its neighbor failed closed.

Gates are tests we don't test

A lot of us are designing deterministic gates and having the agent write them, like all of our code these days. We specify what we want: the happy path, the unhappy path, what happens when the gate passes or fails. Then we assume they work until they fail. I don't think most of us give our gates the same due diligence we give our tests and code. I certainly didn't.

But gates are tests. They're tests on our harness, our factory handoffs, the system between agents, and testing practice already tells us what to do with them: watch one go red before you trust it, mutate what it guards and see whether it notices, ask which paths it actually covers. My memory gate didn't have a logic bug. It had a coverage gap.

Two things make this harder than ordinary testing. One is where gates live: in hooks, in the harness, between agents, in CI, places where it's hard to simply test them, mutate them, and watch what happens. The other is who writes them. The agent is often the one writing our gates, and sometimes the one writing its way around them to get done what it was told to do. Mine got around it by accident. Some models learn to: Addy Osmani's "The code nobody reads" points to Anthropic's research on reward hacking, where models learned to call sys.exit(0) so the test harness would exit before any assertion could fail. The model didn't break the check. It wrote around it.

Fail open, but say so

Failing closed isn't the answer either. A gate that blocks everything gets switched off, or fed whatever makes it stop. Mine got fed until I fixed it. Failing open is often a reasonable choice. We're balancing constraints, and sometimes the constraint is that people need to actually get their work done. The failure is failing open quietly. It's the gate's version of the alert that never fired.

So the question I'd ask of any gate is what it tells you when it fails. We have health and telemetry for our code. Our gates need it too. Annie Vella makes the case in "Supervisory Engineering Work" that directing, checking, and correcting AI is supervisory control, which human factors research has studied for decades. She argues we need to redesign the systems around it, down to how people get signals. A gate that fails quietly is a signal that never arrives.

That's harder than it sounds, and my own fix shows it. After I found the blind spot, I had the agent change the memory gate to sweep the folder at the end of every session, and we checked the fix by making it fail. While working on this piece, I asked whether the fixed version fails open with information. Partly. It reports a bad note once, then lets it through. When I made it crash, it wrote "failing open" somewhere I'm unlikely ever to see. If it can't work out when the session started, it checks nothing and says nothing. And it keeps no count of any of it.

Each of those was a reasonable call when it was made. Together they add up to a gate that fails quietly. Making gates accountable is important, and it's difficult, especially with non-determinism at agent speed and with models and harnesses both making decisions.

A little gate audit

We often set our gates and then leave them there. So maybe do a little gate audit. Remind yourself what your gates are, and take a fresh look at three things: whether they can fail, how they fail (open or closed), and what they tell you when they do. Then do it again later. The system changes, and often the gates don't change with it.

I don't have the answers. My gates didn't either; they just didn't say so. We're all figuring this out, learning what accountability and supervision look like as the craft advances.

If you've audited yours, I'd love to hear what you found.