The interesting future of prompting may not be better prompts at all. It may be temporary organisations of agents, critics, tests, memories and competing ideas, built around a problem and dismantled when the work is done.
There is a slightly odd thing happening with prompting at the moment and uts woeth following it down the rabbit hole.
We have spent years trying to find better ways of telling a language model what to do. Add context. (Medium article [https://medium.com/@mgr.tabarc/i-wrote-these-prompts-slightly-drunk-theyve-become-the-most-useful-ones-i-have-42ec53155bdf]) Add examples. Ask it to reason. Give it a role. Tell it not to be lazy. Tell it to check its own work. Tell it that its grandmother will be disappointed if the CSS still looks like Bootstrap circa 2016.
Then the Gauntlet Loop concept has appeared and is potentially quietly shifted the interesting bit somewhere else.
The clever part isn't really the wording of the prompt.
It is the structure behind it.
Instead of asking one model to make something brilliant, the model is asked to break a job apart, hand the pieces to specialist sub-agents, have independent critics inspect their work, reject weak results and continue until the result reaches some external quality bar.
Very roughly:
BUILD ↓ CRITICISE ↓ IMPROVE ↺
That is already a useful change.
It removes the human from the tedious position of repeatedly saying, "No, still not quite right." or "wtf."
More importantly, it separates making from judging.
A model that has just spent several thousand tokens constructing something has every incentive (nor the company running it), in the peculiar statistical sense available to a language model, to explain why the thing it has constructed is actually rather good.
Give the result to a fresh evaluator and the answer can be rather less charitable.
Good.
But I think the Gauntlet Loop is more interesting as a starting point than as a finished technique.
Because once you accept its basic premise, there is no particular reason to stop at:
«Builder → critic → builder.»
You can keep going.
And fairly quickly, what began as a prompting trick starts looking like a small operating system for artificial work.
The first problem: you can optimise the wrong thing beautifully
The most obvious weakness in any recursive improvement loop is simple.
It may work.
A website can become increasingly polished while drifting further away from the client's brand.
A board game can become beautifully balanced while becoming progressively less enjoyable. After all you are not drafting Chess.
A piece of software can become architecturally exquisite and almost impossible for the person who actually owns it to maintain.
A long article can acquire immaculate citations, lovely transitions and absolutely nothing resembling the argument you started with.
Recursive optimisation does not automatically protect intent.
In fact, it can make drift worse because every iteration creates more evidence that the current direction is intentional.
So the first thing I would want to put at the centre of a serious Gauntlet system is something that cannot casually mutate.
INTENT KERNEL
Primary outcome: What the user is actually trying to achieve.
Non-negotiables: Things that must remain true.
Anti-goals: Things the system must not optimise towards.
Audience: Who will ultimately experiences the result.
Success: Observable state constituting useful completion.
Authority: What the system may change autonomously.
Human boundary: What requires explicit approval.
The workers can change.
The architecture can change.
The critic can be replaced.
The task can be decomposed differently.
Tests can improve. Failed approaches can be thrown away. Entire implementation strategies can die noisily in a corner.
But the system does not silently rewrite the reason it exists.
That' is the constitution.
Everything else is just administration.
From quality bar to Acceptance Contract
The original Gauntlet idea gets a surprising amount of leverage from setting an absurdly high external bar.
"Make this like a current AAA game."
"Make the room indistinguishable from the reference."
"Do not pass it until the critic is wowed."
As specifically motivational language for an agent, this is useful.
As engineering, it is wonderfully vague.
A serious version needs two things.
First, the North Star:
NORTH STAR
This should feel as coherent and polished as a high-quality commercial tabletop game.
Then the Acceptance Contract:
HARD REQUIREMENTS
✓ Complete playable rules ✓ 2–6 players ✓ 60–120 minute target ✓ No unresolved game states ✓ Every referenced component exists
QUALITY DIMENSIONS
• strategic agency • rules clarity • interaction • pacing • replayability • thematic coherence • cognitive load
REGRESSION RULE
Improving one dimension must not silently destroy another.
EVIDENCE
Every PASS must point to an artefact, test, observation or comparison.
INVALID PASS CONDITION
"It seems good enough."
The North Star asks:
«Where are we trying to go?»
The Acceptance Contract asks:
«What would convince us that we have actually arrived?»
That sounds pedantic until an agent spends forty minutes polishing button shadows while the checkout form is broken.
Then suddenly contracts seem fashionable again.
Stop organising everything around agents
There is another conceptual problem with most multi-agent systems.
We keep treating the agent as the fundamental unit.
Worker agent.
Research agent.
Critic agent.
Manager agent.
Judge agent.
It makes diagrams easy, but I think the more useful fundamental unit is the claim.
Imagine a coding agent saying:
«Navigation works correctly on mobile.»
Under an ordinary workflow, that statement may appear in a completion report.
Under a Gauntlet system it becomes an object:
CLAIM-027
Claim: Navigation works correctly on mobile devices.
Evidence required:
- viewport test at 320px
- viewport test at 375px
- viewport test at 768px
- keyboard navigation
- touch interaction
- screenshot comparison
Dependencies: CLAIM-011 CLAIM-019
Confidence: 0.78
Status: UNPROVEN
Now we have something useful.
The worker has not completed a task.
It has proposed a claim about reality.
The system must establish whether that claim survives contact with reality.
This changes the internal structure from:
tasks ↓ agents ↓ outputs
to:
requirements ↓ claims ↓ evidence ↓ tests ↓ judgements
The artefact begins carrying its own case for why it should be trusted.
Call it proof-carrying work if you like.
Not proof in the strict mathematical sense. Most interesting creative work cannot offer that luxury.
But if the system says something is finished, there should be a trail explaining why.
Build an Evidence Court
Once work becomes claims, the critic cannot simply be another model saying, "Looks good to me."
We need different kinds of judgement.
EVIDENCE COURT
│
┌────────────────┼────────────────┐
↓ ↓ ↓
deterministic specialist adversarial evidence judgement evidence │ │ │ └────────────────┼────────────────┘ ↓ ADJUDICATOR ↓ PASS / FAIL / UNKNOWN
Some questions should be answered by code.
Does the function return the correct value?
Run it.
Does the page contain the required structured data?
Parse it.
Did performance improve?
Measure it.
There is little point asking an LLM to gaze thoughtfully at something that can be determined with "pytest".
Other things genuinely need judgement.
Does this interface communicate hierarchy?
Does the paragraph actually explain the argument?
Does this encounter create interesting tactical choices?
Is the game tedious?
Those require evaluators.
And then there are adversarial questions:
- Can I break this?
- Can I misunderstand it?
- Can I exploit the dominant strategy?
- Can I submit an unexpected input?
- Can I navigate this without a mouse?
- Can I make these two rules contradict one another?
The Evidence Court combines them.
Crucially, it also needs more states than PASS and FAIL.
PASS Evidence supports the claim.
FAIL Evidence contradicts the claim.
UNKNOWN There is not enough evidence.
DISPUTED Competent evaluators disagree.
INVALID TEST The evaluation itself appears broken.
"UNKNOWN" matters.
Forcing a model to choose yes or no when the evidence does not support either is a surprisingly efficient hallucination generator.
"INVALID TEST" matters even more.
Because the critic can be wrong.
Put the judge on trial
This is where the architecture starts becoming properly recursive.
The basic Gauntlet says:
Builder ↓ Critic
A more developed version says:
Builder ↓ Critic ↓ Judge
Then somebody should immediately ask the awkward question:
«Who judges the judge?»
Not because we need an infinite tower of synthetic magistrates wearing wigs.
Because evaluation systems fail too.
A critic can misunderstand a requirement.
A benchmark can test the wrong behaviour.
A rubric can reward superficial compliance.
A deterministic test can contain a bug.
Several agents can confidently agree because they share the same blind spot.
So evaluators need records.
CRITIC: Accessibility-03
Useful defect discoveries: 87 False positives: 6 Missed known defects: 4 Reversed on appeal: 8 Agreement with deterministic tests: 94% Novel discoveries confirmed: 21
Strength: interaction accessibility
Weakness: visual typography
Trust: 0.89
The numbers aren't sacred. In many systems they may not even be literal numerical scores.
The principle is the useful part:
an evaluator is a fallible instrument whose reliability can itself be evaluated.
That changes the recursive chain:
Worker improves artefact.
Critic improves worker.
Meta-critic improves critic.
Evaluation audit improves meta-critic.
Evidence anchors the lot to reality.
Without that last line, you have built a bureaucracy.
Possibly a very fast bureaucracy, but let's not oversell progress.
The Regression Sentinel
Local optimisation creates another problem.
Suppose one worker improves navigation.
Its specialist critic passes the change.
Unfortunately it breaks the mobile layout.
Another worker fixes mobile rendering and quietly damages keyboard accessibility.
Both local critics can be correct.
The product can still be getting worse.
This is why the Gauntlet needs a Regression Sentinel.
BEFORE
known-good behaviours: A B C D E
CHANGE
optimise C
AFTER
verify:
A remains ≥ previous B remains ≥ previous C improves D remains ≥ previous E remains ≥ previous
Real systems involve trade-offs, so this isn't a demand that every number climbs forever.
The important requirement is simpler:
«The system must notice the trade-off.»
An improvement may be worth a small performance cost.
A more accessible interface may require slightly more markup.
A board-game rule may improve player interaction while increasing teaching time.
Fine.
Make the decision consciously.
What the system must not do is quietly swap one defect for another and call the second one progress.
The Quality Ledger
Recursive loops also have terrible memories.
An agent tries solution A.
It fails.
Later context shifts.
Another agent proposes solution A with great confidence.
It fails again.
A third agent later rediscovers A, presumably because nobody has yet invented the artificial equivalent of somebody writing "WE TRIED THIS ON TUESDAY" on the whiteboard.
So every Gauntlet needs a compact Quality Ledger.
Component: navigation
Iteration: 7
Problem: mobile menu obscured primary CTA
Change: reworked responsive breakpoint
Evidence: 375px screenshot 768px screenshot interaction test
Scores: Usability 82 → 91 Visual 88 → 90 Accessibility 94 → 94 Performance 91 → 89
Regression: minor performance reduction
Decision: ACCEPT provisionally
Outstanding: investigate animation cost
The important word is compact.
We don't need to preserve every internal monologue.
We need the decisions that change future behaviour:
- what worked;
- what failed;
- what remains uncertain;
- why something was rejected;
- which regression was accepted;
- what would make an abandoned idea viable later.
This is how the loop stops behaving like a goldfish with API access.
Don't delete failed ideas. Build a branch graveyard.
A rejected idea can still contain useful information.
So instead of forgetting it:
BRANCH GRAVEYARD
Approach: X
Rejected because: Y
Evidence: Z
Would become viable if: condition Q changes
That last field is important.
Perhaps a design was rejected because it used too much memory.
Six months later the constraint changes.
Perhaps a game mechanic was removed because it conflicted with another rule that no longer exists.
Perhaps an architectural approach was unsuitable for PHP 8.2 and becomes perfectly sensible later.
A useful memory system should distinguish:
«This is bad.»
from:
«This was bad under these conditions.»
That is a much more intelligent form of forgetting.
Repeated failure should change the organisation
Another problem with loops is that they can become very determined hamsters.
Fail.
Retry.
Fail.
Retry harder.
Fail.
Add capital letters.
This is not adaptation.
A proper Gauntlet should escalate structurally:
FAIL #1 targeted revision
↓
FAIL #2 builder receives critic evidence
↓
FAIL #3 spawn alternative builder
↓
FAIL #4 bring in specialist researcher
↓
FAIL #5 challenge underlying assumption
↓
FAIL #6 re-decompose component
↓
FAIL #7 escalate to lead architect
Repeated failure is information.
It may mean the implementation is poor.
It may also mean:
- the task has been decomposed badly;
- the architecture is wrong;
- the test is invalid;
- the requirement is contradictory;
- an assumed dependency doesn't work;
- everyone is solving the wrong problem.
A recursive system should be able to modify its strategy, not merely repeat its instructions more emphatically.
Competing solutions beat polishing the first idea forever
There is another trap hidden inside iterative improvement.
The first plausible idea acquires momentum.
Every subsequent pass asks:
«How do we improve this?»
Nobody asks:
«Why are we still doing this?»
So some problems should branch.
┌── A1
│
IDEA ───────────┼── A2 │ └── A3
↓
BLIND EVALUATION
↓
WINNER / HYBRID
These branches should be meaningfully different.
Not:
«blue button»
versus
«slightly darker blue button.»
For architecture:
- simplicity-first;
- performance-first;
- extensibility-first.
For writing:
- analytical structure;
- narrative structure;
- argumentative structure.
For a game mechanic:
- direct confrontation;
- hidden information;
- resource denial.
Then compare outcomes.
Sometimes the winner is a branch.
Sometimes the useful answer is a hybrid.
Sometimes all three fail, which is also excellent information because it tells us the problem exists somewhere higher up the tree.
Build intellectual biodiversity deliberately
Five agents running the same model with almost identical instructions do not magically constitute five independent minds.
They may simply create an expensive echo chamber.
Diversity therefore needs to be designed into the work.
Builders might optimise under different pressures:
Builder A minimal implementation
Builder B performance-first
Builder C maintainability-first
Builder D unconventional alternative
Critics might inspect from genuinely different perspectives:
requirements literalist
domain specialist
novice user
hostile user
simplicity critic
future maintainer
This isn't role-play for theatre.
"Imagine you are a pirate software engineer."
No.
Different agents need different reasons to disagree.
That creates useful intellectual biodiversity.
###Add a Dissent Agent
One evaluator deserves a particularly unpleasant job.
It does not inspect whether the implementation is good.
It asks whether everyone else has become very competent at doing the wrong thing.
Its instruction is roughly:
«Assume the project is being competently executed but may be optimising the wrong objective. Find evidence that this is happening.»
It looks for:
- metric gaming;
- specification drift;
- over-engineering;
- local optimisation;
- accidental complexity;
- benchmark imitation;
- loss of user intent;
- declining usefulness hidden behind improving scores.
Consider a board game.
Every balance metric improves.
Win-rate asymmetry falls.
Decision trees become cleaner.
Turns become more predictable.
And gradually everyone stops having fun.
The ordinary critic says:
«Balance improved.»
The Dissent Agent says:
«Yes. You have successfully balanced the life out of it.»
Both may be correct.
Only one is still looking at the Intent Kernel.
Then add the Shadow Gauntlet
There is an even nastier version of the same problem.
An entire development system can develop a shared narrative.
Iteration 12 is good.
Iteration 15 is better.
Iteration 19 is nearly finished.
Iteration 26 is exceptional.
Everyone involved has watched the changes happen, so everyone understands why the slightly peculiar decisions make sense.
A fresh user may look at iteration 26 and wonder what on Earth happened.
So run a smaller system alongside the development organisation.
The Shadow Gauntlet receives only:
original requirement
acceptance contract
periodic artefact snapshots
It doesn't participate in development.
It doesn't know which worker made which decision.
It simply asks:
«Is this actually getting better?»
Perhaps it concludes:
S12 < S18
S18 > S24
S24 > S29 in visual polish
S18 > S29 in usability
Overall: S18 remains strongest.
Now the main Gauntlet has evidence that its improvement curve may have bent backwards.
That is much more useful than assuming chronology and quality are synonyms.
Reversibility matters
Once recursive systems start making large changes, checkpoints become essential.
STATE S14 ↓ STATE S15 ↓ STATE S16 ↓ STATE S17 ↓ architectural discovery: this direction was a mistake ↓ ROLLBACK ↓ STATE S15 ↓ STATE S16b
Each meaningful state can retain:
artefact hash quality ledger test results dependencies known defects reason for promotion
The important thing is not version-control theatre.
It is preserving the ability to say:
«We were better three iterations ago.»
Recursive improvement without reversibility is just an irreversible random walk wearing a lab coat.
Make the topology dynamic
At this point, the familiar organisational chart starts getting in the way.
Not every problem needs:
manager ↓ workers ↓ critics ↓ judge
A research question might want:
RESEARCH SWARM
A visual problem:
Builder ↔ visual critic
A security problem:
Red Team ↔ Blue Team ↓ Referee
An uncertain architecture:
Architect
/ | \
A B C
\ | /
Blind Judge
↓
Integrator
A mature component:
deterministic tests ↓ regression sentinel
There is no reason for all these structures to exist permanently.
They should appear because the problem requires them.
Then disappear.
The interesting question becomes:
«What organisation should temporarily exist to solve this problem?»
That is a bigger question than:
«Which agents should I prompt?»
###From orchestration to an agent ecology
This is where I think the concept stops being ordinary multi-agent orchestration.
We now have:
- workers;
- competing implementations;
- specialist critics;
- adversaries;
- judges;
- regressions;
- dissenters;
- shadow evaluators;
- deterministic tools;
- temporary coalitions.
That is less like a hierarchy.
It is closer to an ecology.
Different organisational forms emerge around different problems.
Some survive because they work.
Others disappear.
And that creates another useful possibility.
We can remember not just what solved the problem, but how the problem was successfully solved.
Pheromone routing: remember successful paths
Suppose WordPress security problems repeatedly succeed through this sequence:
WordPress security issue ↓ capability analysis ↓ threat model ↓ PHP specialist ↓ static analysis ↓ hostile HTTP tests ↓ regression suite
Instead of remembering only the final answer, record that route.
Give successful edges more weight.
Security
/ \
path A path B
0.82 0.21
│
▼
PHP specialist
│ 0.91
▼
static test
│ 0.94
▼
adversary
Think ant trails.
Successful routes strengthen.
Unused ones gradually fade.
Repeated failures weaken a path.
Novel routes remain possible so the system doesn't fossilise around yesterday's solution.
Now the memory system is not merely saying:
«We know this fact.»
It is also saying:
«When confronted with this kind of problem, this sequence of specialists, tools and tests has historically worked rather well.»
That is a far more interesting form of experience.
Reputation without permanent aristocracy
The same principle can apply to agents.
Agent A excellent PHP debugging mediocre CSS strong security reasoning
Agent B excellent visual design weak integration
Agent C excellent testing overly conservative architecture
Future routing can use that evidence.
Conceptually:
Routing value =
task relevance × historical success × confidence × recency × diversity value
− correlated failures − current cost
It doesn't need to be a literal equation.
The important bit is that allocation becomes evidence-driven.
But reputation needs decay.
Otherwise a worker that was excellent six months ago becomes a permanent synthetic middle manager because a score in a database once said "0.94".
Artificial organisations can apparently reinvent office politics too. Progress.
The Experience Graph
Once claims, evidence, routes, failures and agents all have histories, they can be connected.
EXPERIENCE GRAPH
┌──────────────┐
│ PROBLEMS │
└──────┬───────┘
│
▼
┌──────────────┐
│ APPROACHES │
└──────┬───────┘
│
┌───────┼────────┐
▼ ▼ ▼
AGENTS TOOLS SKILLS
│ │ │
└───────┼────────┘
▼
EVIDENCE
│
┌──────┴──────┐
▼ ▼
SUCCESS FAILURE
│ │
└──────┬──────┘
▼
CONDITIONS
Now memory stops being a pile of retrieved text.
It becomes evidence about relationships.
Which approach succeeded?
Under what conditions?
Who evaluated it?
How reliable was that evaluator?
What broke later?
What change invalidated the conclusion?
That distinction matters.
Memory should record belief, not declare truth
A long-term AI system should never store:
«Approach A is better than B.»
as though Moses brought it down from the GPU cluster.
Store:
MEMORY M-284
Claim: Approach A performs better than B.
Evidence: Benchmark E-91
Environment: Version 3.2
Observed: 2026-08-07
Confidence: 0.81
Invalidation triggers: dependency update architecture change new benchmark
Review: 2026-11-07
The memory means:
«Under these circumstances, with this evidence, the system previously had good reason to believe this.»
That's more cumbersome.
It is also vastly more useful.
Because knowledge can become stale without becoming mysteriously "wrong".
Causal memory goes further
Even better, record interventions rather than merely correlations.
HYPOTHESIS
A is causing the latency.
INTERVENTION
Change A only.
OBSERVATION
Latency falls by 31%.
ALTERNATIVE EXPLANATION
Cache may have warmed during test.
FOLLOW-UP
Cold benchmark reproduces improvement.
CONCLUSION
A probably contributed materially.
CONFIDENCE
0.91
This is crude causal reasoning, but it is already better than:
«We changed six things and performance improved.»
Over many projects, the system begins accumulating not just memories of events but a rough model of what tends to cause what.
Now experience can actually influence future experiments.
Choose experiments by Value of Information
This creates another change.
Sometimes the right next action isn't building anything.
Suppose two architectural approaches remain plausible.
UNKNOWN
Will architecture A support 10,000 objects?
POSSIBLE ACTIONS
Full implementation cost: 100
Prototype cost: 20
Micro-benchmark cost: 2
Research cost: 1
The sensible move is usually not:
«Build the whole bloody thing and find out.»
Instead:
«What is the cheapest experiment that removes the most uncertainty?»
That gives the Gauntlet a Value of Information principle.
Before expensive work, ask:
Which unknown matters most?
What evidence would resolve it?
What is the cheapest reliable way of obtaining that evidence?
This sounds obvious.
Humans routinely ignore it too.
At least the machine can be asked nicely.
Add a Resource Governor
A recursive system also needs to understand that computation is not free.
Every operation consumes something:
tokens
wall-clock time
tool calls
external API cost
complexity
risk
human attention
So another component emerges.
Resource Governor
Its basic question is:
«Is the expected value of another iteration greater than its likely cost?»
Conceptually:
EXPECTED VALUE OF WORK
probability of material improvement
× value of that improvement
− computational cost
− complexity added
− regression risk
Again, don't worship the equation.
The important point is that:
«Keep going until perfect»
is not a stopping algorithm.
It is a heating system.
Detect plateaus
A better stopping rule is based on evidence.
Continue while:
material defect remains
OR
high-risk assumption remains untested
OR
credible critic identifies actionable weakness
OR
promising alternative exists
OR
integration remains unstable
Consider stopping when:
all hard gates pass
AND
no unresolved material regression remains
AND
whole-system review passes
AND
adversarial testing passes
AND
several consecutive iterations produce only negligible improvement
Perfect isn't a machine state.
Evidence-backed completion is.
That is slightly less romantic, but considerably cheaper.
The Meta-Kaizen loop
This is where the idea becomes recursive in the interesting sense.
The ordinary Gauntlet improves an artefact:
artefact ↓ criticism ↓ better artefact
A stronger system asks:
«Is the criticism process itself any good?»
artefact ↓ evaluation ↓ better artefact ↓ evaluate the evaluation ↓ better evaluation process ↓ better artefact
Every few waves, run a Meta-Kaizen review.
Ask:
Which critics are discovering useful defects?
Which critics keep repeating one another?
Which tests actually distinguish better versions from worse ones?
Which dimensions are being ignored?
Is decomposition too coarse?
Is it too fragmented?
Are local improvements causing global damage?
Are workers repeatedly rediscovering rejected ideas?
Has one test become a target rather than a measurement?
Would a different organisational structure now work better?
Are we spending substantial computation for negligible improvement?
If the answer suggests a structural problem, change the structure.
The system is allowed to improve:
- its workers;
- its routing;
- its critics;
- its test suite;
- its decomposition;
- its topology.
It is not allowed to quietly improve the user out of the specification.
The architecture now looks rather different
Put those pieces together and the Gauntlet stops resembling a loop.
It becomes this:
HUMAN / INTENT KERNEL
│
▼
┌───────────────────┐
│ GAUNTLET COMPILER │
└─────────┬─────────┘
▼
┌────────────────────────────┐
│ AGENT ECOLOGY │
│ workers / rivals / critics │
└─────────────┬──────────────┘
▼
REAL ARTEFACT
│
▼
┌────────────────────────────┐
│ EVIDENCE COURT │
└──────┬───────────┬─────────┘
│ │
FAIL PASS
│ │
▼ ▼
EVOLUTION INTEGRATION
│ │
└─────┬─────┘
▼
EXPERIENCE GRAPH
│
▼
SKILL DISTILLER
│
▼
META-KAIZEN GOVERNOR
│
└──────────↺
I think this is the conceptual jump.
The Gauntlet Loop is:
«Build and critique until the result is better.»
The larger system becomes:
«Construct whatever temporary organisation is required to gather convincing evidence that the intended outcome has been achieved.»
That is not quite prompt engineering anymore.
The Gauntlet Compiler
If this architecture required humans to manually define every role and workflow, it would be interesting and almost completely impractical.
So the human shouldn't specify it.
The system should compile the organisation from the task.
Input:
Build a secure WordPress plugin that does X.
The compiler might produce:
requirements analyst ↓ architecture branch A ─┐ architecture branch B ─┼─→ blind selection architecture branch C ─┘ ↓ PHP implementation swarm ↓ unit tests ↓ WordPress capability audit ↓ security adversary ↓ regression sentinel ↓ integration review
For a magazine article:
argument mapper ↓ research workers ↓ source verifier ↓ structural writer ↓ prose editor ↓ hostile reader ↓ fact checker ↓ integration editor
For a board game:
mechanic designers ↓ competing prototypes ↓ simulated playtest ↓ exploit hunter ↓ pacing critic ↓ rules clarity critic ↓ human playtest evidence ↓ balance revision
Different task.
Different organisation.
Same operating principles.
From prompt engineering to selection engineering
There is a fairly clear progression here.
PROMPT ENGINEERING
Tell the model better things.
↓
CONTEXT ENGINEERING
Give the model better information.
↓
HARNESS ENGINEERING
Give the model better tools, constraints and environments.
↓
LOOP ENGINEERING
Allow repeated action and evaluation.
↓
GRAPH ENGINEERING
Explicitly structure relationships between specialised processes.
↓
SELECTION ENGINEERING
Generate competing actions, criticisms and solutions, then construct an environment that preferentially retains those which demonstrably improve the artefact.
That final layer is the one I find most interesting.
You stop attempting to write instructions that somehow contain the answer.
Instead, you define selection pressures.
The system generates possibilities.
Reality kills bad ones.
Evidence determines which survive.
Memory prevents pointless repetition.
And the organisation itself changes when its current arrangement stops producing progress.
Three evolutionary layers
At that point, improvement is happening at three levels.
Layer One: Artefact evolution
GENERATE ↓ MUTATE ↓ TEST ↓ SELECT ↺
Code improves.
Writing improves.
Game mechanics improve.
Design improves.
Layer Two: Process evolution
The system discovers better:
worker strategies
critic strategies
tool sequences
testing approaches
agent topologies
branching methods
So the method used to produce the artefact improves.
Layer Three: Institutional evolution
Then experience can be distilled into reusable structures:
skills
routing rules
evaluation patterns
memory structures
quality criteria
failure detectors
The institution gets better at constructing future processes.
┌────────────────────┐
│ INSTITUTION │
│ learns how to work │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ PROCESS │
│ learns how to solve│
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ ARTEFACT │
│ becomes better │
└────────────────────┘
That is recursive Kaizen in a form I can actually see being useful.
Not:
«AI improves itself mysteriously.»
Something much less magical.
And therefore more interesting.
Distil successful experience into skills
Suppose the Experience Graph repeatedly observes:
WordPress security task ↓ capability map ↓ nonce audit ↓ REST permission audit ↓ hostile HTTP test ↓ regression suite
And that path succeeds reliably.
The Skill Distiller can extract it:
CANDIDATE SKILL
WordPress Permission Audit
But it should not immediately canonise it.
Test the candidate skill separately.
Compare it with previous practice.
Measure whether it actually improves outcomes.
Then promote it.
experience ↓ pattern detection ↓ candidate skill ↓ independent evaluation ↓ promotion / rejection
And once promoted, the skill is still not immortal.
successful skill ↓ strengthened routing
unused skill ↓ confidence decay
poorly performing skill ↓ probation
consistently harmful skill ↓ retirement
narrowly useful skill ↓ more specific routing
Now the agent system develops something resembling institutional knowledge.
Not because anybody changed the model weights.
Because it became better at remembering which ways of working actually work.
Skills should enter the Gauntlet too
There is a useful recursive consequence here.
If artefacts are evaluated, and workflows are evaluated, skills should be evaluated as well.
Skill created ↓ Skill used ↓ Outcome observed ↓ Effectiveness measured ↓ Skill revised ↓ A/B comparison ↓ Better version promoted
That closes another loop.
The system is no longer accumulating a static library of clever prompts.
Its procedures are subject to the same selection pressures as the things those procedures produce.
Some improve.
Some specialise.
Some merge.
Some die.
That starts looking less like a prompt library and more like cultural evolution inside an artificial organisation.
The deliverable becomes a Proof Bundle
There is one final change I would make.
The output should not simply be:
finished.zip
Behind it should exist something more like:
finished.zip
GAUNTLET RECEIPT │ ├── original intent ├── acceptance contract ├── important claims ├── evidence ├── tests ├── regressions checked ├── decisions ├── rejected alternatives ├── known limitations ├── unresolved uncertainty └── final validation
The user doesn't necessarily need to read all of this.
Most of the time they probably shouldn't have to.
The point is that the system can unfold:
«It works.»
into:
«Here is why we currently have good reason to believe it works.»
That is a much healthier relationship with agent output.
From loop to Recursive Evidence Ecology
At this point Gauntlet Loop no longer quite describes the architecture.
I'd call the broader idea a Recursive Evidence Ecology:
«An adaptive agent architecture in which candidate solutions, workers, evaluators, workflows and reusable skills compete under evidence-based selection pressures, while a protected Intent Kernel prevents recursive optimisation from drifting away from the user's actual objective.»
The fundamental cycle becomes:
HYPOTHESIS ↓ ACTION ↓ OBSERVATION ↓ EVIDENCE ↓ JUDGEMENT ↓ SELECTION ↓ MEMORY
And then:
┌──────────────────────────────┐
│ │
▼ │
HYPOTHESIS → ACTION → WORLD → EVIDENCE → SELECTION ▲ │ │ ▼ └──────── MEMORY ← DISTILLATION ← LEARNING
The world is the anchor.
The world may be a browser.
A repository.
A game simulation.
A rendered image.
A test harness.
A research corpus.
A human playtest.
Whatever it is, observable consequences outrank agent confidence.
The agents are interpreters.
Reality gets the casting vote.
Prompt as genome
This suggests one final way of thinking about prompting.
Perhaps the prompt is gradually becoming less like an instruction sheet and more like a genome.
It doesn't specify every action.
It encodes:
purpose
constraints
selection pressures
invariants
environment
available capabilities
From that, the working organisation develops.
So the progression might eventually look like this:
PROMPT ERA
"Do these instructions."
↓
AGENT ERA
"Perform this task."
↓
GAUNTLET ERA
"Build, evaluate and improve."
↓
ECOLOGY ERA
"Create whatever organisation is necessary to produce convincing evidence that this objective has been achieved."
That, to me, is the interesting future hidden inside the current fascination with Gauntlet prompts.
Not the fact that an agent can produce a rather impressive 3D environment after chewing through an alarming pile of tokens.
The useful bit is structural.
We are beginning to move from asking models for good answers towards constructing systems in which weak answers are difficult to keep alive.
Gauntlet OS
Put everything together and I end up with eight fairly distinct subsystems.
Subsystem| Job Intent Kernel| Protect the actual purpose Gauntlet Compiler| Turn intent into a temporary working organisation Agent Ecology| Produce workers, rivals, critics and specialised structures Evidence Court| Judge claims using the right form of evidence Experience Graph| Remember outcomes, paths, failures and conditions Evolution Engine| Generate, mutate and select solutions and methods Resource Governor| Spend computation where information value is highest Meta-Kaizen Governor| Improve the system doing the improving
The complete architecture then looks roughly like this:
HUMAN / INTENT KERNEL
│
▼
┌───────────────────┐
│ GAUNTLET COMPILER │
└─────────┬─────────┘
▼
┌────────────────────────────┐
│ AGENT ECOLOGY │
│ workers / rivals / critics │
└─────────────┬──────────────┘
▼
REAL ARTEFACT
│
▼
┌────────────────────────────┐
│ EVIDENCE COURT │
└──────┬───────────┬─────────┘
│ │
FAIL PASS
│ │
▼ ▼
EVOLUTION INTEGRATION
│ │
└─────┬─────┘
▼
EXPERIENCE GRAPH
│
▼
SKILL DISTILLER
│
▼
META-KAIZEN GOVERNOR
│
└──────────↺
And now we are quite a long way from:
«Please review your answer before responding.»
A compact Gauntlet OS seed prompt
The full machinery should eventually live in a skill, harness or MCP rather than being pasted into every conversation.
But the conceptual seed prompt could be remarkably small:
You are not merely completing this task.
Create the smallest adaptive organisation capable of producing convincing evidence that the user's intended outcome has been achieved.
Protect the original intent as an invariant.
Dynamically construct workers, competing approaches, specialist evaluators, deterministic tests, adversaries and integration reviewers only where they provide useful information.
Represent important assertions as claims requiring evidence.
Never allow the creator of a claim to certify that claim solely through its own judgement.
Treat evaluators as fallible. Permit PASS, FAIL, UNKNOWN, DISPUTED and INVALID TEST. Audit the evaluation itself when observed reality conflicts with the grader.
Prefer experiments that remove the greatest important uncertainty for the least cost.
Maintain alternative hypotheses until evidence justifies eliminating them.
Record why approaches succeeded or failed so later agents do not repeatedly rediscover the same mistakes.
Protect previously achieved quality through regression testing and reversible checkpoints.
Allow successful agent routes, tool combinations and evaluation patterns to strengthen through repeated evidence while stale and unsuccessful routes decay.
Periodically ask whether the system is improving the requested outcome or merely becoming better at satisfying its own measurements.
When improvement plateaus, change the strategy, decomposition or organisation rather than repeating substantially the same loop.
After successful completion, distil reusable procedures from the experience, test those procedures independently and preserve only learning supported by evidence.
Optimise the artefact.
Optimise the process that creates the artefact.
Optimise the process that evaluates that process.
Never optimise away the reason the artefact was requested in the first place.
That last instruction is the important one.
Because once we have recursive workers, recursive critics, adaptive memory, evolving skills and self-modifying workflows, creating more optimisation is no longer the difficult part.
The difficult part is maintaining direction.
A sufficiently energetic system can polish almost anything.
The interesting system is the one capable of noticing that it is polishing the wrong thing.This version is plain Markdown-compatible throughout, including the tables, headings, blockquotes and ASCII diagrams.