A small team of hobbyists spent three months and roughly 500 billion tokens decompiling an old first-person shooter into readable C++. They ran Claude Max and Codex Pro side by side, swapped between Sonnet 5, Opus 5.5 and a handful of other models, and found the model choice barely mattered. What moved the needle was the plumbing: one GitHub issue per source file, a shared Discord channel where agents talked to each other and to humans, and a CI webhook that told them when they broke something.

That is the part worth your attention. If you are putting agents on real operational work, quality reviews, supplier documentation, deviation handling, your results will be decided by the same unglamorous infrastructure decisions. Here is what they got right, what they had to fix, and how it maps to your floor.

Your AI Pilot Dies at Week Two. This One Ran for Three Months.

Most corporate agent pilots are demos. Someone wires an agent to a document store, it answers twelve questions well, everyone claps, and the thing never touches work that lasts longer than an afternoon. Real operational work does not fit in a single chat session. It spans weeks, thousands of artifacts, and constant failure states that nobody wrote a prompt for.

The decompilation project is one of the few public records of agents producing useful output across twelve weeks. The team set a clear bar from the start: not “a simple proof-of-concept state,” but an accurate, stable, feature-complete recreation. Three worker agents decompiling and committing, one reviewer agent flagging bugs.

What limited them was never model intelligence. It was context hygiene, review discipline, and plumbing. Agentic AI is an operations problem wearing a prompting costume.

What Actually Ran: Four Agents, Two Subscriptions, One Codebase

The bar was high from the start. Not a demo, but an accurate, stable, feature-complete recreation in readable C++ that actually compiles. Portability and modernization were on the wishlist, running the game on Linux, macOS, in the browser, until the team deferred all of it to focus on reconstructing original behavior first.

Two paid subscriptions ran in parallel: Claude Max (20x) and Codex Pro. Claude agents lived in Claude Code CLI, Codex agents in Codex CLI. Models rotated constantly, mostly Sonnet 5, with Opus 5.5, Luna, Sol and Terra rotating in. For disassembly, they used the official ida-mcp from Hex-Rays: headless, stable, and it carried the whole project.

The three-worker, one-reviewer split and why the reviewer was not optional

Month one ran four agents. Three decompiled and committed. One sat in a reviewer role, passively coordinating and reviewing commits to flag bugs. That ratio is the first thing to copy.

By the end of the first month, roughly 80% of the game was decompiled. It launched, the main menu rendered, maps loaded. Three workers produced that volume; the reviewer is why the volume was worth anything. Drop the agent review loop and you get a lot of plausible output nobody checked.

Why the harness mattered less than the plumbing around it

The team tried other agent harnesses. Their verdict: the choice “barely mattered,” so they stayed on defaults.

Sit with that. Three months of multi-agent workflow at serious scale, and the tool everyone argues about turned out to be interchangeable. What was not interchangeable was issue tracking, shared communication, and automated failure signals. Pick a decent harness in an afternoon, then spend your real effort on everything around it.

The Coordination Layer: GitHub Issues, Discord, and a CI Webhook

Three components did the real work here, and none of them involve a model. A queue agents can read and claim. A bus they all talk on. A signal that tells them when they broke something. Strip the game out of this project and that architecture transfers to any recurring operational process.

One ticket per unit of work: making progress machine-readable

Progress tracking ran through the GitHub CLI. One issue per translation unit, one .cpp file per issue, with labels to group and prioritise. Agents opened, updated and closed their own tickets.

No human dispatcher stood in the middle assigning tasks. That is the whole point. If your unit of work is a deviation report, a supplier audit or an incoming inspection batch, define it once as a discrete record with a status field and an owner, then let agents query it. Vague scope is what kills long-running agent work, not weak reasoning.

Why a shared channel beats point-to-point agent handoffs

Every agent had access to one Discord channel and could post and read everything in it. Not a message bus between specific pairs. One room, full visibility. Humans could join the same channel and talk to any agent without needing machine access, which quietly solves the oversight problem most pilots never address.

Then the feedback loop: a GitHub webhook posted CI failures straight into that channel. Agents found out they had broken the build without anyone telling them. Point-to-point handoffs hide failures inside private conversations. A shared log means the agent that caused a problem, the reviewer, and the person watching all see the same event at the same time.

