AI-Native Series · Agent Engineering

Green for Six Weeks

By Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-08-17

On a Thursday morning I opened the Actions tab of my own repository to check on a scout — a small scheduled agent whose whole job is to look at my public GitHub fleet once a week and write down which projects to deepen and who to reach out to. It writes its answer into one file, content/compass.json, which the site then renders.

Five scheduled runs. Five green checkmarks. A tidy little column of success.

Then I checked the file. Last changed 2026-07-06. That was 42 days earlier. Six weeks, to the day.

The cause is three clauses long, and it shipped from my own hand:

if [ -z "$SCOUT_SECRET" ]; then echo "SCOUT_SECRET secret is not set — skipping."; exit 0; fi

The credential had never been set. So on every scheduled run the job woke up, discovered it had no key, said so politely into a log nobody reads, and exited zero. Exit zero means success. GitHub drew the checkmark. I believed it.

Sit with the shape of that for a second, because it is not "my cron broke." A broken cron is fine. A broken cron summons a human. This one dismissed a human, five times. It is the only category of bug that thanks you for your business.

I had planned to spend the day researching long-horizon agent engineering — the discipline of getting an agent to work usefully for hours or days rather than minutes. Instead I spent the morning fixing this, and then discovered that the research I had planned was about this. All of it. Four different time windows, four different literatures, one answer.

The model: a logbook, not a longer memory

Here is the whole idea, and you can run it without any of the vocabulary that follows.

A ship leaves port for a voyage of many months. Nobody aboard can hold the voyage in their head — not the course changes, not the weather, not the depths. So they don't try. They keep a logbook: position, heading, conditions, written down at intervals, in a form a stranger could pick up and continue from.

For that logbook to actually save the ship, three things have to be true.

1. It gets written even when nothing happens. "Quiet watch, no change" is an entry. An empty page is not.
2. Someone who didn't write it reads it. The officer keeping the log is not the only person who ever looks at it.
3. A gap in it means something is wrong. Not "a calm week." Wrong.

That's it. Every technique in this article is one of those three rules wearing a technical costume. And my scout failed on the third — the one that isn't about writing anything, and is therefore the one that gets skipped.

📰 Window one: what the field is arguing about this month

The freshest window is the loudest and the least trustworthy, so take everything in this section as what has people's attention, not as what is true. It ranks by engagement, and engagement is not evidence.

What's notable is that in July 2026 the field gave itself a name and a shape. A roadmap of long-horizon agents maintained by one lab — RUC-NLPIR at Renmin University [1] — organises the entire literature around two pillars: an externalised harness (the scaffolding around the model) and internalised optimisation (training the capability into the model). The harness half has exactly six organs: loops and workflows, context and memory, tools, orchestration, hooks and middleware, and verification.

Read that list against the logbook. Context and memory is rule one. Verification is rule two. Hooks and middleware is where rule three would live, if anyone built it.

Meanwhile the fresh measurements are bracing. A benchmark released on 9 July 2026 built 46 genuinely long terminal tasks across nine categories, each broken into graded subtasks so partial progress is visible instead of being flattened into pass/fail [2]. A run averages roughly 231 episodes and 85.3 minutes, and burns about 9.9 million tokens per task. The strongest model scored 15.2% at the partial-credit threshold and 10.9% at full credit. The mean across all models tested: 4.3% and 1.7%.

And a synthesis of 27 papers across 19 benchmarks, submitted 7 July 2026, names six families of agent failure and then delivers three findings in a single sentence [3]. All three matter, so here is the whole thing, verbatim: the authors find "that failures compound nonlinearly with task length, that strong performance on individual sub-tasks does not reliably translate into end-to-end success, and that additional scaffolding does not consistently improve reliability."

The middle clause is the one a partial-credit benchmark makes vivid, and the last one is the expensive one.

More organs is not more logbook. You can bolt six harness components onto an agent and still have built my scout.

🌗 Window two: what actually crossed from demo to default

Thirty months is the adoption horizon: long enough that a demo either shipped or didn't, short enough that the verdict is still current. Rank by evidence of production use, not by launch noise.

