Copilot's HydraFusion Builds a Model Workflow Per Request — Your Project's Context Has to Live Outside All of Them (2026)

Five things in the post matter for this question, and all five are in GitHub's own words.

First, the unit of decision. "For each request, HydraFusion currently chooses one of three execution patterns." Those are Single, where "one selected model solves the task directly"; Cascade, where "an efficient model drafts a solution and a quality gate decides whether to accept it or escalate to a stronger model"; and Critique, where "one model drafts a result, an independent read-only critic from a different model family reviews it, and the drafting model revises once."

Second, the critic is deliberately walled off. GitHub lists "Isolated review" as one of five operating principles: "Run review steps in isolated, tool-less contexts, while solver steps use the shared workspace and normal permission-aware agent loop. This allows models to assess the work independently without modifying the repository." The critic reads. It cannot touch your files, and it does not carry your tools.

Third — the sentence the coverage skipped entirely — the record of what happened exists, but on the other side of the wall. "Internally, the runtime records the role, outcome, cost, latency, and diagnostics of each leg so the workflow can be understood after execution. Externally, the developer receives one coherent response and one permission-aware change set."

Fourth, intermediate work is withheld on purpose, and GitHub says why: "Today: HydraFusion shows workflow stages but holds intermediate drafts until it returns one coherent result," because "those drafts may be reviewed, revised, or discarded, so showing them live could make unfinished work appear final." GitHub names the tradeoff rather than hiding it — "Waiting without enough visibility is a real trade-off for developers" — and says it is "actively exploring better progress updates."

Fifth, the preview's own scope. "For this preview, first-turn, single-prompt coding tasks are the best place to start. We'll be focusing on strong multi-turn performance with longer, iterative sessions next." GitHub also flags that "results, models, workflows, availability, names, and product behavior may change as we learn from the preview." It runs through /experimental in Copilot CLI on all plans.

Together those five describe a system optimized to hand you one clean answer per request — a reasonable design goal, and one in which the reasoning that produced the answer is a runtime artifact rather than a durable one.

It does not change what a good instruction file does. Copilot still reads your instruction files, and GitHub's own engineering writeup from two days earlier makes the mechanism explicit: "Prompts carry instructions that shape how an agent works, and they are sent to the model on every turn." Instructions are re-sent, not remembered. That was already true with one model, and it is true with three.

It does change who is accumulating. In a single-model session, there is at least an intuition — usually a wrong one, but an intuition — that the model is "getting to know" the codebase as you go. With a per-request execution plan, that intuition has nowhere to attach. The critic that caught your race condition was, in GitHub's words, an "independent read-only critic from a different model family." It saw the draft, formed a judgment, and its judgment reached you compressed into a revised result. It will not be in the room next time, and no part of the chain is holding onto what it noticed. If routing is per request and the pool can shift as GitHub "evaluate[s] and incorporate[s]" new models, anything you want reliably present has to be stated somewhere the router cannot route around.

And this is not one vendor's quirk. Amp, from Sourcegraph, documents an almost identical architecture from a completely different starting point. Its Modes and Models page says Amp "uses different models for different kinds of work. The main agent handles your task, specialist subagents take on focused parts of it, and smaller system models handle supporting jobs," and that "the models can change as better options become available, while the role of each mode and subagent stays stable." On the isolation question, Amp is blunter than GitHub: its specialist subagents "work in isolation, so they can't communicate with each other, you can't guide them mid-task, and they start with the instructions and context the main agent gives them rather than the full conversation. The main agent only receives their final summary rather than monitoring their step-by-step work."

Two independent products, two independent documentation sets, same conclusion: composed execution buys quality and cost efficiency, and the price is that intermediate understanding is summarized rather than retained. That is an architectural result, not a criticism of either team. It just means the durable layer has to be somewhere else.

"It's just a cheaper model picker." The pricing framing led most of the coverage, and it misses that the composition changes per request. A picker chooses one thing. HydraFusion constructs a plan, and GitHub describes the move as "going from choosing the best model to dynamically constructing the best way to solve each task."

"So the critic's review is in my history." It is not, by design. You receive "one coherent response and one permission-aware change set." The per-leg record is internal.

"Multi-turn is coming, so this solves itself." GitHub says multi-turn performance is next, which is about the quality of longer sessions. A better session is still a session. Nothing in the post suggests cross-task persistence of what a run learned, and treating "multi-turn" as a synonym for "durable memory" is what leaves teams re-explaining in October the constraints they explained in September.

"Copilot has no memory, then." Wrong, and worth stating plainly. Copilot has documented memory surfaces, and this preview is not one of them. The accurate statement is narrower: HydraFusion's documented behavior covers execution planning and result delivery, and there is no documented counterpart in it to a store that accumulates project facts across tasks. That is a scope statement about the feature, not a claim about the product.

The move is not to fight the router. It is to stop asking any model in the chain to be the thing that remembers, and to put a small, explicit layer where every leg of every plan can read it.

