A 111-Move Chess Match Taught Us Why Coding Agents Need Ground Truth

Rope Notes and Gemini played a long chess game through screenshots and chat. Gemini occasionally lost the board. Rope Notes did not—not because it "understood chess" better, but because it could call deterministic tools to reconstruct the position, validate legal moves, test candidate lines, and verify checkmate before claiming it.

Most AI-agent demos look impressive for the first few turns.

Ask a model to write a component, summarize a codebase, or propose a refactor, and it can sound remarkably competent. But the harder question is what happens after fifty turns, after the user changes a requirement, after a test fails, after an earlier assumption turns out to be wrong, or after the agent needs to reason about a state it can no longer safely hold in its context window.

This week, we accidentally found a compact answer through a 111-move chess game.

Rope Notes was playing against Gemini through a conversation. What began as a casual test turned into a long tactical game: captures, queen trades, endgame conversion, repetition risks, stalemate traps, promotion, and eventually a forced mate.

Rope Notes won.

But the interesting part was not the result.

The interesting part was that, at several points in the game, Gemini described a board state or tactical continuation that did not match the actual position. Rope Notes caught those errors because it was not relying only on its own running narrative of the game.

It had tools.

The Difference Between Remembering and Verifying

A language model can maintain a surprising amount of context. It can recall moves, explain tactical ideas, and produce plausible analysis for a long time.

But plausible is not the same as correct.

Chess is unforgiving about this distinction. A single missing pawn, an overlooked defender, or a piece remembered on the wrong square can make an entire paragraph of analysis meaningless. A move that sounds forcing may be illegal. A "hanging" rook may be protected. A claimed checkmate may leave one legal escape square.

During the match, Rope Notes repeatedly treated the conversation as a hypothesis rather than ground truth.

Before committing to a move, it could:

  • Reconstruct the board from the complete move list or a FEN position.
  • Ask for the full legal-move set.
  • Check material, whose turn it was, and whether either king was in check.
  • Evaluate candidate moves with a chess engine.
  • Apply the selected move to the canonical position.
  • Verify claims such as check, stalemate, repetition risk, and checkmate after the move actually landed.

That is a much more reliable loop than "the model thinks it remembers where the pieces are."

The Final Sequence

By the end of the game, Black had promoted and reached a queen-and-rook versus bare-king position. Gemini proposed candidate finishing moves, including lines that looked natural in prose but did not produce the cleanest forced result.

Rope Notes checked the actual position.

The engine found the mating sequence:

109... Rd2
110. Ke4 Kf6
111. Kf4 Rd4#

And then, crucially, it did not simply announce that the game was over because the engine evaluation said "mate."

It applied the final move and checked the resulting state:

checkmate: true
legalmovecount: 0

That is the distinction we care about.

The agent did not merely say the position was checkmate. It asked a deterministic system whether White had any legal move left. The answer was no.

Why This Matters for Coding Agents

We are not building Rope Notes to play chess.

We are building it because software engineering has the same state problem, only messier.

A coding agent does not work on a clean, static prompt. It works inside a moving system:

  • Files change while the agent is planning.
  • Unsaved editor buffers may differ from disk.
  • Git state may contain half-finished work.
  • A compiler error may invalidate an earlier assumption.
  • Tests may reveal that an apparently clean refactor broke behavior somewhere else.
  • A user may revise the requirement halfway through an execution plan.

A browser chatbot can describe what the code should be doing. But an engineering agent needs to know what the codebase is doing right now.

That requires ground truth.

In chessIn a real project
Board stateWorkspace and file state
Legal movesAllowed edits and valid tool actions
Engine evaluationCompiler, analyzer, linter, and test output
Checkmate verificationVerified build, test, or task-completion condition
Repetition/stalemate checksGit conflicts, loops, no-op edits, and unsafe terminal states

The model supplies reasoning. The tools supply reality.

The Agent Is Not the Source of Truth

This is the design principle behind Rope Notes.

An agent should not be trusted because it sounds certain. It should be useful because it can interrogate the real workspace:

  • Read the actual files instead of reconstructing them from pasted fragments.
  • Use language-server diagnostics instead of guessing types or symbol references.
  • Inspect Git diffs instead of claiming what changed.
  • Run constrained checks instead of declaring a fix complete from its own prose.
  • Propose edits for human approval instead of silently rewriting a project.

The agent proposes. The environment verifies. The developer stays in control.

That is also why Rope Notes is local-first. Your project tree, editor buffers, diagnostics, permissions, and review workflow are not incidental details around a chatbox. They are the state an engineering agent must respect.

A Better Definition of "Agentic"

The industry often treats agentic behavior as a measure of how long a model can operate without a human touching it.

We think that is the wrong metric.

The useful question is not:

  • How long can the agent keep talking?

It is:

  • Can the agent keep checking whether its beliefs still match reality?

In the chess match, Rope Notes occasionally had to correct its own earlier analysis too. That is not a weakness. It is precisely why deterministic tool calls matter.

A grounded agent should be willing to say: the board says otherwise.

For coding, the equivalent is even more valuable:

  • The test says otherwise.
  • The type checker says otherwise.
  • The Git diff says otherwise.
  • The permission boundary says otherwise.
  • The current file says otherwise.

That is how an AI assistant becomes an engineering tool rather than a confident narrator.

You Own the Rope

The 111-move match was a fun experiment. It was also a small, concrete demonstration of a larger idea.

Long-horizon work is not solved by asking a model to remember more. It is solved by giving the model a structured workspace, deterministic tools, explicit boundaries, and a way to verify every important claim against the current state.

In chess, that means legal moves and a canonical board.

In software, that means your actual project.

Rope Notes is built for that second problem.