Three OpenAI Engineers Shipped A Million Lines. Your Ten-Hour Agent Run Starts Here

Channel: Nate B Jones
Published: 2026-08-12
URL: https://www.youtube.com/watch?v=HZLPhPbw3fM

AI agent context files are what keep a long agent run on track once your opening prompt goes stale. Here is how OpenAI, Anthropic, and Arize actually structure them, and the four files you can copy.

Grab the Working Context Starter Kit on Substack

Transcript

Three engineers at OpenAI shipped an internal product in about a tenth of the time it would have taken by hand. Roughly 1,500 poll requests. It was a codebase over a million lines by the time they were done. Not a line of it was typed by humans.

A few days ago, I made a video arguing that you should effectively keep your agents' desk neat and tidy if you wanted it to do useful work. I'm going to continue that in this video, but I'm going to talk about the biggest, boldest things we do with agents today—the long running work we do maybe over multiple agent sessions over 6 hours, 8 hours, 10 hours, more. I'm going to tell you the secret of how good engineers and good builders manage those sessions and how you can too. And hint: it's not just by keeping your metaphorical desk clean.

The set of files that you want to get all of this to work for you is over on the Substack. I'll tell you all about it at the end of the video, but before I want to give you why it works and I want to give you the principle so that you understand—regardless of how you use agents or whether you work with Codeex or Claude—how to actually do the work of shaping agent runs and accomplish ambitious projects.

That sounds great, but that's not the real story. Yes, it was a big project—roughly 1,500 poll requests, a codebase over a million lines by the time they were done. And yes, of course, not a line of it was typed by humans. Now individual codec runs that that team pursued ran for more than 6 hours, if not longer at a stretch. As it was running, the team had a context problem that anyone who's running an agent is going to recognize: a giant instruction file that you give an agent for a run like that will crowd out the task, and a huge manual for the project as a whole will turn into, in their words, a graveyard of stale rules.

In other words: how do you give the agent direction so you can accomplish a giant project without causing that project in its own rules to overwhelm the agent?

By the end of this video, you're going to know how to start one of these long projects before you know every step, how to change the direction without restarting, and how to make that correction reach the work the agent hasn't done yet. How to steer it as it goes.

More capable agents increase the reach of your judgment. They also increase the cost of leaving an outdated judgment in charge. So this method works across Claude, across Codeex, and across ordinary long conversations you have with AI, because the current state can live beyond any single session. I think this matters more than the headline context window number because it changes what you can safely put into motion.

OpenAI replaced that giant manual I told you about with a very short map. The map pointed Codeex toward active execution plans, toward decision logs, toward design documents, toward an architecture map, and quality grades for every part of the codebase it was touching. As the product evolved, those materials changed along the way. So they formed an accurate map of the current state of the execution as the giant codebase rebuild progressed. So the agent didn't need every old instruction competing for attention. It needed a reliable way to find the best current information for the next piece of work.

Anthropic has arrived at a similar practice with Claude. In its work on long-running scientific computing, Claude uses a progress file as portable memory between sessions. That file records the current state. It records completed work. It records known limitations and failed approaches with the reason they failed. So a new Claude session can read it, pick up the next task, and avoid walking into the same dead end on a giant project. Anthropic uses the same basic pattern in its long-running agent coding harness: a progress file, structured handoffs, and version history that let fresh sessions continue that job.

These are different companies. They're different systems, but they're responding to the same change. AI is moving from producing an answer to carrying work that develops over hours and days and many separate runs. Once that happens, context can't remain sort of like a frozen packet from the beginning of the job that you send out in a rocket. It doesn't work that way. It has to change as the work teaches you what the job actually is.

The stakes are very high, right? A long-running agent can take a useful direction much, much farther than a chatbot would. It can also take a slightly wrong direction through 6 hours of research and code and analysis and drafts before you realize how far off base you are.

So I call this practice progressive context shaping. You begin with a clear brief, sure, but then you change the small set of instructions and decisions that should govern what happens next. As the work continues to produce evidence along the way, that small current state receives priority over everything that happened along the way.

Good prompt engineering absolutely still matters. A strong opening prompt should define the result that you want. It should identify the materials the agent can use. It should set the boundaries on what it may do and may not do and give it a very sensible first move to try. If you know what quality looks like, you should say so in the instruction set. If publication or spending or deletion or contact with another person requires approval, that's another thing you should write down and say.

The opening prompt gives the agent enough direction to begin useful work and puts those basic guardrails in place. But the opening prompt is written before the work begins. It can only express what you know at that moment. A serious project produces information along the way. The research may weaken your original thesis. The first implementation may expose a dependency that changes how the architecture works. The customer evidence points toward a different use case. Potentially the first 50 results that you get could reveal that your original request will produce a lot of volume and very little value. So maybe this whole thing is not what you wanted it to be.

So at this point, the job is not to defend your original prompt or to sort of push through in a bullheaded way. The job is to change what the agent treats as the current version of the assignment. That is where prompting becomes less like placing an order and more like directing work.

I found myself doing this across a wide range of tools. Sometimes I interrupt Claude code while it is steering. I steer Codeex after reviewing a result or let a project develop through several turns in Claude or ChatGPT. I've kept the changing state in a current markdown file, in a plan, in JSON, in an issue tracker, and in a carefully updated conversation. So I've tried a bunch of different approaches, right? The specific container here matters much, much less than whether the next action gets an updated state on the run.