Context Economics: Why They Compacted at 42% Instead of 90%

Most agent harnesses compact context when the window hits 90% full. The team dropped that threshold to 42%. That is not a tuning tweak, it is a different theory of what context is for.

Their reasoning was blunt. Decompilation produces mountains of volatile information. A function that has been decompiled and committed is dead weight the moment it lands in the repo, but it keeps occupying paid space in the window. Compacting early strips the junk out and leaves the agent reasoning over a cleaner working set.

The payoff was double. Lower token consumption and better output, from the same models. At 500 billion tokens, a 2x efficiency gain decides whether the project continues or quietly stops.

Volatile vs. durable context: what belongs in the window and what belongs in a file

Sort every piece of information your agent touches into two buckets. Volatile means it is only useful while the current task is open: the raw record being processed, the intermediate reasoning, the draft output. Durable means the agent will need it again next week: the standard, the decision rule, the schema, the list of exceptions.

Volatile belongs in the window and should be thrown out aggressively. Durable belongs in a file, a ticket, or a database the agent reads on demand. The failure mode in most business deployments is treating the context window as memory, letting a session accumulate three weeks of half-relevant deviation reports until accuracy quietly degrades.

Write it down, then clear it out. An agent that re-reads a 200-word spec file at the start of each task beats one carrying 80,000 tokens of its own history.

Where Long-Running Agents Win, and Where They Needed a Human

Agents were good at volume. Hundreds of translation units, each one a repetitive grind of reading disassembly, writing C++, and trying again when it didn’t build. No fatigue, no boredom, no drop in care on unit 300 versus unit 3.

They were also good because the work had a judge. Every attempt either compiled or it didn’t. CI either passed or it didn’t. That binary verdict is what let agents iterate for weeks without a person checking each output.

Tasks with an automatic pass/fail signal are the ones to automate first

Before you deploy anything, ask what plays the role of the compiler. If the answer is “a senior person reads it and decides,” you do not have an automatable task yet. You have a task that needs a verification layer built first.

In quality and operations, the compiler-equivalents already exist: spec limits, inspection results, test rigs, SPC rules, document checklists with defined criteria. Point agents at work where those signals close the loop automatically. Deviation triage, CAPA drafting against a template, supplier document validation, non-conformance classification. Each one has a pass/fail test that does not require a human to run it.

Scope discipline remains a human job

The team wanted portability. Linux, macOS, the browser. They dropped all of it and reconstructed original behaviour instead. No agent proposed that cut, and no agent would have.

Agents also depend on tooling you choose for them. This project leaned on the official ida-mcp from Hex-Rays, described as stable, headless, and supporting everything the project needed. Pick the specialised tool, fix the scope, then let agents run. Ambiguity is where they stall, and ambiguity is yours to remove.

Porting This Architecture to Quality and Operations Work

Four pieces transfer directly: a work queue, a shared bus, an automatic failure signal, and context hygiene. Deviation write-ups, supplier documentation review, CAPA drafting, spec reconciliation and audit prep all decompose into units the same way a codebase decomposes into .cpp files. One deviation, one ticket. One supplier dossier, one ticket. One spec pair to reconcile, one ticket.

The failure signal is the hard part in operations, because most quality work has no compiler. You have to build the judge: a checklist validator, a schema check against your QMS template, a required-fields pass before anything reaches a human. No judge, no autonomy.

A 90-day pilot structure that mirrors the four-agent model

Pick one process that is decomposable and verifiable. Spend the first month building the queue and the validator with zero agents running. That sounds slow. The decompilation team spent most of their first four weeks optimising setup rather than output, and that is why the project survived to month three.

Month two, add two or three worker agents and one reviewer agent that reads commits and flags problems. Run the reviewer from day one, not after something goes wrong. Month three, you tune: compaction thresholds, prompt scope, which steps still need a person.

What to measure: cost per completed unit, not tokens burned

Tokens are an input, not a result. Track cost per approved deviation report, cost per supplier file cleared, and the rework rate when a human reviews the output. Those three numbers tell you whether the thing works.

Teams that get value from autonomous AI agents next year will be the ones who built this plumbing, not the ones waiting on the next model release.

Source: momo5502.com