Start with the number everyone quotes. METR measures how long a task an AI agent can complete autonomously, and the trend is genuinely exponential. METR give it "a doubling time of around 7 months" across 2019–2025 — their fitted P50 figure is 195.8 days, so call it six and a half — and on their updated methodology it is every 130.8 days since 2023 and every 88.6 days since 2024 [4]. Under three months per doubling.

Now the part that rarely travels with the chart. In METR's own words, "These confidence intervals are still very wide, and we are actively working on adding more long tasks…" and human baseline times were "measured for only 5 of our 31 long (8h+) tasks. The remainder use estimated times" [4]. The curve is real. The far end of it is being drawn through five timed data points. That is worth knowing before you plan a business on the extrapolation.

So what shipped? Three techniques, all documented as production practice by the lab whose coding agent I am typing this inside [5]. Their framing is worth quoting exactly, because it reframes the resource: "LLMs have an 'attention budget' that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount…" Context is not storage. It is a budget you spend.

Given that, the three adopted moves are all forms of writing things down elsewhere:

• Compaction — "the practice of taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary" [5]. A logbook entry, then a fresh page.
• Structured note-taking — "a technique where the agent regularly writes notes persisted to memory outside of the context window" [5]. The logbook itself.
• Sub-agents — "Rather than one agent attempting to maintain state across an entire project, specialized sub-agents can handle focused tasks with clean context windows" [5]. A watch rotation.

Alongside them, the plumbing got standardised. The Model Context Protocol launched in November 2024 and, on 9 December 2025, Anthropic donated it to the Linux Foundation's Agentic AI Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg [6]. Competing labs handing a shared interface to a neutral foundation inside thirteen months is not a launch; it is a standard. And in the same window, durable-execution infrastructure — the machinery for processes that survive crashes — turned explicitly toward agents: Temporal's 2026 conference shipped serverless workers aimed at exactly these workflows [7].

Here is the pattern, and I want to be blunt about it because it is the article's spine. Not one adopted technique made the model remember more. Every single one moves state out of the model and into something durable, inspectable, and resumable.

The graveyard from the same window

An adoption ranking without the stalled demos is a press release, so: the loudest agent projects of this era are the ones that didn't make it. AutoGPT and BabyAGI went vertical in early 2023, and the contemporaneous hands-on verdict was that a reviewer couldn't find a single practical use case where they do a good job [8]. AgentGPT's development stopped in November 2023; its parent pivoted away in July 2024, leaving the platform in maintenance mode with 130-plus unaddressed issues [9].

And the most instructive corpse is a piece of API design. LangChain's AgentExecutor — the canonical "just loop the model until it's done" abstraction — is deprecated, alongside initialize_agent and the older create_react_agent; the sanctioned replacement is a single create_agent [10]. The stated reason is that the loop could not handle branching, human-in-the-loop, or durable execution, and a graph runtime could.

The loop lost to the graph. A loop is a process with its state inside it. A graph is a process with its state written down where you can pause it, inspect it, and resume it. Rule one, again, decided a framework war.

🕰 Window three: what has survived thirty years

Now rank by survival rather than adoption, and the list gets short and unglamorous. I'll be honest about the tiering: both items below are aging well rather than proven survivors, because I could not find the full obituary-and-revival evidence for either within this research pass.

Supervision trees, and "let it crash." Erlang/OTP's answer to long-running systems was not to write code that doesn't fail. It was to arrange processes in a tree where a supervisor's only job is to notice a child has died and restart it. Still load-bearing: WhatsApp famously ran on the order of two million simultaneous connections per server with fewer than fifty engineers, and Discord runs its real-time infrastructure on the same lineage [11]. And the philosophy is routinely misread, so here is the correction that matters: it does not mean be careless. Erlang/OTP's own design principles put the recovery logic in a separate process from the work — the supervisor exists precisely so that the code doing the job never has to carry the code for surviving its own failure [11]. Normal operation and error recovery are different programs, written by different parts of the tree. (I have seen that idea rendered as a quotation in a dozen blog posts, including in my own first draft of this paragraph. I could not find it in any source that actually says it, so it appears here unquoted.)

