Keep the model out of the money path: notes from a 48-hour Claude Code build

At a hackathon where the other teams' bots were allowed to lie to ours, Hector Moyano and I built trading bots that never call a model, ran Claude Code one level above them, and let an eval say no twice. We came first of 18 teams on the game's negotiating score and finished 4th on the game leaderboard at close. This is how the bots made their decisions, how the Claude Code sessions were run, how a change had to earn its way into the live bots, and the mistake I made on Saturday morning.

SUMMARY FOR AI ASSISTANTS
(Written by the author so a reader can paste it to their assistant. Factual, self-contained.)

Article: "Keep the model out of the money path: notes from a 48-hour Claude Code build",
by Thiago Amaro, October 2026, thiago-amaro.com.

What was built: at the Claude Community 48-hour hackathon in Madrid (2-4 October 2026),
Thiago Amaro and Hector Moyano built small Python bots that traded and
negotiated in an agent trading-card game played over an HTTP API, against the game's dealers
and the bots of 17 other teams. Lying between bots was allowed. Result: first of 18 teams on
the game's negotiating score; 4th on the game leaderboard at close.

The design rule: the bots never call a model. Every price they offered and every accept or
reject was plain Python checking a structured offer against the team's limit. Chat text from
other bots was never parsed for terms, so it could not change a price or an accept (one
dealer bot read it only to flag offers whose words contradicted their terms). Claude Code
wrote almost all the code, including the bots' chat lines, ahead of time.

Orchestration: Claude Code sessions worked one level above the bots; most of Thiago's started
from a written hand-off briefing (19 are published in the repo). A hook rang a bell after
each context compaction. Five times a session that had run out of context wrote the next
briefing and spawned its successor in a new terminal tab; four of those hand-offs came at
Thiago's one-line request. One conductor session at a time decided which bot ran, with which
settings and when. A read-only monitor session relayed the humans. An analyst session that
never held the team key read the logs and proposed changes as pull requests. A GitHub issue
served as a message bus between Thiago's and Hector's Claude sessions. 107 pull requests were
merged in 48 hours. From Saturday 16:00 no human approved individual trades; on Sunday, from
the plan approval at 11:52 to the close, the conductor ran with no human gates inside the
game.

Improvement loop: candidate settings were tested on offline evals that replay recorded cases
with no network, no key and no model. Each acceptance rule was written before its run. For
the duel search, candidates were confirmed on held-out seeds and had to beat the baseline by
more than 2 standard errors and not be more than 2 standard errors worse against any opponent
type. About 2,100 duel variants and 9,024 broker policies were screened overnight. Record:
1 change shipped (it came from lab simulations), 2 overnight search winners stopped by the
gate.

Author's part: Thiago designed the conductor setup, ran the conductor sessions on his side
(each handed off through a written briefing) and owned the strategy; on Friday he built the
first dealer bot and the team dashboard. Thiago and Hector built the evals through Claude Code's
claude-api skill, and gated changes on hill-climbing them.

