Very interesting: I wonder if the RL approach is diverging between Anthropic and OAI?
I noticed that Fable uses shell tools almost exclusively (even to search and edit files), compared to previous Anthropic models.
Having run some experiments with 5.6, I notice that it uses built-in file systems and provider native tools much more (not shell tools), compared to previous OAI models.
yes, basically people that want to host powerful, long-running agent runs not on dedicated VMs (although lightspeed can use those too), but on an abstraction layer above.
My thesis is that the right abstraction is durable workflow engines. And AFAIK, OAI also uses Temporal for their complicated hosted agent infra.
I think these kind of semi-coding agents--but hosted--are the future for enterprises. Claude Tag, Claude Cowork, now Work by OAI.
Agents-on-your-machine clearly have their place, but for many workflows this is too unruly. Hence, the "long-running agent running on shared infra" pattern.
I think this is where the ball is headed. I'm building towards an open source version of this[0]. Still just working on the core, but hopefully soon self-hosted versions can be built on top.
Oh man, I love capitalism spoiling us here. I was just enjoying my extra Fable credits, now I'll switch to using 5.6 this weekend. I was planning to ration my Anthropic credits, I guess now I do not have to. And I was half wondering if exactly this would happen: right when Fable usage credits were starting to kick in for people, OAI swoops in and takes the puck. As much the AI craze is crazy, this play by play part is pretty fun.
getting downvoted for my other answer. I wasn't clear: yes, there is of course a lot of prior art in pi, and pi specifically does not just store the session events, but adds an abstraction for easy branching which is great.
But what I tried to get at is the question what additional events you store to construct more than just the llm session log but also more fine grained events around the entire agent state, which of course depends on what you want out of your agent.
The paper here in question is going even further and is event sourcing a larger state than just the session transcript, specifically additional graph structures that are getting built as part of the session.
in my agent, specifically, I focus on the event sourcing all the stuff that makes an agent work well as part of a deterministic workflow, which again is prerequisite to run agents in durable workflow engines like Temporal.
most coding harnesses store the exact messages that have been sent to the llm and the messages items that have come back from the llm, not much else. Then, there is also a set of events/commands/etc that are in-memory only. Together they constitute the current state of the agent loop.
In Lightspeed, we store all of them as events, thus can always reconstruct the exact state of the loop (e.g. state of open tool calls, compaction decisions in-flight, etc). This makes it possible to run the agent in a durable workflow engine easily.
Very cool. I settled on the same/similar design in my agent harness.
All relevant events that affect the context window are stored in an event log. Forking agents and sessions is simply setting a pointer to the sequence number of another event log.
I work with large enterprises that _only_ run critical workloads on locally hosted models. Think banks, insurance, etc--businesses that absolutely cannot leak any data. They also have CC and Codex, but their use is extremely restricted; anything of consequence runs on models running on GPU clusters in their own datacenter.
Agent harness for durable workflows, starting with Temporal.
Most agents for durable workflows feel like toy examples. There is no "Codex" or "Claude Code" for, say, Temporal. So I'm building full-featured agent for these runtimes. Why? Because it makes long-running agents easier to operate and scale. Currently, all frontier harnesses need to run inside a guest OS and need a dedicated process, this is quite challenging to orchestrate and maintain.
To make it work, I had to figure out what part to run as deterministic workflow code, and what part to run as I/O or side effects (aka activities). I'm using a CAS for most of the payloads to maintain a lightweight footprint in the workflow code.
Currently supporting skills, MCP, prompts, a virtual file systems, and soon sandboxes.
Arguably, if your agent needs a lot of custom logic to drive the agent loop it isn't an "agent" at all. At best it is an agentic workflow, or rather a workflow with some LLMs calls in between.
I think that's why agent SDKs feel like the wrong abstraction. If you are writing a workflow, use a workflow engine (Airflow, Temporal, etc), and call some LLMs with a small LLM library. If you need a "real" agent, use a full-featured agent harness, like Codex or CC or Pi or whatever, then load it up with all the tools, skills, mcps that it needs, and let it rip.
Incidentally I've been building a full featured agent harness that runs inside durable workflow engines [0], but it is designed _not_ as an SDK but rather as a standalone, full-featured harness with an API.
This is why taking investments too early is usually a mistake. It locks you in to one hand. Of course, you can pivot, but it is much harder with investors looking over your shoulder.
I keep saying this is the single most important article to consider when talking about AI assisted software building. Everyone should read it. The question should always be: is a human building a theory of the software, or is does only AI understand it? If it's the latter, it is certainly slop.
(Second, albeit more theoretical, would be A Critique of Cybernetics by Jonas)
It's a tradeoff. Technically, you need very few programs, you can let an agent do everything and coordinate everything. But that is also inefficient, it's slow and uses a lot of tokens. So you allow the agent to build tools and coordinate those tools, just like we humans do. However, with agents, the threshold of pain is much higher, we can let agents do thing's "manually" where humans would build automations much sooner.
Agree. It's code all the way down. The key is to give agents a substrate where they can code up new capabilities and then compose them meaningfully and safely.
Larger composition, though, starts to run into typical software design problems, like dependency graphs, shared state, how to upgrade, etc.
Wall-mounted dashboards are a huge life-hack, especially if you have a family. We got a 37-inch touchscreen one, running DAKBoard.
We have several kids and have been organizing our daily todos and calendars on it for several years. We used to drop the ball quite a bit due to a hectic schedule and the dashboard has helped us tremendously. Since it is mounted in the kitchen, being able to pull up recipes is a plus.
I think sandboxes are useful, but not sufficient. The whole agent runtime has to be designed to carefully manage I/O effects--and capability gate them. I'm working on this here [0]. There are some similarities to my project in what IronClaw is doing and many other sandboxes are doing, but i think we really gotta think bigger and broader to make this work.