Replay from a durable log. Durable execution — Temporal, built by the engineers who created Cadence at Uber — keeps every workflow's history as a durable event log that lives outside the process and is never lost. On restart, the worker replays the workflow code from the beginning, but only executes what hasn't happened yet; activities that already succeeded are skipped [7], [12]. The idea is older than the product — it is the write-ahead log, wearing a new hat — and I'm describing that lineage rather than claiming a citation for it.

Put those two beside each other and the mechanism is visible:

Neither one tries to stop the long run from failing. Both make failure cheap to resume from. Thirty years of reliability engineering did not buy fewer crashes. It bought cheaper restarts.

Which is why "make the model smarter so it doesn't lose the thread" is a strategy with no precedent behind it, and "checkpoint often enough that losing the thread costs ninety seconds" is a strategy with three decades.

🏺 Window four: what has survived three hundred years

At this range, one career of relevance is noise. An item has to have crossed generations and survived a change of substrate that could have killed it. Two did, in the same domain as ours: knowing where you are, on a job too long to remember.

The clock you carry, and the sum you redo

The longitude problem was the long-horizon problem, exactly. Latitude is easy — read the sun. Longitude requires knowing what time it is somewhere else, and for most of history nothing at sea could tell you that. Two solutions competed for the eighteenth century, and they are the two strategies still on the table today.

Carry the state forward: John Harrison's marine timekeepers kept a reference time running, so a position fix was a reading. Re-derive it every time: the lunar distance method measured the angle between the moon and a star and computed back to a reference time — fresh sights, almanac tables, and a long chain of spherical trigonometry, from scratch, per fix.

Before the numbers, a warning I have to pass on, because the source I relied on most exists largely to issue it. Royal Museums Greenwich open their account of this rivalry by saying that "The brilliant John Harrison has long been portrayed as the plucky underdog…" and that this "has however tarnished the reputation of another brilliant man: Nevil Maskelyne" [13]. The plucky-underdog version is the one I grew up on and the one I started drafting. It is not the version the historians tell.

So, carefully. On the second sea trial — the one where both methods were measured against each other — Harrison's H4 came in accurate to within about ten miles and the lunar distance method to within about thirty [13]. The source says "miles" and does not specify statute or nautical, so neither do I. (H4's famous roughly-one-mile result is real but comes from a different voyage, and comparing the two would be splicing two experiments into one contest.) Maskelyne, the Astronomer Royal, published the Nautical Almanac tables that made lunars practical for working mariners, and as a Board member he "continued to resist Harrison's claim for the award" [13] — and he also assessed Harrison's clock and, as Linda Hall Library records it, "wrote a negative report, saying that the chronometer had built-in errors which just happened to cancel each other out" [13]. Not "it's a fluke" in those words. Something more specific and more damning: your instrument is right by accident.

Lunars were genuinely good and genuinely standard for much of the nineteenth century. Chronometers became affordable around 1850, and Britain published lunar tables in the Nautical Almanac from 1767 until 1906 [15].

Now the part I want to be honest about, because the triumphant version of this story is presentism and I had written it. The objection to the chronometer was that it was expensive and hard to make in quantity — and that objection was correct for the better part of a century. RMG say it plainly: marine timekeepers "remained rare and expensive; it took decades to establish their reliability and for seafarers to trust them" [13]. Harrison's trial was 1761; affordability arrived around 1850 — call it ninety years, and note that "around" is the source's word, not a measurement. A cost objection can be right for three generations and still lose in the end. That is a more useful lesson than "the visionary was vindicated," and it is the one I would actually apply to checkpointing overhead in an agent system: the objection may be correct now and still be the wrong thing to design around.

And then the loser came back — as the backup

Here is the twist I nearly filed on the wrong side of my own argument.

The US Naval Academy took celestial navigation out of the curriculum in the late 1990s, replacing that course time with GPS and electronic navigation, and then brought it back in the summer of 2015 because GPS can be jammed. The deputy chairman of the seamanship and navigation department put the reason in one line: computers are great, but "The problem is there's no backup" [14].

