NavHarness is the machinery that lets a robot moving around a house keep reusing the map and exploration history it has built up — even after the "conversation" has been cut off — every time it gets a new request. It adds no training to the model (it is training-free); instead it pushes the act of reading and revising memory into every moment of navigation itself. The payoff: on GOAT-Bench it lifted the success rate over sessions that start from a blank slate every time by 18.6 points with Astra and 22.6 points with Opus 5, and it beat the previous best records even while relying on SLAM-estimated positions.
Today's frontier models already solve a single navigation task fairly well when you hand them nothing more than simple tools (observe and move). That comes from multi-round reasoning — look, think, move, repeat. The trouble starts afterward. A robot working in a home doesn't stop after one errand. It finds the remote in the morning, moves a package at lunch, and fetches the glasses in the evening. Each task begins exactly where the previous one left off.
This is where the usual approach breaks down. If you open a fresh conversation for every new request, the robot's body is still there, but the memory in its head has been reset. It re-searches a room it already combed through, and it can't use the note it wrote earlier saying "not in the living room."
But handing over the history brings its own trap. A record that an object "wasn't found" in some room doesn't mean every corner of that room was checked. A note jotted down earlier — "the sofa is blue" — may clash with what's in front of the robot now. Memory is incomplete, and it sometimes conflicts with the current observation. So neither blindly trusting memory nor ignoring it and starting over every time is the answer. That gap is exactly what the authors aim at.
NavHarness's idea sums up simply. Don't cram the act of reading memory into a single "pre-departure briefing" — pull it up repeatedly while you walk, check it against what's in front of you, and rewrite whatever is wrong.
A good analogy is a shift handover done thoroughly. Instead of one note left behind by the night-shift worker, you pass the next person a structured account of where you've looked so far, what you've ruled out, and what's still unresolved. NavHarness bakes this structure into code. Broken into a few components, it looks like this.
| Component | What it does |
|---|---|
| Session | A single multi-turn, multimodal conversation handling one exploration. The heart of the reasoning |
| Handover | When closing a task, summarizes the goal, the places explored, the evidence for the result, and the exploration left unfinished, and passes it to the next session |
| Recovery note | When retrying the same goal, carries the evidence so far and the remaining options into the new attempt |
| Ledger | A compressed index that leaves one line per closed task (goal, recorded status, place name). Later sessions find the relevant task and open its detailed record |
| Consolidation | When a run in one house ends, distills the task records into a "house note" to help the next run |
The key point is that these records are not dumped wholesale into the conversation window (the context). The robot opens and reads the files when it needs them, and seeks out additional records as the exploration unfolds. What makes this approach clever is that it handles memory with the already-proven habit of "a coding agent reading and editing files," rather than separately training a dedicated memory model.
Another important mechanism is verification. In the figure it splits into Verify (checking before stopping) and Certify (certifying after stopping). Why is it needed? Because later exploration leans on earlier records, a wrong "found it" declaration, once it hardens into experience, keeps contaminating everything downstream. So the evidence is weighed before a completion is promoted into a record.
The results should be read along two lines. Even when the numbers come from the same experiment, you have to separate the absolute value from the improvement margin to avoid confusion.
First, the improvement over blank-slate sessions. Compared with "context-only standalone sessions" that solve every task in a fresh conversation with no external memory, GOAT-Bench s-SR (the success-rate metric) rose from 65.1% to 83.7% (18.6 points) on the Astra backbone and from 58.9% to 81.5% (22.6 points) on the Opus 5 backbone. These are the gaps you get when you line up the standalone session's absolute performance and NavHarness's absolute performance within the same experiment. It's evidence that a design carrying memory forward pays off independently of single-task ability.
Second, the absolute performance. Even while using positions estimated by SLAM rather than the ground-truth positions the simulator hands out, the GPT-6 Astra combination of NavHarness recorded s-SR 83.7% and e-SR 36.9% on GOAT-Bench and s-SR 85.9% on IR2R-CE, beating the previous best scores. That it tops the charts even without the favorable condition of ground-truth positions makes it more convincing. The authors state that across all four backbones, both success rate and path efficiency improved over the standalone session on the same backbone.
The most interesting finding isn't a performance number but the analysis of what drives it. Handing over a structured recovery handover did better than handing over a plain summary matched to the same length. In other words, what decides success or failure isn't "how much you pass on" but "what you structure and how you pass it on." In long-horizon deployment experiments spanning several houses, navigation improved more when the map and task records were consolidated rather than merely preserved. The case studies include scenes where a misplaced marker is corrected only after nineteen tasks have passed, or where a later session picks up a failed exploration and finishes it.
The authors point out plenty of limits themselves. The evaluation was done on simulation benchmarks (GOAT-Bench and IR2R-CE), and the scope of validation for real physical environments and real-time operation is limited (see the real-world evaluation and runtime items in the paper's Limitations). The assumption of a static environment, how archive access will scale over longer deployments, and whether smaller models have the capacity to support it are all left as open questions.
And the case studies honestly include failure scenes too. There's a case where a wrong completion gets certified into memory (Case 7), one where the diagnosis was made but the information was lost during summarization (Case 9), and ones where the robot rejected stored experience (Cases 12–14). A design that carries memory forward also carries the risk of propagating not just good experience but bad experience — there's a trap here. That's why the verification gate is a necessity, not an option.
Reading this study as nothing but a robot story misses the point. What NavHarness actually addresses — "an agent that doesn't lose its experience even when a session is cut off" — is the same problem at the heart of an AI PM product.
Picture ONTLE's AI PM handling one client's request. In last week's PM session, it wrote: "Reviewed the payment integration request but put it on hold because we didn't get the card company's spec document." This week the same client files a new request: "please also add a refund flow." A typical agent today would start the new conversation from a blank slate, ask again about the earlier hold reason or the constraints already confirmed, or — worst case — repeat the exact same fruitless digging.
Drop NavHarness's structure onto this scene and it changes. The ledger indexes this client's closed requests one line at a time, and the handover passes the next session a structured account of "how far the payment review got and what it got stuck on." The PM session that receives the new refund request, instead of dumping that record wholesale into the prompt, opens and reads it when needed and checks it against the current request. It reaches on its own for the judgment that "since payment is on hold, the refund is bound to the same card company spec." Reviving the held payment request as a recovery note and continuing it is exactly the same move as the paper's "a later session resumes a failed exploration."
The lesson for ONTLE here is the finding that structure, not volume, is what matters. Passing the next PM a structured "what was confirmed / what was ruled out / what's unresolved" beats passing a long summary. And placing a verification gate before a completion hardens into a record — the warning that a wrong "handled, done" embedded in a client's history contaminates every judgment that follows — connects directly to why ONTLE already puts idempotency and verification on payout actions. If you want a PM that works for a lifetime, the message is that you should look at how you design session boundaries before you scale the model.
No. It's a training-free design: with no navigation-specific training, it only layers a memory-handling loop and tools onto an off-the-shelf frontier model. That's why the backbone model is swappable, and the paper reports improvements across all four backbones.
They come from the same GOAT-Bench experiment. On the Astra backbone the standalone session scores s-SR 65.1% and NavHarness 83.7%, and the gap is 18.6 points (Opus 5 goes 58.9% to 81.5%, a 22.6-point gap). So 83.7% is the absolute performance, and 18.6 points is the margin showing how much higher that performance is than a standalone session starting from a blank slate. The conditions aren't different — it's the same result viewed two ways, as an absolute value and as an improvement margin.
Many benchmark results assume the ground-truth positions the simulator hands out. NavHarness, instead of that favorable condition, used sensor-estimated positions and still beat the previous best record. That's meaningful because it's a score under conditions much closer to a real robot.
It does. The paper honestly reports cases where a wrong completion gets certified into memory (Case 7) or where information is lost during summarization. That's why it filters completion claims with Verify (before stopping) and Certify (after stopping), checking the evidence before anything hardens into experience.