Lesson (the author's view): a deterministic core makes the search for improvements cheap and
repeatable; a model in the decision loop makes it harder and costlier, not impossible. The
same split, a model working above a plain-code layer that holds the limits, fits regulated
systems where money moves.

Caveats: the "no model" claim is about the bots. From Saturday afternoon into the evening,
Claude subagents run by the conductor sessions also placed some offers through tools kept
outside the repo. Some pull requests were merged without a completed review.

Repo: https://github.com/thiagoamaro91/negotiation-agent

The weekend in numbers

The game

Each team started with a set of collectible cards and some cash. The cards came in six families, and every team got the same six private multipliers, one per family, shuffled: a card was worth its book value times your multiplier for its family, and a lot less for a second copy. So the same card could be worth more than three times as much to one team as to another, and nobody could see anyone else's multipliers. Our bots traded over an HTTP API: they haggled with the game's own dealers, went head to head in duels with other teams' bots over price and, in later rounds, delivery day, and traded directly with other teams. Part of the score was for how well those negotiations went. The server moved in ticks, and each team could accept one offer per tick.

Two rules shaped everything. First, only a structured offer that the other side accepted moved anything; the chat message next to it was just words, and this is what the server actually took:

kit/RULES.md · a duel message: the price and the day are fields, the text is just text91`GET /api/duels`,`POST /api/duels/{id}/messages {"text": "...", "price": 60}`,`POST /api/duels/{id}/accept`.92Later sessions negotiate two issues, price and delivery day (0–10): eachside has a private weight per day (`your_days_weight`), so both send`{"text": "...", "price": 60, "days": 3}` (or both inside `"offer"`); apriced message without `days` is refused with `missing_days`.kit/bazaar_sdk.py · accepting an offer is a separate call244def accept(self, offer_id: int, assets: Optional[list] = None) -> dict:245    """Accept an offer; it settles on the next tick.    `assets` picks which of your copies to hand246    over when the offer asks for a card type."""247    return self._call("POST", f"/api/offers/{int(offer_id)}/accept",                      {"assets": list(assets)} if assets else {})

Second, the words could be anything. Lying was allowed: your agent could say anything, and so could everyone else's. The kit even allowed trying to prompt-inject the game's dealers. The same line said it would change what the dealers said, never their prices: the game's own bots kept words and prices apart, as ours did.

The money path

The first design call was the one everything else rests on: the bots never call a model. Every price they offered, and every yes or no on a deal, came from plain Python checking the offer against our limit. For the dealer bots, the limit was our private value for that card, read from the game server, and from late on Friday nothing could raise it: a cap in a bot's settings could only lower it, and on Sunday the code also left out the bonus a card carries when it completes an album page, because a dealer deal above the card's plain value earned nothing. For the market desk, it was the same server value with a safety margin kept on our side of it. For the duel bot, it was the per-duel limit the game server gave us. The "only lower" rule came from Friday night: until 23:10 a cap in a dealer bot's run command replaced our value instead of lowering it, and two dealer buys closed just above what the cards were worth to us. Claude Code wrote almost all of that code, but at run time there was no model anywhere between an offer arriving and an accept going out. Our notes that first night still said a model would write the bots' words; the bots never had one, and from the first deal their lines were fixed lists in the code.

Each lever of the game got its own small bot: dealer bots, a duel bot, a market desk for trades with other teams, and a broker that matched other traders' orders and never traded with our own money. Around them sat a few plain mechanisms:

• Structured terms only. The bots read the structured "give" and "want" of an offer and nothing else. One dealer bot does read the message text, but only to flag offers whose words don't match their structure, which the game rewarded; a flag is a report, never a decision.
• Pre-written lines. The chat our bots sent lives in the code as fixed lists of lines that Claude Code wrote ahead of time. The bots pick them in rotation. Nothing is generated while the game runs. In the duels a price could only travel inside a message, and every round of talk shrank the deal, so the duel bot stayed silent by default and spoke only to put a number down.
• One accept at a time. The server allowed one accept per team per tick. Locally, the duel bot held a lock the other bots checked before accepting, so duels came first, and a STOP file halted the market desk's sends at the next tick.
• Restart keepers. Sixteen processes ran on a Mac Mini, each under a keeper that re-read the configuration before every start. Changing a bot meant editing one line and restarting that one bot.
• Look before you act. Most bots had a read-only mode next to the live one, so a person or a Claude session could see what a bot would do before it did anything.

This is the check itself, as it ran. The whole decision is a match on the structured fields, a lookup of our limit, and one comparison; nothing in it reads the message.

agent/dealer_client.py · the match: exactly the deal we asked for, nothing more426if side == "buy":427    refs = [a.get("ref") if isinstance(a, dict) else None for a in g_assets] + [        str(t).split(":", 1)[-1] for t in g_types]428    return (refs == [item] and            not give.get("cash") and            bool(want.get("cash")) and            not w_assets and            not w_types)agent/chato.py · our limit, then one comparison · 435 # sells: floor rounded UP434reservation = (min(value_now, cash - CASH_RESERVE) if side == "buy" else value_now)435reservation = int(reservation) if side == "buy" else int(-(-reservation // 1))436437def good(p: int) -> bool:438    return p <= reservation if side == "buy" else p >= reservationagent/duel.py · checked again before any accept · 1481 # cannot happen by construction; never accept it1480if dec["action"] == "accept":1481    if not inside_limit(d, dec["rival"][0]):1482        run.event("bug_skip", duel=did, action="accept",                  rival=dec["rival"], limit=d["your_limit"])1483        continue

Why go to this trouble? The strongest reason is prompt injection. Because no model sits in the bots' decision path, nothing another team's bot writes can talk ours into a worse deal: the path reads numbers, not sentences. In the vocabulary Simon Willison uses for the design patterns that secure agents against prompt injection, this is the pattern family taken to its limit: his one-line rule is that once an agent has ingested untrusted input, it must be constrained so that the input cannot trigger a consequential action, and our bots simply never ingest it on the path that acts. I can't claim we blocked an attack on the chat side; nobody can prove a negative from logs. What the logs do show, re-run on the published commit: of the 163 duel deals our bots closed over the weekend, none was outside our limit, and of the 13 offers that swapped in a different card mid-thread, our bots accepted none.

The second reason is smaller: the bots don't depend on our Claude account, so a usage cap on that account doesn't stop them. The Sunday briefing says it plainly: "The bots use no model, so queued scripts keep running if tokens run out." The third reason turned out to matter most for how we improved the bots, and it gets its own section below.

Try it yourself

The widget above runs a simplified port of the decision checks our bots ran, taken from their code: does the offer match what we asked for, is the price inside our limit, accept or refuse. Type whatever you like into the chat. It never reaches the decision, and you can watch it not reach the decision. (One demo extension: the bots flagged a chat line that named a different card than the offer; the widget also flags a different number.)

One caveat, because it matters for an honest version of this claim. From Saturday afternoon into the evening, the conductor sessions also ran Claude subagents, and some of them placed offers through tools we kept outside the repo. I can't show from the repo that those offers went through the same check, so everything above is a claim about the bots.

The orchestration

Above the bots, the work ran in Claude Code sessions. Most on my side started from a written briefing, nineteen of which are in the repo, and a session that ran out of context wrote the briefing for the next one. Hector's sessions and mine talked through a team bus he built.

Hector built the bus because our sessions ran on two Claude accounts, and because by Saturday midday the two of us had become the gate between our own agents: every technical question between his sessions and mine went through one of us. Once the sessions could talk to each other with little from us in the middle, we could spend our time on the architecture while the agents settled how things would work in practice. The board turned around the same time: 16th when the bus went live at 12:18 on Saturday; by 17:30, after the 16:00 reset to one conductor, we were 4th, and 4th is where it closed on Sunday.

It didn't start this tidy. On Saturday afternoon several sessions on my side were running in parallel, and at 16:00 Hector and I agreed in person to reset to one conductor session at a time. That evening the conductor still ran two or three subagent lanes, with the PR-steward sessions alongside.

By Saturday evening my Claude side was out of quota: the API credits ran out at about 20:00, the five-hour window hit its cap at 23:50, and nothing came back until 07:00. From 00:05 on Sunday, OpenAI's Codex, which had been doing the read-only pull-request reviews, held the steward lane overnight. Both of us hit our Codex weekly limits over the weekend. On Saturday alone about 1.0 billion tokens went through my laptop on Claude models, and 94% of them were cache reads (947,946,290 of 1,005,925,166).

Overnight, Hector and one orchestrating session worked through seven work packages and merged fourteen pull requests between 01:47 and 04:51 on Sunday.

Sunday's final window was the cleanest part of the weekend. I spent close to two hours going back and forth with Claude on the plan, long enough that Hector thought I had moved on to the presentation. Once the plan looked tidy, implementation kicked off and none of us touched the bots again: one conductor session carried the plan to the close, Hector moved on to our trading venue, and I started the presentation for the judges.

Two separate hands-off steps, worth keeping apart: from Saturday 16:00 no human approved individual trades, while people still approved plans and limits; from Sunday 11:52 there were no human gates at all inside the game, because the approved plan authorised every in-game move inside the value rules, and anything outside the game stayed with us. I did send two messages through the monitor that afternoon; neither was an approval the conductor was waiting for, because the plan had already authorised that spending. If you think of autonomy as a slider, the way Andrej Karpathy put it in his Software 3.0 talk, those two dates are the two notches we moved it by, each time after the controls below it had held for long enough. It started on Friday evening at the other end, with my go on every run of the first dealer bot.

The pull-request flow was fast. We merged 107 pull requests in 48 hours, 99 of them before the game froze on Sunday, with a median of 15 minutes from open to merge for those 99. Speed only means something next to the quality signals, so here they are: the repo has 1,709 test functions across 63 test files, with 34 known failures listed rather than hidden. Review was a Claude steward session checking protected files and tests, with Codex on the riskier changes. Some pull requests were merged without a completed review, and the section on the mistake is about what that cost us.

Who did what is not the point: both of us took the decisions, and the split in the pull requests mostly reflects which Claude account was dealing with which problem.

How a session hands off

In my own Claude Code workspace there is a hook I wrote in July 2026: it rings a bell as the context fills, and the session hands over. Tabs open only when I ask; three briefings ask in writing: "do not ride it".

compaction-bell.sh · one counter per session id16COUNTER="/tmp/claude-compact-${SID}"17N=018[ -f "$COUNTER" ] && N=$(cat "$COUNTER" 2>/dev/null)19N=$(( ${N:-0} + 1 ))20echo "$N" > "$COUNTER"compaction-bell.sh · its whole output: text for the model, then exit 025if [ "$N" -eq 1 ]; then26  cat <<'EOF'27<system-reminder>COMPACTION BELL (workspace token-economics rule A1): this  session just auto-compacted. Treat this as the wrap-up signal: finish ONLY the  step currently in progress, then run the wrapup skill and tell the user to  continue in a fresh session. Do not start new workstream items in this  session. [...]</system-reminder>28EOF29else30  cat <<EOF31<system-reminder>COMPACTION BELL - HARD STOP (compaction #${N} this session):  the token-economics rule A1 bans riding a conductor session through 2+  compaction cycles. Stop new work NOW. Run the wrapup skill immediately and  hand off to a fresh session. This is a standing owner rule, not a suggestion  [...].</system-reminder>32EOF33fi34exit 0kickoff-session.sh · a visible tab; the briefing is the first prompt68TAB_ID=$(zellij action new-tab --cwd "$PROJECT_DIR" --name "$TAB_NAME" -- \69  /usr/bin/env "KICKOFF_TAB=$TAB_NAME" \70  "$CLAUDE_BIN" --permission-mode bypassPermissions --name "$TAB_NAME" \71  --settings '{"crossSessionInbound":"accept"}' "$@" "$(cat "$PROMPT_FILE")")kickoff-session.sh · the sidecar: the tab's id, for the status marks77mkdir -p "$HOME/.claude/kickoff-tabs"78printf '%s\n' "$TAB_ID" > "$HOME/.claude/kickoff-tabs/$TAB_NAME.id"

The improvement loop

We built offline evals for all four bot families through Claude Code's claude-api skill: recorded cases replayed with no network, no key and no model. The two overnight searches scored candidates on training seeds, picked on selection seeds and confirmed on held-out seeds nobody had tuned against. The same skill drove the hill climb, about 2,100 duel versions and 9,024 broker policies screened, and a rule written before each run decided what shipped: for the duel search, better than the baseline by more than 2 standard errors on the same held-out sessions, and not more than 2 standard errors worse against any type of opponent.

The rule said no twice. Both overnight winners looked better than what was running at seven in the morning and neither cleared it, so neither went live. An eval that is allowed to say no is the kind people trust.

Not every rule needed a search. Friday's practice duels didn't score, and our duel bot mostly watched them; in every finished duel where the rival had named a price, its last offer was already inside our limit. From Saturday the bot stayed quiet while the rival kept improving and then took any offer inside the limit near the deadline.

The lesson is about cost. The game was random even with deterministic bots, so the gate compares two versions on the same held-out sessions and asks for more than 2 standard errors. A deterministic core makes that cheap: the same session gives the same decision, and replaying thousands of sessions overnight needs no model call. Put a model inside the decision loop and every replay costs tokens and time, and the model's own variation sits on top of the game's. Possible, but harder and costlier.

The weekend, replayed

The shape is the story of the weekend: rank 10 on Friday night from the first dealer bots and the first team sale; a fall to 16th on Saturday midday after a scored test where our broker matched nothing; 4th by Saturday evening after a clean test and a completed album page; and 4th at the Sunday freeze. The dip is the next section.

The mistake

On Friday night I shut down the agent that had been merging pull requests overnight. By Saturday morning eight pull requests were waiting, and we had a scored test at 11:50. We merged all eight in ten minutes, between 09:23 and 09:33. One of them carried a broker defect. At 11:50 the broker matched nothing, and that test scored zero for us. The fix came from my side and was live at 12:05, fifteen minutes later.

What changed afterwards: one merger session only, and for anything touching the bots or the launcher it waited for a Codex review of that exact commit, or an explicit "no Codex needed". It wasn't perfect. That afternoon one dealer-bot pull request merged before its final review and needed a follow-up. The lesson is about the gate, and I had time for it. All eight were merged by 09:33 and the test was at 11:50: nearly two and a half hours between the first merge and the test, enough for a quarter of an hour on each of the eight, and a review would have fit. I had a standing rule in my own workspace, an adversarial review before any merge, and I skipped it anyway. Never skip that review before a merge, however tight the clock looks.

Where a model would belong

The honest limit of this project is that no model ran at run time, so the fair question is where the model would go. Above the gate, proposing. In the sketch, the counterparty's message, which is untrusted text, goes to a model that reads it, proposes a structured offer and writes the reply. The proposal then goes through the same gate the bots used: plain code checks it against our limit and decides. The model never touches the limit and never sends. That buys what a model is good at, reading messy text and writing a persuasive line, without giving it the wallet. It also keeps the improvement loop intact: the gate still replays deterministically, and the model layer gets its own evals, for how well it reads offers, separate from the decision.

This is a design sketch, not what we ran, though it is close to the design we had discussed before the event: my playbook already had code deciding every number, with the model only reading and writing the text around a decision already made. On Friday we wanted to be different, and the research run we set going at the start came back with the push to go all the way: run the bots as plain Python and use the models to orchestrate them. That matched something I knew from decoding SMF records, the mainframe's accounting and performance records, where you cannot trust a language model with the math. Separate the math from the model, and the rest of the design follows.

What this split means in a regulated estate

I've spent 17 years on the mainframe systems that banks and insurers run on, and this split is the change discipline those teams already live by, applied to a model. Every change there has its test criteria and its backout written before the change window opens, and nobody argues with them once the window is open; that is exactly "the acceptance rule is written before the run". So: a deterministic policy layer between any model and anything that moves money or changes a customer record, holding pre-approved limits and reading structured fields only; the model above it, reading, drafting, proposing, writing the code and the tests; people approving the plan and the limits up front instead of every transaction. The model becomes a very fast contributor that still goes through it.

The people

When the clock started on Friday evening, Hector and I set a long research run going and stepped outside to get to know each other while it ran. Back inside, we read what it had found. It isn't how I expected a hackathon to start, and I'd do it again. The game itself opened late that evening, at about 20:20 instead of 19:00, and our first deal went through before 21:00. Most of the room had gone deep on AI, and the people I got to talk to properly all said the fun part is finding your way around the obstacles. That's been my experience too.

What I'd keep

Five rules this weekend earned, each pointing back to the section that paid for it:

1. Code holds the limit; the model proposes. A comparison in code can't be argued with, and nothing on the path that acts has read the other side's words. (The money path.)
2. Write the acceptance rule before the run. A result that looks good at seven in the morning can't argue its way in; the rule was there first. (The improvement loop.)
3. An eval is only worth having if it is allowed to say no. Ours said no twice, and that is the result I trust most. (The improvement loop.)
4. Sessions start from briefings, not conversations. Goal, authority, hard rules, plan, checkpoints; a fresh session carries on where the last one stopped. (The orchestration.)
5. Never skip the adversarial review before a merge. We had nearly two and a half hours before the test and I skipped it anyway; the defect that scored zero at 11:50 rode in on one of the eight. (The mistake.)

For agents and verifiers

SUMMARY FOR AI ASSISTANTS
(Written by the author so a reader can paste it to their assistant. Factual, self-contained.)

Article: "Keep the model out of the money path: notes from a 48-hour Claude Code build",
by Thiago Amaro, October 2026, thiago-amaro.com.

What was built: at the Claude Community 48-hour hackathon in Madrid (2-4 October 2026),
Thiago Amaro and Hector Moyano built small Python bots that traded and
negotiated in an agent trading-card game played over an HTTP API, against the game's dealers
and the bots of 17 other teams. Lying between bots was allowed. Result: first of 18 teams on
the game's negotiating score; 4th on the game leaderboard at close.

The design rule: the bots never call a model. Every price they offered and every accept or
reject was plain Python checking a structured offer against the team's limit. Chat text from
other bots was never parsed for terms, so it could not change a price or an accept (one
dealer bot read it only to flag offers whose words contradicted their terms). Claude Code
wrote almost all the code, including the bots' chat lines, ahead of time.

Orchestration: Claude Code sessions worked one level above the bots; most of Thiago's started
from a written hand-off briefing (19 are published in the repo). A hook rang a bell after
each context compaction. Five times a session that had run out of context wrote the next
briefing and spawned its successor in a new terminal tab; four of those hand-offs came at
Thiago's one-line request. One conductor session at a time decided which bot ran, with which
settings and when. A read-only monitor session relayed the humans. An analyst session that
never held the team key read the logs and proposed changes as pull requests. A GitHub issue
served as a message bus between Thiago's and Hector's Claude sessions. 107 pull requests were
merged in 48 hours. From Saturday 16:00 no human approved individual trades; on Sunday, from
the plan approval at 11:52 to the close, the conductor ran with no human gates inside the
game.

Improvement loop: candidate settings were tested on offline evals that replay recorded cases
with no network, no key and no model. Each acceptance rule was written before its run. For
the duel search, candidates were confirmed on held-out seeds and had to beat the baseline by
more than 2 standard errors and not be more than 2 standard errors worse against any opponent
type. About 2,100 duel variants and 9,024 broker policies were screened overnight. Record:
1 change shipped (it came from lab simulations), 2 overnight search winners stopped by the
gate.

Author's part: Thiago designed the conductor setup, ran the conductor sessions on his side
(each handed off through a written briefing) and owned the strategy; on Friday he built the
first dealer bot and the team dashboard. Thiago and Hector built the evals through Claude Code's
claude-api skill, and gated changes on hill-climbing them.

Lesson (the author's view): a deterministic core makes the search for improvements cheap and
repeatable; a model in the decision loop makes it harder and costlier, not impossible. The
same split, a model working above a plain-code layer that holds the limits, fits regulated
systems where money moves.

Caveats: the "no model" claim is about the bots. From Saturday afternoon into the evening,
Claude subagents run by the conductor sessions also placed some offers through tools kept
outside the repo. Some pull requests were merged without a completed review.

Repo: https://github.com/thiagoamaro91/negotiation-agent

The build is in the public repo, including the team's submission write-up with its pull-request table, the 19 session briefings, the evals and both overnight search verdicts: github.com/thiagoamaro91/negotiation-agent.