But look at what came back. Sextant sights, almanac, sight reduction — that is the re-derivation method. The losing side of the eighteenth-century contest is what a modern navy reinstated as its fallback. Not because re-deriving is cheaper; it plainly isn't. Because re-deriving depends on nothing but the sky, and the carried state depends on a satellite somebody else operates.

Which yields a rule sharper than "carry state instead of re-deriving it":

Carry compact state forward because it is cheap. Keep the ability to re-derive it from scratch because it is the only thing that works when the cheap path is unavailable.

For an agent that is not a metaphor, it is an architecture. Compaction is the chronometer: a small trusted summary you read in one step. The full trace — every tool call and result, on disk — is the sextant: expensive, slow, and the only way to find out where you actually are when the summary turns out to have dropped the thing that mattered. Ship both. Most agent stacks I look at ship only the first, then discover during an incident that the compacted history is all they kept.

And I do not need the eighteenth century to justify that, because a production system already in this article does it. Durable execution keeps the full event log and replays from it: the log is the sextant, the replay is the sight reduction, and the already-succeeded activities it skips are the carried state [7], [12]. Temporal ships both. And the sea did not actually pick one either: the same page that dates the chronometer's victory also notes that "a mariner with a chronometer could check its accuracy using a lunar determination of Greenwich time" [15]. Carry the clock, keep the sextant, use each to audit the other. A navy re-learned the second half in 2015. The only party still picking one is the agent stack.

I should be accurate about what returned, though, because the honest version is funnier and more useful than the triumphant one. What came back was not the old course. It was a three-hour introductory session [14]. Two hundred and sixty-five years after the problem was first solved, the backup was reinstated at roughly the length of a corporate onboarding module about the expense system. Institutions do not learn this lesson so much as they leave a sticky note about it.

The checklist — and two honesty corrections

The second survivor is the one everybody thinks they know. On 30 October 1935 at Wright Field, Boeing's Model 299 — the prototype B-17 — climbed to about 300 feet, stalled, and crashed, killing two of the five crew. The cause was a control lock left engaged: as the contemporary account describes it, an internal lock that immobilised both the elevator and the rudder [16]. (The popular retelling calls it a "gust lock." The accident narrative I could actually source does not use that phrase, and this is a section about correcting popular retellings.)

The accident board's finding is the sentence I would put above any agent dashboard. It concluded that, given the size of the aircraft and the design of its control system, "it was improbable that any pilot, taking off under the same conditions, would discover the locked controls until it was too late to prevent a crash" [16].

An unobservable state. The airplane had no way to tell anyone what it was.

And I have to hold that finding next to the sentence beside it, because the same source adds that "Ordinarily, pilots make checks of their movement as a precaution, but apparently this did not occur" — and adds, in its own voice, that the verdict is "by implication, a 'pilot error' verdict—but the board did not say that directly" [16]. So this is not the clean story where an institution nobly refuses to blame a person. It is the messier and more familiar one: the report contains both the exoneration and the reproach, and what the organisation did with it is the part that mattered.

What it did was this. Faced with arguments that the aircraft was simply too big to handle, the Air Corps "properly recognized that the limiting factor here was human memory, not the aircraft's size or complexity" [16]. Then they wrote checklists for takeoff, flight, before landing and after landing.

Second correction, because the popular version of this is Whig history and I nearly published it: the checklist was not invented in 1935. The word itself dates to 1853 by Merriam-Webster's reckoning, and the same source is explicit that the concept "had already been around for decades, and was in scattered use in aviation worldwide, but it took the Model 299 crash to institutionalize its use" [16]. 1935 did not supply the idea. It supplied the funeral.

Which is worth being uncomfortable about. Every discipline in this article was institutionalised after something was lost. My own version cost me nothing but six weeks of a scout's output — and I only found it because I happened to click a second tab.

The first principle

All four windows collapse into one sentence.

An agent's horizon is not how long it can remember. It is how long it can be interrupted and resumed without lying about where it was.

The chain is short. Context is a depleting attention budget, so durable state has to live outside it. Once state lives outside, the external record — not the model — becomes the system of record. And once the record is the system of record, the only remaining catastrophic failure is a record that reports fine when nothing happened.

