Why long tasks need workflows, not longer contexts
A task that fails in one long conversation often succeeds when it is split into isolated subagents with explicit success criteria, external state, and an independent reviewer.
The longest-running failure in agent work is the task that is almost done. You give an agent something substantial, it starts well, and then somewhere in hour two the quality curves downward. It forgets a constraint it followed correctly thirty steps ago. It re-solves a problem it already solved. It reports success on something it did not finish.
The instinct is to blame context length and reach for a bigger window. That helps a little, and it does not fix the actual problem.
What actually degrades
A single long context is a single shared workspace, and everything that happens in it is permanent. Every failed attempt, every stack trace, every file you read and did not need, stays in the transcript and competes for the model’s attention with the instructions that matter. The signal-to-noise ratio of the context falls steadily as the task proceeds, and the model’s behaviour follows it down.
There is also no checkpoint. If the run goes wrong at step 40, there is nothing to go back to. The error is woven into the same history as everything good that happened before it.
The structural fix
What reliably helps is treating a long task as a workflow of bounded units rather than one continuous conversation. Five pieces do most of the work.
Isolated subagents. Each subtask runs in its own clean context, sees only what it needs, and returns a result rather than a transcript. The parent never inherits the subtask’s dead ends. This is the single biggest change, because it converts “context that only grows” into “context that gets reset at known boundaries.”
Explicit success criteria. Each unit needs a statement of what done means that can be checked by something other than the agent’s own optimism. A test that passes, a file that exists with a specific shape, a schema the output must validate against. Vague instructions produce confident wrong answers, and Anthropic’s own prompting guidance makes the same point in a simpler setting: be explicit about the output you want rather than hoping it is inferred. That advice scales up to workflow design almost unchanged.
External state. The durable record of what has been decided and what remains should live outside the conversation, in files or a task list the workflow reads and writes. State kept only in context is state you lose at the first compaction or crash. State on disk survives a restart and can be inspected by a human mid-run.
Parallel work. Once units are isolated and have clear contracts, the independent ones can run at the same time. The benefit is partly wall-clock speed, but the more useful effect is that parallelism forces you to define the boundaries properly. If two subtasks cannot run concurrently, it is usually because you have not actually separated their responsibilities.
Independent review. A separate agent, with no memory of how the work was produced, checking the result against the criteria. An agent reviewing its own output is grading its own homework with full knowledge of the reasoning that produced it, which is exactly the context that makes mistakes look reasonable. A reviewer that only sees the artifact and the requirement catches things the author structurally cannot.
Two corrections worth making
I want to flag two claims I have seen repeated, because I was asked to write about them and they do not hold up.
The first is that ultracode is an official command. I have not found an
official source establishing that, and I would not describe it as one. If it
exists in your setup it is a local or community convention, not a documented
product feature, and the distinction matters when someone tries to use it
expecting documented behaviour.
The second is that Anthropic has just released a named workflow product. I am not stating that, because I have no official announcement to point to. The patterns above stand on their own merits regardless of what is or is not shipping under a brand name. Describe the pattern; do not promote it to a product it may not be.
The Bun case, with its caveats
The most interesting public example I have seen is Bun’s own account of rewriting a large amount of their codebase in Rust, which by their description leaned heavily on running many Claude workflows in parallel. It is a genuinely large mechanical translation done at a pace that would be hard to reach by hand.
The caveats are the important part, and Bun states them themselves rather than leaving them to be inferred. A rewrite like that works because the target behaviour is already pinned down by an existing, substantial test suite. The agents were not deciding what the code should do. They were moving known behaviour across a language boundary with a fast, mechanical oracle telling them when they got it wrong. Remove the tests and the same workflow produces a large volume of plausible code nobody can verify.
That is the condition I would put on all of this. Workflows let you attempt longer tasks; they do not let you skip the part where something outside the agent checks the result.