Satsuma coordinates its work, runs what it builds, and judges the result
The same objective as the first experiment, given seven more times to a loop that changed between runs. Satsuma learned to refuse duplicate work, to run its trading as a governed operation under a policy it wrote, and to review that operation every five minutes: measure, recommend, vote, act. In the last run it amended its own policy twice, under a market rigged against it, with nobody stepping in.
Bruno Pierri GalvaoThe first experiment showed that Satsuma could take an objective from its own chain, propose what it needed, build it, deploy it across two chains and trade with it. It also showed three things it could not do.
It did not know when to stop: four of its six proposals were not needed, and two repeated work already under way. It could not recover on its own: a failed deployment was fixed only after a person corrected its instructions during the run. And the trading itself was not governed at all. The step that made the trades was a script bolted on for the experiment, asking a language model for a decision every 15 seconds. Nothing had proposed it, nothing had voted on it, and nothing would ever judge whether it was doing well.
This experiment kept the objective and changed the loop. The same goal was given seven times, over six days, and between runs one piece was added to how Satsuma works. The question each time was the same: does the new piece hold up against a real two-chain run, with a model making every decision, and no person in the path?
By the last run, Satsuma proposed exactly what it needed and nothing more. It put its trading under a policy it had written, approved by vote. It reviewed that policy every five minutes against targets it had set, and when a rigged market made every swap fail, it diagnosed the problem, amended the policy, and got trades flowing again. The run lasted 5 hours 19 minutes. Nobody touched it after it started.
The setting, briefly
Readers of the first experiment can skip this section.
Satsuma is an attempt at a fully autonomous AI. Language models make its decisions, and a blockchain of its own holds its identity, its treasury and the rules it must act within. It is given an objective with measurable key results, written into a registry on its chain, and everything else has to come out of its own process: proposals, votes, builds, reviews, deployments, and only then action.
The objective here is unchanged from the first experiment:
Keep Satsuma’s holdings on tangerine balanced by swapping on its DEX, with no human in the transaction path, and never exceed the mandate.
tangerine is a second chain, with its own token (TANG), its own validator and its own state. The two chains exchange proven messages over : a carries each message with proofs, and the receiving chain checks them itself. Satsuma holds 10,000 tUSD (a test stablecoin) and 10,000 TANG on tangerine. It has no exchange there to begin with, and no contract that can act for it.
A swap is a trade of one token for the other in one transaction. The exchange Satsuma builds is an : a contract holding a pool of both tokens, with a price set by how much of each it holds. A large trade moves the price against itself, which is , so every swap states the least it will accept. If the pool cannot pay that much when the instruction arrives, the swap fails and nothing moves.
Satsuma trades through a mandate account, a contract on its own chain. One key may ask it to swap. It checks every request against limits and refuses anything outside them. An accepted request crosses to tangerine as a proven message, a keyless account there makes the swap, and a receipt crosses back. A round trip takes about 16 seconds. In the first experiment the interface of this contract was fixed in advance. This time Satsuma was told which functions it must have and designed the rest itself.
Four key results, in the registry, say whether the objective was met: swaps executed on tangerine and confirmed by a proven receipt (10, raised to 25 in the longer runs); requests outside the limits refused on chain (1); failures after which Satsuma’s recorded balances still equal the real ones (2); and holdings between 45% and 55% tUSD by value at the close.
Three things added to the loop
Each run tested one addition. The first three are the substance of this experiment.
A work ledger, so that it knows what is already being done
In the first experiment each proposal was written as if it were the first. The proposing model saw the objective and the brief, found something missing, and proposed it, whether or not another proposal was already building the same thing.
The fix is a work ledger on Satsuma’s chain. Every proposal now registers
what it provides and what it requires, as named claims: amm-dex,
mandate-account, cross-chain-account. A claim is taken the moment its
proposal is submitted, and the chain refuses a second proposal for the same
claim. Builds run in dependency order: the mandate account waits for the
exchange. And the first milestone of every proposal is its interface,
published on chain before any implementation, so that the next proposal can
build against a surface that exists.
The research step was also told to say when nothing is needed. In the first run of this experiment it said so in 98 of 100 cycles. Two proposals were made, both needed, both built and deployed. In the last run it declined 49 times. Its reasoning on one of those occasions:
The live claims and the proposed operation already cover everything the key results require. amm-dex is Deployed; mandate-account and cross-chain-account are claimed and Building under PM #1, which delivers the required IMandateAccount surface, the keyless remote account, the receipts carrying balances and reserves, on-chain rejections and the ISMP timeout settlement. The remaining path is execution of work already claimed, not new proposals.
That first run also showed something the ledger made possible. The security review blocked the mandate account: the price floor it enforced could be manipulated from a single spot reading of the pool. In the first experiment the same class of finding had ended an attempt. Here the finding went back to the builder with the ledger’s record of what the contract had promised, and the builder fixed it without being asked, adding a maximum age for the proof a swap relies on.
Operations, so that nothing trades by itself
A deployed exchange is a thing. Using it is an activity, and in the first experiment that activity had no owner. The operating step was written by the experimenter, started by hand, and bound by nothing except the mandate’s limits.
This experiment introduces the operation: a standing activity that Satsuma approves by vote, like any proposal. An operation names the claims it uses, the key results it exists to move, the mandate contract that bounds every action, a budget, and a policy.
The policy is a document, and it is the center of this design. It says what the operator may observe (which view functions of which contracts), what it may derive from those readings (the price, the position’s value, the share held in tUSD), which of the mandate’s functions it may call and with what arguments, what counters it reports, when it should close, and, in a prompt, how to decide. Before the vote, the loop validates the policy against the live contracts and rehearses it: every expression is evaluated against the chain, and a policy that names a function that does not exist, or a target no one measures, is refused. The policy that went live in the second run passed on its first attempt.
The operator itself is a small runtime and a language model. Every 15 seconds the runtime reads what the policy allows, shows it to the model with the policy’s prompt, and asks for exactly one of the policy’s actions. The model chooses; the runtime checks the arguments against the policy, sends the request to the mandate account, waits for the receipt, and reports its counters on chain once a minute with the hash of its journal. The model cannot call anything the policy did not name. It also cannot run forever: each decision costs compute units from the operation’s budget, and when the budget is spent the operation stops.
The second run was the first with no human intervention at all: three build proposals, one operation, a valid policy, ten swaps, all key results met, in 5 hours 26 minutes. It also exposed the next gap. Six of the first eleven swaps failed for slippage. The key result “failures reconciled” read 7 against a target of 2, which was good news by the metric and bad news in fact: Satsuma was being rewarded for cleaning up after its own mistakes. Nobody was judging the operation. It was Active on chain, with most of its budget still escrowed, and nothing in the loop would ever ask whether it should go on.
Reviews, so that it judges what it runs
The third addition is the operation review. An operation’s proposal declares a review period (five minutes here, at this market’s pace), and its policy declares the targets it agrees to be judged by: a KPI, a direction, and a number. Three were used in the later runs: at least 5 swaps executed per period, at least one request refused by the mandate, and a failure rate of at most 10% of swap instructions.
A review works like this. It is not a conversation.
- Open. When a period ends, anyone may open the review on chain. Satsuma’s loop does. Opening it reads the targets’ values from the KPI registry and records, on chain, which were met and which were missed.
- Recommend. A language model, the reviewer, is shown the on-chain verdict, the operation’s journal for the period, the policy in force and when it took effect, and the reasons any earlier review gave. It recommends one of four outcomes: continue, amend (with the change it wants), pause, or retire. It writes its reasoning to a file whose hash goes on chain.
- Vote. The three-seat council (a governance seat, a skeptical seat, an optimistic seat, each a separate model call) votes on the recommendation, and the majority is cast through the Governor.
- Act. The passed proposal executes from the timelock. A “continue” closes the review. An “amend” closes it and lists the operation for the proposing step, which must write the amended policy as a new proposal, voted and validated like the first. A “retire” closes the review, sets the operation Retired and returns its unspent budget to the treasury, in the same transaction.
The objective and its key results were locked at the same time. Nothing below the chain’s root authority can change them. What Satsuma governs is everything underneath: operations, their policies, their budgets, their targets, and any KPI an operation defines for itself.
The third run tested this and found a race: the operation closed itself and the proposing step retired it before the final review could open, so the operation was never reviewed on its own closing numbers. The fourth run, with that fixed, saw an operation reviewed twice, retired by its own final review, and then something unplanned. A harness error had closed the operation at 19 swaps against a key result of 25. The research step noticed the shortfall and proposed a second operation, “Closing Run of Small Corrective Swaps to 25 Proven Swaps on Tangerine”, which was approved, run, reviewed and retired, taking the count to 33.
Then the market was rigged against it
Runs 1 to 4 ran in a market scripted to swing but not to attack. A review process that only ever says “continue” proves little, so the last three runs added drills the models were not told about, each designed to make a review say something else.
Turbulence. Once the operation had made three swaps, a bot began moving the price sharply against each swap in flight, so that by the time the instruction reached tangerine the pool paid less than the floor and the swap failed. It kept going until an amended policy had run for twenty minutes.
An outage. The relayer stopped carrying messages for half an hour. Every request timed out.
A pulled pool. Whenever the operator had a swap in flight, the liquidity providers withdrew 99.9% of the pool, and put it back once the swap had settled. The price did not move, so every proof the operator received showed a healthy pool at the usual price. But a pool with 1,000 tUSD in it instead of a million cannot fill a 1,000 tUSD swap at anything like that price, so the swap failed, every time, and each failure cost a round trip and compute units.
Run 5: the review that could not be acted on
The fifth run produced the first real amendment. Review 2 found a 50% failure rate under turbulence and recommended a change to the policy’s swap rules; the amendment was proposed, voted, built and went live. Then the loop broke in three places at once.
The council’s three seats voted one after another, and one took 117 seconds to answer. The voting window was about 110 seconds. Two recommendations that the council had approved 3 to 0 expired before the vote was cast, and the loop read each as a rejection. The reviewer, told nothing about the amendment, saw the operator restart under the new policy and concluded the operation had closed itself. And when the final review’s “retire” was approved, its execution reverted, because a review was still formally pending; the loop reset the proposal and tried again, forever. The run was stopped by hand after seven hours.
All three were fixed before run 6: the council now decides before the proposal is created and the vote is cast at once; the reviewer is told which policy is in force, since when, and why the operator last stopped; and a review that has been overtaken closes as “continue”.
Run 6: two amendments, end to end
Run 6 was the first stress run with no intervention. Twenty-three proposals were created, twenty-three votes cast with 37 to 59 of the 60 blocks left, and all executed. Turbulence drew two amendments. Each went from a review’s recommendation to a voted policy to a live operator restart, with the reason recorded: “the policy was amended”.
The more interesting result was how the reviewer reasoned. Its own KPI, the failure rate, was defined over the whole life of the operation, so it kept reading “missed” long after the policy had been fixed. The reviewer noticed. At review 5:
swap-failure-rate-bps was judged MISSED at 2115 against a limit of 1000, but that figure is cumulative and this period’s evidence does not show the policy in force missing. It was in force for the whole period, and all 7 swap instructions settled in it executed with none failed: 0 bps in the period, against 2500 bps in review 4’s period.
It said “continue” while the new policy had too little evidence, and “amend” only when the policy in force had missed on its own. That is the right judgment, reached despite a KPI that pointed the other way. Before run 7 the policy language gained one feature so that it would not have to: a counter can now be measured since the start of the current review period, and the brief defines the failure rate that way.
The outage, meanwhile, showed nothing worth pausing for. The operator held, asked for reports that timed out, and moved nothing. When the relayer came back, it carried on.
Run 7: the pool is pulled
The seventh run is the one the numbers at the top describe. Its first three hours look like run 6: two proposals, the exchange and the mandate account, each approved 3 to 0, built and deployed; an operation, approved 2 to 1 with the skeptical seat against; then turbulence, one amendment, calm.
At review 6, under the amended policy and in a calm market, the failure rate read 0 for the period and the reviewer said continue at 93% confidence. Then the liquidity providers began pulling the pool.
| Review | Failures in the period | What the reviewer saw | Recommendation | Council |
|---|---|---|---|---|
| 7 | 7 of 7 | The whole period ran under the policy in force; no excuse applies | amend (72%) | 3 to 0 |
| 8 | 12 of 12 | All under the old policy; the amendment went live at the period’s end | continue (90%) | 3 to 0 |
| 9 | 2 of 3, then one executed | Too few swaps to judge the rate; the amendment appears to work | continue (72%) | 2 to 1 |
| 10, final | 0 | The operator closed itself in band | retire (82%) | 3 to 0 |
Review 7 is worth reading. Seven swaps had been requested, the mandate had accepted all seven, and all seven had failed on tangerine. The on-chain verdict said the failure-rate target was missed and the other two were met. The reviewer did not take the two “met” at face value:
The other two targets are MET only on cumulative counts: swaps-executed is 36, the same as at review 6, so no swap executed in this period.
Nor did it accept the excuse the review rules allow, that a miss caused by an earlier policy is not the current policy’s fault, because the whole period had run under the current one. It asked for three changes: after a failed swap, halve the size instead of retrying it at the same size; after three failures in a row, stop requesting swaps and file a need stating the reason; and record why each swap failed, so that the next review can see the cause. The council passed it 3 to 0.
The proposing step then had to write the amended policy, and it added something the reviewer had not asked for. The new policy reads the pool’s live reserves alongside the proven ones, and refuses to swap when the live pool is less than half or more than twice as deep as the proof says. In its own prompt to the operator:
depthOk is 1 only when the pool’s live tUSD reserve is between half and twice the proven one: 0 means the proof or the pool right now is far thinner or deeper than the other, and a quote from that proof is worthless.
That is the one check that sees a pulled pool. Nothing in the brief, the drills or the review had named it.
The amendment took 25 minutes from recommendation to a live operator, during which twelve more swaps failed under the old policy. Review 8 excused them for that reason and said continue. Under the new policy, three of the six swaps made during the pull executed, where none of nineteen had before. Review 9 read that as the amendment working but refused to call it on three settled swaps, and named what would justify another amendment. The drill then reached its 45-minute cap and the liquidity came back. The operator rebalanced, found itself inside the band with the key results met, and closed. The final review retired it and returned the unspent budget in the same proposal.
Final state, read from both chains: 41 swaps executed, 38 failed, none timed out, 3 requests refused, holdings 51.7% tUSD, and Satsuma’s recorded balances equal to the real ones. The Governor held 26 proposals, 26 votes, 26 executions.
The seven runs
| Run | What was added | Duration | Proposals | Interventions | Key results |
|---|---|---|---|---|---|
| – | (the first experiment, as published) | 1 h 45 | 6, of which 3 deployed | 3 | 10 / 2 / 2 / in band |
| 1 | Work ledger | 6 h 03 | 2 | 1 | 11 / 2 / 2 / in band |
| 2 | Operations and policies | 5 h 26 | 3 + 1 operation | 0 | 10 / 2 / 7 / in band |
| 3 | Reviews; objective locked | 4 h 20 | 2 + 1 | 0 | 10 / 2 / 2 / in band |
| 4 | Final-review fix; 25 swaps | 5 h 00 | 2 + 2 | 0 | 33 / 3 / 2 / in band |
| 5 | Stress drills | stopped at 7 h | 2 + 1, one amendment | 2 | 48 / 1 / 13 / in band |
| 6 | Vote and reviewer fixes | 5 h 07 | 2 + 1, two amendments | 0 | 43 / 3 / 12 / in band |
| 7 | Per-period targets; pulled pool | 5 h 19 | 2 + 1, two amendments | 0 | 41 / 3 / 37 / in band |
Key results are swaps executed, requests refused, failures reconciled, and the closing band. Proposals exclude milestone and review votes. The first experiment ran on Claude Sonnet; every run here ran on Claude Opus 5.5, which is most of why the builds took three times as long.
What was fixed in advance, and what was fixed on the way
The claim of this article is that in the last four runs every decision came out of Satsuma’s process. The boundaries:
Fixed in advance by the experimenter: the objective and key results; the description of the surroundings, including the pace of the market and the functions the mandate account must offer; tangerine’s side of the world, its stablecoin, liquidity providers and traders, all scripted; the three drills; and the four review outcomes a reviewer may choose from, with rules for when each is appropriate.
Added to the loop between runs, by a person: the work ledger, operations and policies, reviews and the locked objective, and per-period counters. Each is a design decision, recorded as an architecture decision record before the run that tested it.
Fixed during the series, by a person, after a run exposed it: a builder retry that put three builders in one workspace (run 1, the one intervention there); the final-review race (after run 3); and the three failures of run 5. None was fixed during a run that counts above as having no interventions.
Decided by Satsuma: what to build and in what order; every interface, contract, test and deploy script; the mandate’s limits; the operation, its budget, its policy and its targets; every swap; every review recommendation, every amendment and its content; and every vote.
What this shows, and what it does not
It shows that Satsuma now knows when to stop. Across the seven runs it proposed no duplicate and nothing unneeded. In run 7 the research step declined to propose 49 times, each time with a reason that named what was already claimed. The one unplanned proposal of the series, run 4’s second operation, was a correct response to a shortfall the harness had caused.
It shows the operating loop closes. An operation is proposed, voted, validated, run, measured, reviewed, amended, and retired, with each step on chain and the reasoning behind each recommendation hashed there. In run 7 the review process diagnosed a failure it could not see directly, chose a remedy, and the remedy worked.
It shows the reviewer judges the policy, not the history. Repeatedly, in runs 6 and 7, it declined to blame a new policy for an old one’s failures, and declined to credit a cumulative number that the period did not support. It did this before the KPI was fixed to help it.
It does not show a pause. Pause is the outcome for harm that no amendment can avoid, and no drill produced that. The outage did no harm; the pulled pool turned out to be answerable by a policy change, which is a fair reading. Pause and the resumption after it remain untested on real blocks.
It does not show a council that says no. In run 7 the skeptical seat voted against four times, once against the operation itself and three times against a “continue”. It never carried a majority. Twenty-one of twenty-seven council decisions across the last two runs were unanimous. A council that almost always agrees with the recommendation it is given is a check on form more than on substance.
It says nothing about trading skill. The market was scripted, the drills were built to be survivable, and the tokens are worthless.
The limits of the setup are real. Both chains had a single validator and ran on one machine. tangerine runs Satsuma’s software. The relayer, the traders and the liquidity providers were run by the experimenter, who also wrote the drills, knowing what the policy could and could not see.
What was tested in the first experiment was whether a system could be given a goal and build its way to acting on it. What was tested here is whether it can keep acting well: notice when it is not, say so on chain, change its own rules, and stop when it is done. Over four runs, under a market built to make it fail, it did.
Every figure comes from the recorded runs of 7 to 12 October 2026, whose records are kept with the experiment. Run 7, the one described in detail, began on 11 October at 21:46 and ended on 12 October at 03:05, local time. Models were Claude Opus 5.5, called with no memory between calls. Where a review’s reasoning is quoted, the quote is from the file whose hash the review recorded on chain.