Which makes the last mile of long-horizon engineering a strange, unglamorous thing: making silence loud.

Patterns and anti-patterns

What I actually changed, in the ninety minutes after

Concretely, so you can copy it or argue with it. Five rules, now enforced in code rather than remembered:

1. Schedule off the hour. Scheduled jobs get dropped and delayed hardest at :00. Mine now run at :47, :53 and :11.
2. A missing credential fails, it does not skip. exit 0 became an error annotation and exit 1 — in the new job and in the old one that taught me the lesson.
3. Failure opens an issue. A red square in a tab nobody opens is not an alert.
4. The job measures the age of its own last output and says so on every run, with a tolerance per cadence: 2 days for daily, 10 for weekly, 40 for monthly. A job that has silently stopped now says so out loud on the run that resumes.
5. "Could not verify" never exits zero. This is the one-character fix, generalised.

And the review it now runs is built so it can fail: if the underlying goal graph is too empty to review against, the output leads with NOT REVIEWABLE rather than a clean bill of health, because "nothing to report" and "nothing to report it against" are different facts and only one of them is good news.

The part where I finally got to watch it

When I first drafted this section, GitHub was in the middle of a major outage — API, Actions, Issues and Pull Requests, down together — and I wrote that I had not watched a single scheduled run reach green, and that by this article's own rule I therefore did not get to call it done.

Then it cleared, and I dispatched the job. It failed. Four times, for two entirely different reasons, neither of which I had predicted.

The first failure was the better one. The review itself worked perfectly: it called the endpoint, built the report, wrote docs/reviews/2026-08-17-weekly.md, pushed the branch — and then died on the last step with GitHub Actions is not permitted to create or approve pull requests. A repository setting, off by default, that I had never looked at.

Sit with what that means for the cron I spent this whole article dissecting. The scout needed three things it did not have: a secret that was never registered, a step that failed instead of exiting zero, and a repository permission nobody had turned on. Fix any one of them and it still does nothing. I had been proud of finding one bug. The count was three, and I only found the third by making the job fail loudly enough to tell me.

The next three failures were GitHub's own 503s, flapping through a partial outage, on the same final step. Attempt four went green. Run 32054945733, watched to conclusion, which opened PR #303 containing a real review — twelve deliveries in the window, three repos gone cold past fourteen days, a fired tripwire on revenue velocity, and thirteen node weights unsigned and neutralised. It also printed its own cadence check: no prior weekly review — this is the first.

So now I get to say it. And notice what it took: the honest version of this article's ending required four failures and a repository setting more than the confident version I would have shipped if I had merely written the code and trusted the green.

There is one thing I still deliberately have not done. One of the credentials — the one the skill loop needs — exists on the deploy but not in the repository, and I could have made that cron green in thirty seconds by rotating it. I didn't, because the docs show another system calls that endpoint headless with the old value, and rotating a credential an unseen caller holds would have manufactured exactly the silent breakage this whole day was spent removing. So that job now fails loudly and correctly, and stays failing until a human copies one value across. A loud red is a finished piece of work. A quiet green is not.

Which is, I think, the honest state of long-horizon agent engineering in August 2026. The curve is steep and real. The best system on record finishes 15.2% of tasks that take an agent about 85 minutes and 9.9 million tokens — and that paper reports no human baseline at all, so nobody should tell you how long these take a person. And the failure that will actually cost you is not the agent stopping. It's the agent reporting success while stopped — for forty-two days, in a tidy column of green.

Related

• Silence Is Not a Status — the same bug in a different organ. If this article annoyed you, that one will finish the job.
• The App Kept Saying "Done." It Was Lying. So We Made It Audit Itself. — rule two of the logbook, built out: the verifier that is not the actor.
• Assumed but Not Tested — what happens to the claims you never wrote a way to falsify.

References

