
### The Gauntlet Loop: A Quality Bar AI Can’t Talk Its Way Around

Before getting into the technique, here is what I was building. [Dance of Ashes](https://danceofashes.pages.dev/) is a mobile-first, choice-driven dark-fantasy browser game in which players create a character and navigate ten consequential decisions during a civil war fought with dragons. Each choice affects the character’s relationships, abilities, reputation, achievements, and eventual ending. I began the project using [Legionnaire](https://www.legionnaire.xyz/), developed by [Gal Bartov](https://x.com/Krysuss), as a quality reference—not to copy its football setting or design, but to learn from the way it turns a simple series of decisions into a compelling, persistent career.

The first version was not broken. That was the problem.

It loaded. The buttons worked. The colors were tasteful. It was recognizably the thing I had asked for—and it was completely forgettable.

This is a common failure mode in AI-assisted work. A capable model can produce something locally coherent on its first attempt. Because nothing is obviously wrong, both the model and the human are tempted to call it done. The result clears the low bar of “it works” while missing the much harder bar of “I want to keep using this.”

The Gauntlet Loop is a way to keep that first plausible draft from certifying itself.

Before going further, the credits should be explicit because this project owes two different debts:

- **The method:** This article is a continuation of [Matt Shumer’s original post on X](https://x.com/mattshumer_/status/2081830214384886228?lang=en) and his later explanation, [How to Run a Gauntlet Loop](https://somethingbig.ai/gauntlet-loop). The prompt and project that demonstrated the method are also public in the [Claude of Duty repository](https://github.com/mshumer/Claude-of-Duty).
- **The product reference:** the source and quality bar for my game was [Legionnaire](https://www.legionnaire.xyz/), developed by [Gal Bartov (@Krysuss)](https://x.com/Krysuss). Dance of Ashes is an independent adaptation of lessons I observed in his work; it is not the origin of those interaction ideas.

Gal’s development deserves real praise. Legionnaire compresses an enormous career simulation into a remarkably approachable mobile loop. It makes identity, progression, risk, history, and the next decision legible without making the player feel as though they are operating a spreadsheet. That balance is difficult product work. Its restraint is especially impressive: the game understands that persistent consequences and good pacing can create more attachment than spectacle alone.

What follows is my attempt to apply the idea, understand why it works, and make it useful outside one spectacular demo.

### The real problem is not generation. It is stopping.

Most prompting advice focuses on the input: add context, define a role, request a format, include examples. All of that helps. But once an agent can edit files, run code, inspect a browser, and test its own work, the larger opportunity is no longer a single perfect prompt. It is a better process for deciding when the work is good enough.

A normal agent loop looks something like this:

1. Interpret the request.
2. Build a solution.
3. Look at the solution it just built.
4. Explain why the solution is reasonable.
5. Stop.

Step four is the trap. The builder knows every constraint it encountered and every compromise it made. That context makes it an excellent defense attorney for its own work. It can explain why the spacing is acceptable, why the test coverage is sufficient, or why the interaction is “intuitive.”

But users do not experience the explanation. They experience the artifact.

The Gauntlet Loop changes the stopping rule. Instead of asking the builder whether the work is good, it introduces a real quality bar and a separate critical pass that inspects the finished output. If the reference still wins, the loop continues.

In its simplest form:

> Set a concrete bar. Build. Compare the real artifact against the bar. Fix the largest gap. Repeat.

The loop is simple. Choosing the bar is not.

### A reference is not a mood board

“Make it amazing” is not a quality bar. Neither is “production-ready,” “premium,” or “addictive.” These phrases express ambition, but they give the critic nothing falsifiable to inspect.

A useful bar is concrete enough to win or lose against.

For a visual product, that may be a live site at a specific mobile viewport. For prose, it may be a handful of exemplary passages judged on clarity and compression. For infrastructure, it may be a recovery test, a latency distribution, or a known implementation. Shumer’s write-up makes the same point: the reference does not need to be realistically beatable; it needs to keep the work moving in the right direction instead of allowing “pretty good for AI” to become the finish line.

I used Gal Bartov’s [Legionnaire](https://www.legionnaire.xyz/) as the bar for a mobile browser game. The goal was not to copy its football theme, artwork, content, or interface. It was to study the excellent product decisions underneath them and understand why a session felt like a career rather than a sequence of forms.

That distinction matters. A weak comparison says:

> The reference has large background images, so add large background images.

A stronger comparison asks:

> What does the reference make the player understand, feel, and anticipate—and what mechanisms create that effect?

The live comparison surfaced things that a screenshot alone would have missed. The reference made identity persistent. It showed accumulation clearly. It kept a season-by-season record. Every decision immediately changed a visible career. A collection created unfinished business. The next choice arrived before the energy of the previous one disappeared.

My game, [Dance of Ashes](https://danceofashes.pages.dev/), already had more atmosphere: generated character art, dragons, cinematic endings, music, sound, and animated fire. More spectacle was not the largest remaining gap. The gap was legible continuity.

That led to a different set of changes: a daily shared prophecy, completion streaks, a visible legacy score, persistent decision ledgers, and a Vault that turns old lives into a collection. The reference supplied the standard, not the skin.

## The anatomy of a useful gauntlet

A strong Gauntlet Loop has five parts.

### 1. A destination

Describe the outcome at full ambition. Do not prematurely prescribe the architecture.

“Build a mobile-first browser game people want to replay” leaves room for the agent to discover the right systems. “Add three modals, a WebGL dragon, a PostgreSQL database, and a daily login bonus” may lock the work into an implementation before anyone has proven those are the right ingredients.

Constraints still belong in the prompt. The distinction is between constraints and guesses. “Must work on a phone and deploy as a static site” is a constraint. “Must use React” may just be a guess.

### 2. An inspectable reference

Name the real artifact, test, measurement, or example that represents the bar. The agent must be able to access it and compare against it directly.

If the reference is a website, inspect the live interaction—not only the landing-page screenshot. If the goal involves motion, pacing, audio, or responsiveness, the evidence must include those dimensions. A still image cannot tell you that the pause between two questions feels dead.

### 3. Separation between builder and critic

The full version of the method uses fresh-context critics: the critic receives the goal, rules, reference, and actual artifact, but not the builder’s diary of effort.

That context separation is not ceremony. It removes the story of how hard the work was. The critic sees what a user sees.

When a separate agent is unavailable, the principle still helps: split building and evaluation into distinct phases, discard the builder’s self-description, and restart the critique from observable evidence. It is weaker than a genuinely independent critic, so say so honestly, but it is still better than asking “how did I do?” in the same breath as the implementation.

### 4. One largest gap per round

A critic that returns 47 observations often creates less progress than one that identifies the most important failure.

The next round should have a sharp target:

- first minute does not establish identity;
- choice feedback takes too long;
- the player cannot explain why the run ended;
- mobile controls obscure the scene;
- the test passes on average latency while p99 is unacceptable.

Fix the largest gap, render or run again, then re-evaluate. This makes each round directional and keeps the agent from polishing low-impact details while the central experience remains weak.

### 5. Evidence and a stopping condition

“The critic loved it” is not evidence.

Useful evidence can be screenshots at fixed viewports, interaction traces, real-device recordings, accessibility checks, test output, performance distributions, or structured blind comparisons. The artifact determines the evidence.

In my case, the visual pass was paired with a simulation of 7,200 careers. That test verified that all 36 events were reachable, no phase was skipped, all four ambition paths could reach their rare endings, and the resulting runs did not collapse into a handful of identical sequences. It did not prove that the game was fun. It did eliminate several ways the game could quietly be broken while looking polished.

The stop condition should also be honest. Stop when the artifact clears the bar, when marginal improvements are no longer worth their cost, or when the compute budget is exhausted. Do not quietly redefine the reference downward.

The public Claude of Duty repository is unusually valuable here because its own assessment says the project did **not** beat Call of Duty in blind comparisons. The bar still produced a far stronger artifact. A gauntlet is a direction and a discipline, not a magical guarantee of victory.

### What usually breaks the loop

The first failure is a vague bar. If the critic must invent what “great” means, it can invent a reason to pass the work.

The second is self-grading. The builder’s context leaks into the judgment, and effort gets mistaken for quality.

The third is evaluating a summary instead of the artifact. “Implemented responsive design and polished animations” tells us nothing about whether the mobile layout clips or the animations feel sluggish.

The fourth is using the wrong evidence surface. Screenshots are good for hierarchy, density, alignment, and visual character. They are poor evidence for latency, sound, pacing, game feel, focus behavior, and failure recovery.

The fifth is arbitrary iteration. “Do five rounds” may stop while the work is still improving—or waste three rounds after progress has stalled. The exit should depend on evidence, not a ritual number.

The sixth is uncontrolled parallelism. Some components can be improved independently; others share state, timing, style, and performance constraints. If ten builders simultaneously optimize tightly coupled parts, integration debt can erase their local gains. Parallelize along real boundaries, then run a whole-artifact smoothing pass.

## A practical prompt shape

The most useful prompt is usually shorter than the operating process behind it. Here is a domain-neutral version:

```text
Build [OUTCOME] at the level of [CONCRETE REFERENCE]. Preserve these
constraints: [CONSTRAINTS]. Decide the implementation yourself.

Break the result into the smallest parts that can be improved and judged
independently. For each important part, use a builder and a separate critic
with fresh context. The critic must inspect the real artifact—not the builder’s
summary—and compare it directly with the reference using [EVIDENCE].

When ours loses, identify the single largest meaningful gap, fix it, and run
the comparison again. Maintain an integration pass across the whole artifact.
Stop only when ours clears the agreed bar, improvements stall under the stated
rule, or the budget is reached. Report any remaining gap honestly.
```

The bracket people pay the least attention to is `[EVIDENCE]`, and it may be the most important one.

For a landing page, it might say: “screenshots at 390×844 and 1440×900, plus keyboard navigation and a performance trace.” For an API: “contract tests, fault injection, p50/p95/p99 latency, and recovery after process termination.” For an article: “a blind edit against these five reference passages, scored for clarity, argument density, and unsupported claims.”

Once the evidence is explicit, criticism becomes actionable.

### What changes for the human

The Gauntlet Loop does not remove human judgment. It moves it upstream.

Instead of manually specifying every feature, the human chooses the ambition, reference, constraints, evidence, and budget. Those decisions shape everything the agent does afterward.

This may be the more durable skill in an age of capable agents: not describing every step, but constructing an environment in which weak work cannot easily approve itself.

There is also a psychological advantage. A high reference gives you permission to reject the first competent result. You are no longer being “too picky.” The work simply has not cleared the bar yet.

## The loop in one sentence

The Gauntlet Loop turns quality from an adjective into a comparison.

That is why it works. The agent is no longer asked to feel more ambitious, praise itself less, or somehow know when a product is addictive. It is given a destination, a rival, an independent judgment, and another round.

The first draft can still be forgettable. It just no longer gets the final vote.

---

_With appreciation to [Matt Shumer](https://x.com/mattshumer_) for developing and sharing the Gauntlet Loop method, and to [Gal Bartov](https://x.com/Krysuss) for building [Legionnaire](https://www.legionnaire.xyz/)—the source product whose thoughtful game design gave this experiment a meaningful bar to pursue.\_

And if you want to see the result of this experiment, you can play [Dance of Ashes](https://danceofashes.pages.dev/). It is a work in progress, but it is playable and demonstrates the ideas discussed here.

![Dance of Ashes](https://res.cloudinary.com/dtt2usukl/image/upload/v1787771881/Screenshot_20260826_221739_avvxol.png)


Why better AI work comes from concrete references, independent criticism, and evidence-driven iteration—not a more enthusiastic version of ‘make it better.

Experimenting With A Gauntlet Loop


Before I get into the details, I must say in advance - This solution was created a long time ago - These days we have many other options available, while they are deffinitley better and easier to use or implement, but since I did this while there were no other good options available, I decided to still write a blog post about it.

For a long time, coding agents have been tied to the machine they're running on. If you wanted Claude Code to review code, create files, or work on a project, you had to sit in front of your dev station. Sometimes, I found it a bit frastrating when I came up with ideas I wanted to implement but it wasn't a good time to do that, thats why I decided to do this.

The goal was simple:

Send a command from my phone and have Claude Code execute it on my development machine from anywhere in the world.

What emerged was a mini architecture built from a handful of lightweight components that many of us have or can get easily:

- A smartphone
- Termux (or any other terminal emulator)
- Tailscale
- A Raspberry Pi
- Coding agent (e.g. Claude Code)
- SSH

The result feels like carrying a personal software engineer in your pocket.

### The Architecture

At a high level, the system looks like this:

Phone
↓
Termux
↓
Tailscale
↓
Raspberry Pi Gateway
↓
SSH
↓
Development Workstation
↓
Claude Code

Instead of exposing a workstation directly to the internet, the Raspberry Pi acts as a gateway layer.
The phone never talks directly to the development machine. Everything flows through a secure private network and a controlled entry point.

Why Not Just SSH Into The Laptop?

Because the goal wasn't remote shell access.
The goal was intent-based development.

Instead of ssh laptop > cd project > open editor > run commands,

I wanted, cc <project-name> "prompt"

The phone becomes a command console for AI-driven development rather than a remote desktop replacement.

### The Power Of A Gateway

The Raspberry Pi ended up serving an important purpose.
Technically, the phone could have talked directly to the workstation.
However, introducing a gateway provides several benefits:

The workstation is never directly exposed, and all requests arrive through a dedicated machine whose sole purpose is routing and validation.

Also, the gateway can eventually queue requests, rate limit usage, log activity, add authentication layers, and route requests to different machines.

Today it forwards commands. Tomorrow it could become a complete AI orchestration layer.

### The Role of Tailscale

One of the biggest challenges in personal infrastructure is networking. Static IPs, port forwarding, dynamic DNS, firewall rules—these are all problems developers have historically had to solve. Tailscale largely eliminates that complexity.

Every device becomes part of a private mesh network. The phone can securely reach the Raspberry Pi regardless of Home Wi-Fi, mobile network, public Wi-Fi, or travel.
Also, no ports need to be opened to the public internet.

The entire setup feels local, even when it's distributed globally.

### Why Termux?

Most mobile development workflows rely on custom apps, web dashboards, or messaging bots (I do have multiple dedicated agents for specific tasks triggered via Telegram, but this one felt different for me).
Termux provides something more powerful: A real terminal.

This means the interaction model remains familiar, no UI needs to be built, no mobile application needs to be maintained, and the phone becomes a portable command-line client.

For developers, this is often the most productive interface possible.

### Claude Code As Infrastructure (Can be any other coding agent of course)

One interesting realization from this project is that Claude Code stops feeling like a coding agent and starts feeling like infrastructure.
Instead of opening Claude and asking it to help with a task, the system treats Claude as a service endpoint.

A request arrives.
A project is selected.
Claude receives context.
Work is performed.
Results are returned.

This shifts AI from an interactive tool to an operational component.

### Things I improved on the way

- Dedicated Worker User: Instead of running under a primary workstation account, Claude could operate under a restricted user with access only to project directories.
- Containerized Execution: Each request could execute inside a disposable container, providing stronger isolation and reproducibility.
- Job Queue: Long-running tasks could be queued and tracked asynchronously.
- Notifications: Results could automatically return through push notifications, Telegram, Discord, Slack, and multi-agent routing.
- Different requests could be routed to different agents: Code reviewer, Test engineer, Documentation writer, Architecture advisor, etc.

### The Bigger Picture

The most interesting part of this project isn't the technology itself.
It's what it represents.
We're moving toward a world where software development isn't tied to a specific device.

The workstation/cloud remains where the compute lives.
The developer becomes location-independent.

Your phone becomes a secure command center capable of initiating meaningful engineering work from anywhere.
A Raspberry Pi, a private network, and an AI coding agent are enough to create something that would have felt like science fiction only a few years ago.

And the best part?
The entire system runs on hardware that most developers already have sitting around at home.

![Sequence-diagram](https://res.cloudinary.com/dtt2usukl/image/upload/v1787765418/7ad1f280-ff80-4dd0-a811-e342e4a52f52_fu5bdf.png)_Sequence diagram of the first iteration_


Have you ever had an idea but not the time or resources to implement it? That is why I built a Remote AI Development Gateway

Running Claude Code From Anywhere


## The Next Step Beyond Chatbots

Most people interact with AI through chat interfaces. They ask a question, receive an answer, and move on.

While this interaction model is powerful, it still requires humans to initiate every task. The AI remains passive, waiting for instructions.

A more interesting direction is emerging: autonomous personal agents.

Instead of answering questions, these systems continuously perform useful work on behalf of a user. They monitor information sources, collect relevant data, make decisions, filter noise, and proactively deliver results.

The difference is subtle but important.

A chatbot responds.

An agent acts.

---

## The Real Problem: Information Consumption Does Not Scale

Software engineers, technology leaders, and technical enthusiasts consume information from dozens of sources:

- RSS feeds
- GitHub repositories
- Hacker News
- Reddit communities
- Technical blogs
- Product announcements
- AI research updates
- Social media discussions

The volume of content has become impossible to process manually.

Ironically, the problem is no longer finding information.

The problem is deciding what deserves attention.

Every day thousands of articles are published, hundreds of repositories trend, and dozens of new tools appear. Most are irrelevant. A few are valuable.

Finding those few valuable items is increasingly difficult.

---

## Personal Agents as Information Filters

A personal agent changes the flow of information.

Instead of:

```text
Sources → Human → Knowledge
```

the system becomes:

```text
Sources → Agent → Human → Knowledge
```

The agent acts as a filtering layer.

Its responsibilities include:

- discovering content
- removing duplicates
- scoring relevance
- ranking results
- summarizing findings
- delivering actionable insights

The goal is not replacing human judgment.

The goal is preserving human attention.

---

## NanoClaw as an Agent Runtime

One of the interesting frameworks for building lightweight personal agents is NanoClaw.

Rather than focusing on large enterprise workflows, NanoClaw enables the creation of small autonomous systems that can run continuously on inexpensive hardware.

The architecture is intentionally simple:

```text
Scheduler
    ↓
Data Collection
    ↓
Filtering
    ↓
LLM Evaluation
    ↓
Delivery Channel
```

Each stage performs a specific responsibility.

This separation makes the system easier to extend and maintain.

---

## A Practical Example

In our implementation, the agent runs continuously on a Raspberry Pi.

Its purpose is straightforward:

Collect articles from multiple technical sources and deliver only the most valuable content through Telegram.

While this sounds simple, the interesting work happens between collection and delivery.

The pipeline performs several stages:

### Collection

The system aggregates content from multiple feeds and communities.

Instead of relying on a single source, it gathers a large candidate set of articles.

```text
142 articles fetched
```

A large pool increases the probability of finding high-quality content.

---

### Quality Filtering

Most content is immediately discarded.

Common filtering criteria include:

- low information density
- clickbait titles
- duplicate content
- promotional material
- irrelevant topics

The majority of collected articles never reach the next stage.

---

### Relevance Ranking

The remaining candidates are evaluated using an LLM.

Rather than simply ranking popularity, the model attempts to answer:

> Would this be interesting to this specific user?

This distinction is important.

Popularity is global.

Relevance is personal.

The most valuable article is often not the most popular one.

---

### Delivery

The final result is delivered through a channel that already fits into existing workflows.

In our case:

```text
Telegram
```

No new application.

No dashboard.

No web portal.

The information arrives where attention already exists.

---

## Why Small Hardware Is Enough

One surprising aspect of modern agent systems is how little infrastructure they require.

The Raspberry Pi hosting this workflow performs:

- scheduling
- feed aggregation
- ranking orchestration
- storage
- messaging

The computationally intensive reasoning is delegated to cloud LLMs.

As a result, the local machine acts primarily as an orchestrator.

This architecture provides several benefits:

- low cost
- low power consumption
- continuous operation
- minimal maintenance

The agent remains available 24/7 without requiring dedicated servers.

---

## The Importance of Memory

An agent becomes significantly more useful when it remembers.

Without memory:

```text
Every day starts from zero.
```

With memory:

```text
The system learns history.
```

Examples include:

- avoiding articles already sent
- tracking previously discovered tools
- remembering user preferences
- detecting recurring topics
- identifying emerging trends

Memory transforms automation into personalization.

---

## Beyond Article Delivery

Content discovery is only one use case.

The same architecture can be extended to:

### Trend Detection

Monitoring GitHub repositories and identifying rapidly growing projects.

### Technical Research

Tracking specific technologies across multiple sources.

### Open Source Discovery

Finding promising new tools before they become mainstream.

### Personal Knowledge Management

Building curated collections of information over time.

### Automated Reporting

Generating daily or weekly technical briefings.

The agent becomes a continuously operating research assistant.

---

## The Shift Toward Ambient Intelligence

The long-term significance of personal agents is not that they automate tasks.

Software has automated tasks for decades.

The difference is that modern agents can evaluate information and make lightweight decisions.

They operate in the background.

They monitor.

They filter.

They prioritize.

They surface what matters.

This creates a new interaction model where users spend less time searching and more time consuming relevant information.

The technology fades into the background while useful outcomes become more visible.

---

## Conclusion

The future of personal AI is unlikely to be a single chat window.

Instead, it may consist of many small autonomous systems quietly working on our behalf.

A lightweight NanoClaw deployment running on a Raspberry Pi illustrates this direction well.

The system is not attempting to replace human expertise.

Its purpose is much simpler:

Reduce noise.

Preserve attention.

Deliver the right information at the right time.

As AI capabilities continue to improve, personal agents may become one of the most practical and impactful applications of large language models—not because they answer questions better, but because they know which questions we never needed to ask.

For further implementation details, reach me out on [Linkedin](https://www.linkedin.com/in/or-kazaz/).

![rasberry-pi](https://res.cloudinary.com/dtt2usukl/image/upload/v1783102141/af25b4ee-a33b-423c-b958-2f13d8fb4abe_vhu8am.jpg)_My RP Setup_


How a NanoClaw-powered personal AI agent cuts through information overload with autonomous research and smart automation.

Autonomous Knowledge Assistant with NanoClaw


I first got to know NotebookLM from a YouTuber I follow, who recommended this amazing tool for analyzing financial reports of public companies. As an investor in the stock market, I was intrigued, but as a software developer, I got even more excited. I immediately started thinking about how I could apply and leverage this to my own work. Could it help me manage documentation, understand complex PRDs or requirements, design a TLD, HLD or even brainstorm new features? The answer is yes.

So basically, for those who are not familiar with NotebookLM, it is a personal research assistant that can go through vast amounts of documentation (docs, links, videos, etc.), generate summaries, and even help you brainstorm. It’s an incredibly powerful tool for software developers looking to boost their effectiveness.

#### Things you can do with NotebookLM:

**Learn a New Codebase:**
When you join a new large project, the first few weeks could be blur of documentation and code. Instead of spending days manually reading through hundreds of files, you can upload key modules, architecture diagrams, and design documents to NotebookLM.

Then, you can ask NotebookLM to "Summarize the core functionality of the OrderProcessing module." (which is of course an example module).
You can also solve questions with it by simply prompting "Explain why the UserAuthentication service interacts with the Database layer in this specific way."

**Streamlining Project Planning and Requirements:**
Project specifications, user stories, and technical requirements can be a mess sometimes. I'm sure most of you are familiar with how much its easy to give up on tools like Confluence for example, which can become a hell of outdated documents and projects. Therefore, you can upload all related documents for a new feature; PRDs, the technical design doc, and the user stories.

Then you can consolidating information. I ask it to "List all the user-facing requirements for the new dashboard" or "What are the key dependencies for implementing Feature X?"

You can also leverage it for test cases ideas based on user stories.

![NotebookLM Mind Map](https://res.cloudinary.com/dtt2usukl/image/upload/v1756379322/NotebookLM-Mind-Map-Apollo_y7mqps.webp)_NotebookLM Mind Map_

**Learning Assistant:**
Learning new languages, frameworks, and tools is a constant part of a developer's life. I've started using NotebookLM as my personalized study guide. I upload tutorials, documentation, and best-practice guides from the web and usually generate it as a "podcast" which I find much more efficient to learn something new.

You can ask it to explain concepts, comparison of different technologies or frameworks, and some other specific questions.

By grounding its responses in my chosen learning materials, NotebookLM becomes a highly effective tutor tailored specifically to my needs.

![NotebookLM](https://res.cloudinary.com/dtt2usukl/image/upload/v1756379148/Screenshot_2025-08-28_at_14.04.51_iyzlov.png)_Summarizing an article to a short podcast_

---

I encourage you to give it a try and let me know what you think!


Summarize articles, reports, create mind maps, brainstorm features & generate test cases ideas based on your data using NotebookLM.

AI Articles

All AI Articles

Experimenting With A Gauntlet Loop

Running Claude Code From Anywhere

Autonomous Knowledge Assistant with NanoClaw

Get Smarter With NotebookLM