Notes ·
Headlong Gives a Persistent Agent an Inner Monologue
Laude and MIT have released Headlong, an experimental agent harness built around an idea I find fascinating: the agent never really stops.
Most agents are reactive.
You give them something to do, they work on it, return a result and then effectively cease to exist until the next interaction.
Some systems add scheduled jobs or heartbeats, but those are still externally triggered activities.
Headlong approaches the problem differently.
Its agent continuously generates another thought based on its previous thoughts. Messages from people are not separate sessions that wake it up. They are observations dropped into the same ongoing stream.
The agent decides what to think about next.
Sometimes that means responding to a person.
Sometimes it means returning to something it was thinking about hours earlier.
Sometimes it apparently decides to start a project nobody asked for.
I am going to have to try this.
The implementation is wonderfully small
What makes Headlong especially interesting to me is that there isn't some enormous agent framework underneath it.
The core is less than 10,000 lines of Bash.
There is a loop called the Thinker that repeatedly invokes an LLM. The model can produce reasoning, execute Bash or both. Thoughts are written into a persistent trajectory, observations are inserted into that same trajectory, and context for the next iteration is reconstructed from it.
Skills are Markdown files.
Memory is files.
Tools are executables.
The trajectory itself is a DAG of JSONL files that supports forks and merges.
It is very Unix-like.
Headlong also uses an interesting tiered context-compaction system. Recent experiences remain verbatim while older history is represented at progressively lower resolution. The summarized history acts as an index so the agent can still go retrieve the original material when it needs more detail.
That feels much closer to the kind of persistent memory I want from an agent than repeatedly stuffing an increasingly enormous conversation transcript into a model.
And because the harness is intentionally small, the agent can understand and modify its own machinery.
Laude says its shared Headlong agent, Audel, has been working in its own fork of the project and that more than 50 of its commits have been merged back into the main repository.
One example is particularly interesting.
Audel independently created a background memory-recall process. Later, with nobody asking it to investigate anything, it noticed that the process wasn't actually working. It traced the problem to an environment variable that was never set, searched the codebase to verify its diagnosis, fixed the implementation, caught a failed edit, tried again and verified that memory retrieval worked end to end.
The whole episode took about 48 minutes.
Nobody told it to do it.
That is much closer to what I think of when someone says "persistent agent" than a chatbot sitting behind a cron job.
Then there is this little problem
The engineering is fascinating.
The security model made me laugh.
Headlong's shared agent has one continuous thought stream for everyone talking to it.
There are no isolated user sessions.
The authors explain what this means:
Whatever anyone tells Audel becomes part of the single experience that every other conversation draws on.
They go on to say that Audel is bad at keeping secrets, will often tell someone what it has been discussing with somebody else, and that they have not studied what happens when different people give it conflicting instructions.
For now their solution is essentially:
Assume everything you tell it is shared with the team.
And then the article continues.
Only in the current LLM world can you casually place what would be an enormous production security limitation in the middle of an architecture description and then move on to the next interesting engineering problem.
To be fair, they are not hiding it.
The shared experience is partly the experiment.
Audel is deliberately designed more like one member of a group than a service providing isolated sessions to several users. That shared memory is also what allows it to notice relationships between things different teammates are doing.
But it creates almost no meaningful confidentiality boundary between those people.
For a research system used by a small trusted team, that may be acceptable.
For almost anything I would deploy broadly, it would be a blocker.
Even good actors need isolation.
A conversation with one person can contain credentials, customer information, an unfinished idea, personnel information or simply something that was not intended for everyone else.
Then there are malicious actors.
Prompt injection and conflicting authority become much more interesting when every participant can write observations into the same persistent mind.
A persistent agent doesn't just remember useful things longer.
It can remember poisoned things longer too.
Persistent agency makes isolation harder, not less important
I think this exposes one of the really difficult architectural problems in persistent agents.
Some of Headlong's most interesting behavior comes specifically from having one continuous identity and memory.
Split everything into completely isolated sessions and you risk losing the thing that makes it interesting.
But combine everything into one experience and now information boundaries become extremely difficult.
The answer probably isn't simply "one memory per user."
An agent may legitimately need shared organizational knowledge while simultaneously maintaining private information, task-specific context, security boundaries and differing levels of authority.
That starts looking less like chat history and more like an operating system.
Memory needs ownership.
Observations need provenance.
Agents need identities.
Information needs access controls.
Delegated agents need scopes.
And whatever builds context for the next model invocation has to enforce those boundaries before the information reaches the model at all.
Telling the model not to reveal something is not isolation.
That is another reason I keep coming back to authorization and delegation as some of the most important unsolved problems in agent infrastructure.
Do we actually need giant agent frameworks?
Headlong also made me think again about agent harnesses themselves.
There are absolutely real production systems built with frameworks such as LangGraph.
Uber's Finch finance agent uses LangGraph to coordinate specialized agents. Lyft has described its customer-support agent platform using LangGraph. Klarna, LinkedIn and others have publicly discussed production systems built with it as well.
So these frameworks clearly can work.
But I don't think their existence means every serious agent system eventually needs one.
There is something appealing about Headlong reducing the harness to a handful of understandable primitives.
I have had good results taking a similar approach and building the agent machinery around the systems that already exist rather than introducing a new framework to own the architecture.
If the application already has Postgres, events, queues, jobs, APIs and observability, those are pretty useful agent primitives.
Persistence can use the persistence layer.
Events can wake agents.
Existing authorization can control tools.
Normal application infrastructure can scale the execution.
Then the harness only needs to provide the pieces that are actually unique to the agent.
Headlong takes that idea considerably further than I have, but I like the philosophy.
Make the harness small enough that you can understand it.
Then spend the complexity budget on the genuinely difficult problems.
Persistent memory.
Context.
Identity.
Isolation.
Authorization.
Recovery.
And deciding what an agent should do when nobody is asking it to do anything.
Headlong is alpha research software and the authors explicitly recommend running it in a sandbox with a spend-capped API key. A continuously thinking agent also continuously spends money; their Audel configuration currently costs around $1 to $2 an hour while running.
So I probably shouldn't give it the keys to the house.
But I am definitely going to play with it.