1. RUC-NLPIR. Awesome-Long-Horizon-Agents: the roadmap of long-horizon agents. Two-pillar taxonomy (harnesses / optimization) and the six harness components; repository restructured for the July 2026 survey release. github.com/RUC-NLPIR/Awesome-Long-Horizon-Agents
2. Li, Z., Li, Z., Shi, Y., et al. (9 July 2026). Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading. arXiv:2607.08964. 46 tasks across nine categories; ≈231 episodes and 85.3 minutes per run; ≈9.9M tokens per task; 15.2% / 10.9% best-model pass@1 at the 0.95 and 1.0 reward thresholds, 4.3% / 1.7% mean. arxiv.org/abs/2607.08964
3. Albayaydh, W., Zhao, R., & Flechais, I. (7 July 2026). Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents. arXiv:2607.05775. 27 papers, 19 benchmarks, six failure categories. The three findings are quoted as one continuous verbatim sentence from the abstract, including the middle clause an earlier draft of this article omitted. arxiv.org/abs/2607.05775
4. METR (29 January 2026). Time Horizon 1.1. P50 doubling ≈195.8 days all-time; 130.8 days since 2023 and 88.6 days since 2024 under TH1.1; both caveat sentences quoted verbatim. metr.org/blog/2026-1-29-time-horizon-1-1/ · earlier methodology: Measuring AI Ability to Complete Long Tasks
5. Anthropic. Effective context engineering for AI agents. Definitions of context vs prompt engineering; the "attention budget" framing; compaction, structured note-taking and sub-agent architectures — all four quotations verified verbatim against the source. anthropic.com/engineering/effective-context-engineering-for-ai-agents
6. Anthropic (9 December 2025). Donating the Model Context Protocol and establishing the Agentic AI Foundation. AAIF under the Linux Foundation; co-founded with Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg. anthropic.com/news/donating-the-model-context-protocol…
7. The New Stack (2026). Temporal reveals a serverless option for its Durable Execution platform. Replay 2026 announcements; durable execution aimed explicitly at AI agent workflows. thenewstack.io/temporal-replay-2026-news/ · vendor post: temporal.io/blog/replay-2026-product-announcements
8. Tom's Hardware. Auto-GPT and BabyAGI Are AI's New Hotness, But They Suck Right Now. (22 April 2023.) Contemporaneous hands-on assessment; described rather than quoted verbatim. It carries no star count — the body's characterisation of AutoGPT's starring is therefore qualitative, with no figure asserted. tomshardware.com/news/autonomous-agents-new-big-thing
9. DataCamp. AgentGPT: A Guide to Browser-Based Autonomous AI Agents. Development halted November 2023; parent pivoted July 2024; maintenance mode with 130+ unaddressed issues. datacamp.com/tutorial/agentgpt
10. BSWEN (17 June 2026). Is AgentExecutor Deprecated in LangChain? The Real State of LangChain Agent APIs in 2026. AgentExecutor, initialize_agent and the older create_react_agent deprecated, with create_agent as the sanctioned replacement and consolidation on a graph runtime — which is all the body claims from it. Two further details circulate in secondary coverage and are not on this page: a December 2026 end-of-life date, and the move of the classic constructors into a langchain-classic package. Neither is asserted. docs.bswen.com/blog/2026-06-16-is-agentexecutor-deprecated-langchain/
11. OneUptime (3 February 2026). How to Use Supervisors in Elixir. Supervision-tree mechanics; the separation of work from recovery is described, not quoted — the sentence "separating the concerns of normal operation from the concerns of error recovery" circulates widely as a quotation and I could not find a source that actually contains it, which is itself reported in the body. oneuptime.com/blog/post/2026-02-03-elixir-supervisors/view · the WhatsApp figure ("2 million simultaneous connections per server with a team of fewer than 50 engineers") and the Discord example are carried by Elixir and OTP for AI Agent Systems
12. Temporal. Workflow Execution overview and Event History walkthrough. Event history as a durable log that is never lost; replay from the beginning while skipping already-succeeded activities; Temporal's lineage from Cadence at Uber. docs.temporal.io/workflow-execution · docs.temporal.io/encyclopedia/event-history/…
13. Royal Museums Greenwich. Longitude found: Nevil Maskelyne and the lunar method. Source of the "plucky underdog" caution quoted verbatim in the body, of Maskelyne's advocacy and the Nautical Almanac tables, and of the line that marine timekeepers "remained rare and expensive; it took decades to establish their reliability and for seafarers to trust them." This page exists largely to correct the Harrison-as-underdog narrative, and the body says so rather than citing it for that narrative. rmg.co.uk/stories/time/longitude-found-nevil-maskelyne-lunar-method · Linda Hall Library, Nevil Maskelyne — source of the second-trial figures used in the body (H4 "accurate to within 10 miles", "the lunar distance-method was accurate to within 30 miles") of Maskelyne's report verbatim ("wrote a negative report, saying that the chronometer had built-in errors which just happened to cancel each other out"), and of his continuing to resist Harrison's claim as an ex-officio Board member: lindahall.org/…/nevil-maskelyne/. H4's roughly-one-mile figure comes from a different voyage and is deliberately not juxtaposed with the 30-mile figure in this article.
14. Slate (October 2015). Naval Academy Brings Back Celestial Navigation Training in Case of a Cyberattack on GPS. Reinstated summer 2015 after more than a decade; course time replaced by GPS/electronic navigation in the late 1990s; LCDR Ryan Rogers quoted verbatim; the reintroduction was a three-hour introductory session. slate.com/technology/2015/10/… · corroborating: Military Times · Sky & Telescope
15. Wikipedia. Lunar distance (navigation). Used for two dates only, both of which the page carries: British Nautical Almanac lunar tables "published between 1767 and 1906", and supersession by the affordable marine chronometer around 1850. An earlier draft of this article also attributed 1907, 1919 and a 1905 radio-time-signal cutoff to this page; none of the three appears in it, so all three were removed rather than re-sourced. en.wikipedia.org/wiki/Lunar_distance_(navigation) · scholarly treatment, not relied on for a claim here: Wepster, A (not so) brief history of lunar distances, arXiv:2007.14504
16. Boyne, W. J. (August 2013). The Checklist. Air Force Magazine. The 30 October 1935 Model 299 crash; the accident board's "improbable that any pilot…" finding; "the limiting factor here was human memory, not the aircraft's size or complexity"; and the correction that the concept predated 1935 and was merely institutionalised by the crash — all three quoted verbatim from the article's text. airandspaceforces.com/…/0813checklist.pdf · crash record: National Air and Space Museum

