01
Long-horizon agents
Context windows got bigger. Memory did not. Four hours in, an agent is mostly working from a summary of itself, and the summary is where the errors live.
Open problem
What should an agent refuse to compress?
Most agent research assumes the work can leave the building. Ours assumes it can't. That meant rebuilding the harness, the compute, and the permissions underneath it.
An agent that runs for six hours is not a chatbot on a longer leash. It opens files no one listed, spends money no one approved line by line, and reaches hosts that were never in the plan — most of it after the person who asked has gone home.
The usual answer is to run it somewhere else: someone else's data center, someone else's jurisdiction, someone else's audit log. For most teams, that is the right answer.
The organizations with the most to gain from a six-hour agent are the ones that can't use one. Not won't. Can't.
So we build the other way.
Three products, stacked the way a ship is stacked. You stand on the top deck. The other two are why it floats.
A quiet room. Ask, hand off, come back to finished work. It picks up where you left off on any device, and nothing leaves your dock.
A hundred results don't become a hundred walls of text. Each one gets a line where it happened, and a place you can go back to.
Everything below this line runs on hardware you can walk up to.
Every tool, every hand, every permission, accounted for. Work moves through it in the open, and what it touches stays yours.
The allowlist is written while you are watching. The model never edits it, and has no way to ask.
The part you never see. Enough compute to matter, close enough to trust. Nothing leaves the ship unless you send it.
A measurement, not a policy — which is why it can also tell you when something did leave.
The dashed line under each is the part we haven't solved.
Context windows got bigger. Memory did not. Four hours in, an agent is mostly working from a summary of itself, and the summary is where the errors live.
What should an agent refuse to compress?
Benchmarks measure the model. Deployments fail on everything around it: tool schemas, retries, timeouts, the interrupt that lands mid-write. Most of the distance between a good demo and a working system is here, and almost none of it is in the weights.
Which failures belong to the model and which belong to the harness? There is still no clean way to tell them apart.
Running a serious model on hardware you already own is a scheduling problem before it is a hardware problem. Weights that don't fit, batches that never fill, eight people and one GPU.
What is the real floor — how much iron does a building actually need before this stops being a compromise?
Prompt injection is the famous one. The quieter problem is an agent that had permission for every individual step, and should not have had it for the sequence.
How do you prove what an agent did not do?
We would rather show four empty boxes than four numbers we can't reproduce. They fill in when the runs do.
Run 0417, plotted from its own event log: six hours on sealed hardware, compressed to forty-five seconds, including the parts where it sits and waits.
We take on a few partners at a time, and we choose by whether the constraint is real. Tell us yours.
Request a berthNotes from the yard when there is something worth reading. No cadence, no newsletter.