One of the clearest public examples we have of this comes from Arize. Its agent, Alex, was asked to summarize multiple traces. During one memorable run, the agent made 27 model calls. Almost all of them went into reorganizing its own to-do list. It kept moving information around without completing the assignment. Sometimes that does sound like AI, right? The original request had been buried under tool output and under intermediate results and the agent's own activity. And Arize didn't solve that by adding a more forceful sentence at the top of the prompt. The team decided to solve that by moving the current plan entirely outside the conversation window and storing it on disk. On every model call, the system rebuilt a short plan message from the latest state and placed it in front of the noisy history. The agent could see what was done, what was in progress, what came next. Doesn't that sound nice if you're the agent?

Arize's example separates transcript—the transcript of the work so far—from current context. That's really important. It's like putting the road safety signs up front. The transcript still held real information, but the maintained plan received much more authority than the pile of events that happened along the way. Arize gave the agent an updated answer to a very practical question: given everything that has happened, what should I be doing next? What should I be doing now?

That is close to how I use current.markdown in a personal workflow. It's an ordinary file, right? It's not a Claude or Codeex feature. Anybody can use it, and you and the agent just need to agree to keep it current. In Claude code, claude.markdown can tell Claude to read it at the start of the job and update it after every consequential decision. In Codeex, agents.markdown or the task itself can give the same instruction. In a normal chat, you can attach or paste the current state when you begin a new conversation.

In an ordinary Claude or ChatGPT conversation, the same practice takes on a couple of different forms. While the thread is still useful, you can steer it directly. And when a decision needs to survive, when it needs to transcend the current chat you're in, you just ask for a replacement project brief that reflects the new state and you read it and you correct it and you carry that brief into your next conversation. The old thread becomes history and the brief says what's true today, what's true now.

You don't need to preserve every correction this way. You want to save the change only when it affects what you're going for—your target for this run, your goal, the definition of done. If you would be annoyed when a fresh agent misses the decision that you would want to make, then you should put it in the project state or you should have the agent put it in the project state. On the other hand, if it only helps explain how you got there, it probably doesn't belong in that file. It probably is just in the history and you cannot mess with it a lot.

Other coding agents expose project rules or instruction files that can point to the same kind of state. While a multi-agent system might use a ticket or a JSON record or a database. OpenAI's Symphony system uses a project board to define and track real work. Whether the mechanism is markdown or an issue in Linear, the next agent action has to read the updated decision.

I learned the value of this in a long Codeex project of my own. I was building a benchmark across a really large set of my own work. So the run discovered 339 different sources and it generated over a thousand questions and it produced 250 verified answers. And that was real progress. And then the delegated agent began repeatedly continuing itself during package synchronization. In other words, it was still active but it stopped adding useful value. The original objective had encouraged continuous stress testing, and early in the run that instruction helped the agent to kind of keep going. But at some point it became the wrong instruction.

The useful next move was no longer to generate more questions or keep the continuation loop alive. It was actually to deepen the evidence behind the most valuable answers we discovered to questions along the way and then to stop. So I stopped the run and I changed the state. The saved record said the project was checkpointed after a retry loop and prohibited resuming the unbounded run. And the next pass would select the 50 highest value answers to those questions, replace generic evidence with evidence specific to each question, validate the package and stop.

All completed work remained available under a new direction. That is progressive context shaping in a real project. Because what I found was I was getting stuck because the old instruction was essentially pushing the agent too far in a direction that was unhelpful for ultimately getting my goal accomplished. The next run needed to do different work. So I changed the agent state it would inherit and turned an open-ended generation job into a very bounded job that was supposed to finish up. So then I got 1,000 questions, 250 answers, and a source map that remained useful. So at the end of it, I actually got the questions and answers that mattered the most to me and I got real value.

Anthropic's scientific computing example shows the same move at a smaller scale. In one solver project, the progress notes record that an attempted method was too stiff and name the method that replaced it. A new Claude session doesn't need to relive the entire failed attempt. It can see the failure and move on. It just needs the consequence, right? This approach failed for this reason. Use this replacement. Continue from the current state. This is what helpful forgetting can look like for agents.

The system doesn't erase the evidence of the old attempt. That the history can remain in a change log somewhere. But the failed method doesn't have the same position as the active plan. The agent carries the lesson forward without carrying every single token that produced the lesson and kind of getting confused along the way.

Now, there are four kinds of context worth separating here, and I'm going to go through all four.

The first is stable instruction. How to work, where to find things, what actions require approval, and what standards should remain in force. Claude might read that from claude.markdown. Codeex might read it from an agents.markdown file. It's a markdown file, right? Another tool might call it project rules. You get the idea.

The second is current project state. What the goal means now, which decisions are active, what remains unresolved, what should happen next, and when the agent really needs to stop. This is often changing material, and it may live in again a markdown file, a ticket, a structured data, but it's different. It's different from the actions that require approval. It's different from the guardrail stuff. It's really about the condition of the goal.

The third is the map. What material exists and where it lives? How does the agent get resources? Research files, design documents, transcripts, prior drafts. The agent doesn't need all of it in front of it right now. It needs a reliable way to find the bit that matters for the next decision. Most people will skip this layer. And skipping it is why they end up just kind of pasting everything in. Have you ever done that?

The fourth is history. What happened before, what changed, why a decision was made, and how to recover an earlier version. Git, or a change log, or a decision log. Transcripts, they're all useful history. And history matters, but we want history to not masquerade as current instructions. So we keep it as a separate set of data that the agent can access instead.

OpenAI used exactly this separation in that million-line project I talked about at the beginning of this video. A short agents.markdown map, the repository, active execution plans carried progress and decision logs, and design and architecture documents held deeper knowledge. The team even ran recurring work to find stale documentation and update it along the way. And so instead of squeezing a million line

(capture appears truncated)