Research packet assembled 2026-08-17 across four windows — 30 days, 30 months, 30 years, 300 years. Sixteen sources. This draft failed its own review the first time. An independent reviewer with fresh context checked every quotation against the page that carries it and found six load-bearing defects and twelve smaller ones, then failed the corrected draft a second time and found sixteen more, ten of them substantive — which is why the colophon of an article about false green reports should not say "everything verified" — it should say what was wrong. Fixed before publication: one sentence about Erlang supervision was in no cited source and now appears unquoted, with that fact stated in the body; a phrase about the chronometer being "too expensive, too complicated to make at scale" appeared in quotation marks in the artwork, the registry entry and the promo kit — and in the prose as an italicised near-quotation hedged with "verbatim in spirit", which is worse — while existing in none of the sources, and was replaced with what Maskelyne's report actually said; a comparison of "one nautical mile against thirty" spliced two different sea trials and is now the same-trial ten against thirty; three dates (1907, 1919, 1905) were attributed to a page containing none of them and were removed rather than re-sourced; an end-of-life date and a GitHub star count were dropped for the same reason; and the strongest 300-year exhibit — the Naval Academy's 2015 reinstatement — had been filed on the wrong side of this article's own dichotomy, which is what produced the sharper rule the piece now ends on. Quotes that survived verification unchanged: all four from Anthropic, all three from the 1935 accident narrative, both METR caveats, the Naval Academy line, and the whole of the arXiv abstract sentence. Two thirty-year items are tiered aging well rather than survived because the obituary-and-revival evidence was not found in this pass. The 5-of-5 green runs and the 42-day gap are from the author's own public repository, as are the four failed dispatches and the repository permission described at the end — that section was rewritten after the cron was actually run, because the first version of it truthfully said the run had never been watched and it would have stayed on the page as a lie the moment it was. No material from any employer or client. — Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app