Step 1: Separate the two kinds of context you are currently mixing

Split every line of your instruction file into one of two buckets.

The first is how to work here: build commands, review steps, style constraints, directories not to touch. This belongs in files, re-sent every turn, exactly as it is today. GitHub and Amp both handle it well and you should not move it.

The second bucket is what we established: the decision to move off the streaming parser and why, the fact that the payments service uses a different test command because of a vendor sandbox, the two approaches already tried on the flaky integration test. This bucket grows continuously, is discovered during work rather than written in advance, and is exactly what a per-request plan cannot hold — because the leg that discovered it was isolated and summarized.

If your instruction file currently contains bucket-two content, you have been using a re-sent prompt as a memory store. It works until it doesn't, and it silently competes for the same budget as bucket one.

Step 2: Capture at the moment of correction, not at the end of the session

The valuable material appears when you tell the agent it is wrong. That is the moment a constraint becomes explicit, and the moment you are least likely to write anything down, because you want the task finished.

Make it one action instead of a chore. When you correct the agent, state the correction as a durable fact — "the payments service tests run through make test-payments, not npm test, because the vendor sandbox needs the fixture server" — and send that sentence to your memory layer rather than only into the chat. The reason is what makes it survive contact with a future decision; a bare rule with no rationale gets overridden the first time it is inconvenient.

Step 3: Give every leg of the plan the same read path

The point of putting the layer outside is that it does not care which model is executing. A solver leg, a cascade escalation, and a fresh session tomorrow all reach the same store the same way. In practice that means exposing it over MCP, so any client that speaks the protocol can read it, and over an API for the surfaces that cannot.

That also fixes the isolation problem from the other direction. GitHub's critic runs "tool-less" by design, so it will not query anything mid-review — but the drafting model, which does use the shared workspace, can pull the established facts before it writes. Getting the constraint into the draft beats catching it in review.

MemoryLake is the layer we build for exactly this shape of problem: one store that outlives any particular model, session, or execution plan.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. The key is what lets a routed workflow, a CLI session, and a teammate's editor read the same facts without any of them owning them.

Step 2: Upload your first memories

Drop in the documents, images, and files that already carry your project's established decisions — architecture notes, the incident writeup behind the current retry policy, the design doc everyone still argues about. Start with what you are tired of re-explaining rather than trying to be comprehensive.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other agents access over MCP or the API. For Copilot CLI workflows, read the relevant memories at the start of a task so the facts are present in the draft, and write back the corrections you make during it.

The first thing you notice is the disappearance of a specific kind of repeat conversation. Not "what does this function do" — agents were always fine at that — but "we tried that in July and it broke staging." That sentence stops being something a human has to supply.

The second is that model changes stop costing you. GitHub says "when new models become available in GitHub Copilot, we can evaluate and incorporate them into its model pool." If your durable knowledge lives outside the pool, a change to the pool is a change to quality and cost, not to what your agent knows. That is the difference between an upgrade and a migration.

The third is that the isolated critic becomes less of a loss. You cannot see its reasoning, and probably should not want to — GitHub's argument that showing discarded drafts "could make unfinished work appear final" is sound. But when its judgment surfaces as a change you accept, you can record the conclusion in one sentence. The reasoning stays in the runtime; the conclusion becomes yours.

The fourth mostly matters to teams: a store any client can read is a store a new engineer's agent can read on day one, so the knowledge stops being a property of whoever had the long session.

Write conclusions, not transcripts. A routed workflow produces a lot of intermediate material you never see. Do not try to reconstruct it. Record the one-line outcome and the reason.

Keep instruction files for invariants only. Anything true regardless of what you are working on belongs in files; anything discovered belongs in the store. Mixing them puts discovered facts in competition with build commands for the same prompt budget.

Attach the reason to every fact. "Use make test-payments here" gets overridden. "Use make test-payments here because the vendor sandbox needs the fixture server" does not.

Record supersessions instead of deleting. When a decision reverses, say so and say when. An archive that keeps every version resolves nothing; a store that quietly drops the old version cannot explain the new one.

HydraFusion is a well-argued bet that the next gain in coding agents comes from composing models rather than picking one. Its five operating principles — isolated review, bounded execution, fail-safe application, validated routing, complete accounting — read like a team that thought carefully about running someone else's repository.

What the bet also does, quietly, is retire an assumption. There is no longer a single model behind your session that could plausibly be the thing that remembers. The router picks a new plan per request, the critic is walled off on purpose, and what reaches you is one answer and one change set. Amp documents the same shape from a different direction, which suggests this is where composed agents are going generally.

The practical response is small. Decide which of your context is invariant and which is discovered. Leave the invariant part in files where it already works. Put the discovered part somewhere no execution plan can route around, attach the reason to every entry, and let whichever model wins the next routing decision read it. Then the model pool can change as often as GitHub wants, and the only thing that changes is how fast your code gets written.