Jonathan tested persistent goals in Codex by feeding Linear ticket acceptance criteria to agents with 20-30 turn budgets, treating it as a capability probe rather than production-ready. The core problem: looping agents only work if each loop has a skill competent enough to succeed. Peter Steinberger's advice is to convert repeated actions into automated skills, so future runs are free.
Goals in Codex are persistent objectives in Codex that keep a thread working toward a defined outcome across turns. A goal gives Codex a completion condition. What should be true, how success should be checked, and what constraints must stay intact. Jonathan, from your CTO perspective, you were mentioning you've been using goals in Codex, or you, you had tried it. What are your thoughts?
I just tested it out. I still don't consider it like a valuable tool that I use regularly in my workflow. It's more like, you know, okay, I'll pick up a ticket from Linear, and if it has really clear acceptance criteria that I can feed into the goal, I can say like, here, Alex. Allocate 20 or 30 turns towards like trying to accomplish this whole thing by yourself and see how far it can get. I'm really not expecting it's the best way to get my work done. I'm just kind of seeing like what's the model capable of at this moment in time. The idea here is good. I posted an article in our team learning section about, it's called What the Fuck is a Loop? Peter Steinberger versus Boris Cherny. And one of the key ideas there is like, that these looping agents are cool, but the underlying primitive that needs to get better is the skill. Like, for each loop, how does this skill get good enough to achieve the thing that it's supposed to do during the loop?
Steinberger's other recurring point pairs with the loops one and is the more durable half. If you do something more than once, turn it into an automated skill. And if you do something hard, turn into a skill afterwards. So next time it's free. That makes a lot of sense.
Yeah. Yeah. And we've seen a lot of tools to improve skills like GBrain's Skillifier function. We've seen auto research applied towards skill improvement.. And so I think if you're going to run /goal, you sort of want to have some like well-tuned skills that are, that are already proven that can do that. You're going to want to have an output criteria that's highly measurable by the LLM that it can know whether or not it's getting closer to it. And not every problem is a good fit for that, you know, but the, you know, the, the range of like what output criteria can a coding agent consider is getting like, you know, broader and broader with each release. And I think about this a lot actually. And, you know, like in Elon's algorithm, they talk about that every requirement for a system. So if you think about like specifying the requirement that is the endpoint for a slash goal. In Elon's companies, he said that every requirement has to have a human's name by it. Like if they're being really serious about engineering, really saying that this requirement matters, then who does it matter to? You know, what does it mean that it matters to them? Like what do they want to see? Right? And so I think when we think about like how to specify a goal, I think getting to that level of pedanticness about like, this is the self model of the user that needs to see this result in the requirement specification. But also, like, the reality of goals is that we successfully approximate the definition of them as we define them. And so having an adaptive goal, having it is like, you know, where I think these things will get useful. The looping pattern, the autonomous looping pattern with an adaptive goal that has a requirement set that has a subjective, like, judge of, like, what is achieved or not achieved. Yeah, so I'm thinking about ways of how to improve the autonomous looping pattern so that it can sort of, like, fill in some of those gaps right now. But in the meantime, I just kind of play with it as a toy.
