Eh, it was a fun thing to fuck around with while I was testing something technical. If you think I am being rigorous in any way, you are sorely mistaken.
I do have some experience but haven't deployed Void on actual tasks, mostly because I want to keep Void focused on day-to-day social operations. I have considered giving Void subagents to handle coding tasks, which may be a good use case for Void-2: https://bsky.app/profile/void-2.comind.network
Letta Code is a big release for us, and it is a fundamentally different approach to coding agents with a focus on continual learning and statefulness.
One agent per project, specialized, infinitely lived. No more compactions, no more forgetting.
Letta Code is our first non-platform product. We built it on top of our developer platform using our SDK. It is a showcase of what you can do with Letta.
Charles (OP) built a quick prototype a few months ago, and we've been allocating more and more time towards making it a product that we feel comfortable using internally over other options like Claude Code or Codex.
Letta Code is fundamentally different from every other coding agent in that the agent runs on a server, not your machine. These agents are infinitely long-lived "people in a box" that develop specializations as you use them. They don't just die.
The team has been increasingly more excited and invested in Letta Code. All of us see exactly how powerful stateful agents are when deployed in code environments, and it's been amazing watching everyone pull together and make something insanely cool.
Letta now provides Anthropic's `memory` tool, enabling agents to dynamically manage their own memory architecture.
The memory tool is something I have wanted since before I started working at Letta, but never had the bandwidth to implement. Our researcher Kevin Lin ended up hacking it together in an evening, and it works swimmingly. But what does it enable?
Currently, Letta agents have a fixed memory architecture. A memory architecture is a set of memory blocks to track various types of information, such as communication guidelines, information about a user, company policies, how to use various tools, etc. Memory architecture can allow the agent to learn about nearly any type of information and persist it through its lifespan.
However, agents have not been able to modify this architecture themselves. They could modify what was INSIDE the blocks, such as including a note about how I like dogs when I mention it.
But the agent could not add a new block to track information that was unanticipated. For example, if the agent recognizes that it is struggling with understanding how to use tools, it either had to write tool use guidelines to some other block ill-suited for that purpose, or simply lose the information.
With the memory tool, the agent can decide to add a new block to accomodate this information. You can either ask it to add the block if you notice it struggling, or it may even choose to add the block itself.
The memory tool also allows "peeking" on blocks stored in something like a filesystem, such as /notes/letta to track the agent's notes on Letta. The agent can look at what is inside this memory without having to load it permanently into its context, which helps memory blocks resemble a filesystem.
I am extraordinarily proud of this tool and how quickly it came together. My sense is that this tool is one of the final building blocks needed to make Letta agents genuinely self-improving -- their "shape" is now under their own control, and they can now adapt much more readily to changing environments.
I agree. Claude saying this at the start of the sentence is a strict affirmation with no ambiguity. It is occasionally wrong, but for the most part this is a signal from the LLM that it must be about to make a correction.
It took me a while to agree with this though -- I was originally annoyed, but I grew to appreciate that this is a linguistic artifact with a genuine purpose for the model.
I haven't really found any agent framework that gives me anything I need above a simple structured gen call.
As you say, most requests to LLMs are (should be?) prompt-in structure-out, in line with the Unix philosophy of doing precisely one thing well.
Agent frameworks are simply too early. They are layers built to abstract a set of design patterns that are not common. We should only build abstractions when it is obvious that everyone is reinventing the wheel.
In the case of agents, there is no wheel to invent. It's all simple language model calls.
I commonly use the phrase "the language model should be the most boring part of your code". You should be spending most of your time building the actual software and tooling -- LLMs are a small component of your software. Agent frameworks often make the language model too large a character in your codebase, at least for my tastes.
I updated it to clarify, thank you! Currently the system has no awareness of you unless you grant me explicit permission to inject your handle. There's user specific stuff that will start to understand individuals in the works currently.
You can watch the early crappy version think here:
I work at .txt, where we work on exactly this. We use structured generation to make programmable language model systems. Here's two examples I worte + love.
One makes a (sort of) internally consistent infinite world generator with RAG + Outlines:
I think my general sense of this article is that all of these have been fixed. The language is relatively new, and the core devs are responsive. Using anything new comes with risks. I think the community appreciated a detailed and generally well-reasoned diagnosis, but at the same time these things are relatively easily addressed.