The problem it solves
Sending transactions is the easy part. Knowing where to send them is the hard part. A strategy that reads as one sentence is a dozen decisions in practice: which network has the rate today, which crossing to use and what it costs, which market has room, what to approve, and in what order any of it can happen without stranding money halfway. Here you name the outcome, and the route is worked out for you.What happens when you press Run
Your words pass through six stages before anything reaches a network. Each stage narrows what is possible, and each one can refuse.
A refusal at any stage is recorded as carefully as an approval.
Why it keeps going after you close the tab
Some steps settle in seconds and some do not. A price you are waiting for might arrive next week. A network crossing can take a few minutes of waiting. A transaction can sit unsent and need resending at a higher fee. So a run cannot be a request that simply returns an answer. It has to survive you closing the tab, and survive a restart nine steps into a fourteen-step plan. A program holding the plan in its memory would lose it at the first of those. Every step is written down as it happens, and a run is rebuilt from that record rather than remembered.Survives a restart
The record of what has already happened, the protection against doing a step
twice, and the history of every run. These live in a database, not in the
memory of a running process.
When a run stops
Step 1 lands, step 2 fails, somebody proposes a change, steps 2 and 3 run. That is a normal outcome. It retries very little on purpose: a fee bump for a stuck transaction, and a couple of attempts where the cause can clear on its own. Past that it stops and waits for you, because most real problems need a decision rather than another identical attempt.Editing a workflow that has already moved money
An amendment can change steps that have not run yet, and never ones that have. Every step that already ran must reappear unchanged, in order. Altering or dropping one is refused, and so is resending a failed step without changing it. Two details that prevent surprises when you approve an edit:- Steps have names, not positions. If they were numbered by position, inserting one would silently repoint everything after it.
- Amounts that follow another step use what actually arrived. Step 1 asked for 1000 and delivered 997, so step 2 gets 997. The summary tells you which steps a person edited and which simply followed.
Who proposed an amendment is recorded so you can see it afterwards, not to decide
whether to allow it. An owner can be tricked and a model can be manipulated, so
the checks are identical either way.
Where the boundaries are, and where they are not yet
Two protections hold today, on every path that moves money.- The fee payer builds the transaction from separate named fields and is never handed a ready-made instruction. There is no input to that function capable of expressing “call this address with this payload”.
- The agent’s approval is checked on the network itself, not in our code. The fee payer is the sender of the outer envelope only, never the holder of your assets.
Under the hood
This section is for people integrating or evaluating the system. You do not need it to use the product.What runs, and what each part holds
Around those sit the console, the tool server the agent talks to, a quoting
service, and the engine holding each run’s history. One more runs each
transaction on a copy of the network before it is sent, on every network except
HyperEVM. How transactions are sent says what it checks.
One container is reachable from outside. Everything else answers only on the
internal network.
The services are built from one image, with a variable choosing which one runs,
so they share every compiled constant. That is why they are deployed together.
Two of them on different builds work out account addresses two different ways,
and every batch is then refused.