AI Orchestration

Unix pipes make AI composable.

Every AI product wants to be the operating system. There already is one — on every server, and on every MacBook. It only needed something new to run.

$ cat error.log | toast "why did production crash?"
$ git diff | toast "review this patch"
$ ps aux | toast "anything suspicious?"
$ journalctl | toast "summarize the outage"
$ find . -name '*.c' | toast "which files deserve attention?"

One model is useful. Several models working together are better.

$ for p in Security Performance Style; do
      $p pull-request.md "review this"
  done | toast integrate
security     the new endpoint trusts X-Forwarded-For for rate limiting.
performance  N+1 on session.tokens — 200 queries on a warm cache.
style        three helpers parse the same date three ways.

Ship after the header trust is fixed. The other two can follow.

One input. Three specialists. One answer. No framework. No graph to declare. Just pipes.

The specialists are symlinks — toast --add Security and so on. Hand toast a filename and it reads it; the remaining words are the prompt. The loop's stdout is the integrator's stdin. No redirects, no bashisms: this runs in dash. And these are three different training distributions, not three runs of the same weights — personas span providers, so the reviewers do not share blind spots. That is the reliability argument, and it is why the integrator has anything to integrate.

Loops let AI iterate.

Good work is rarely done in one pass. Agent frameworks added cycles to their graphs for exactly this. A cycle is a while loop with a diagram around it.

🍞 while toast server.c "improve until production ready"

[toast] pass 1 · bounds check on parse_header · build ok · tests ok
[toast] pass 2 · replaced strcpy · build ok · tests ok
    ... 14 more ...
DONE

Each iteration:

• reads the current code
• finds one improvement
• makes the change
• builds
• tests
• records why
• updates its notes

Eventually it prints DONE and exits nonzero. jam stops. Not because the loop counted to ten. Because the work is finished.

That is jam, not sh — while <command> takes no do and no done, and repeats until the command exits nonzero. 20 while <command> caps it at twenty passes if you would rather not find out the hard way.

Files are memory.

You don't need another database.

Everything is text. Version it. Search it. Review it. Delete it. The model forgets. Your filesystem doesn't.

Text is not the point. It is the cheapest thing that keeps the point, which is that you can look. A vector store, a context window, a state blob inside a runtime — each of those is memory you cannot read, and memory you cannot read is memory you cannot correct.

Unix was already multi-agent.

Unix is what evolved when people had to share one computer. Isolated processes. Permissions. Pipes. A filesystem they all could see. The agents were people. Nothing about it had to change for AI.

A company is made of people who are wrong quite often. It gets dependable work out of them anyway. Review. A record of why. The ability to undo. None of that requires anyone to be reliable.

Those same three things are the whole design here. Several models that fail in different places, so an error has to survive more than one of them. ito recording why a change was made, not just what changed. And undo, which is the only reason letting a pass run unattended is a sane thing to do. Reliability is a property of the arrangement, not of the parts — which is exactly how it has always worked with people.

It also declined to say what data means. stdin, stdout, and one byte of exit status. No types. No schema. No registry of what a program is. Every system since has added structure. Every structure became a wall.

That refusal is why something invented fifty-five years later needed no kernel change: a model emits text, and text was already the interface. The exit byte is why a non-deterministic process can sit inside deterministic control flow — toast prints DONE and exits nonzero, jam stops. Frameworks rebuild that as a conditional edge because they gave up the process boundary that handed it to them. And files as memory is not our idea either; it is inherited, because Unix made everything a path.

Unix already solved orchestration.

No orchestration framework required. The jam shell orchestrates. Pipes branch. Exit codes choose. Loops retry. Files remember. cron schedules. ssh distributes. Intelligent processes reason.

There is one habit underneath all of that, and it is the reason any of it works: Unix stores information once and derives the rest. A pipe moves state rather than copying it. An exit code is one byte the parent was already waiting for, not a status object somebody maintains. A process tree is not kept by anyone — it is what forking leaves behind. So none of the lines above is a feature we added, and the rule that falls out of them is the one worth keeping: do not hand-maintain information the runtime already produces. Policy still has to be written — the allowlist, the stopping condition, what counts as done. Those are yours, in a file you can read. Everything else was already on the machine.

They compose.

Small commands become systems.

Graphs are just control flow you can serialize. Learn a framework and you learn nouns that live in one repo. You keep learning Unix.

How far up this ladder you should climb is a different question — one tool, six levels: the six levels of using AI.

Unix is learnable one command at a time.

A framework wants the whole ontology before you can do anything. Unix wants one command.

Each is useful the day you learn it. None is invalidated by the next. There is no version 2 that deletes what you know.

It is discoverable: man, --help, a filesystem you can read. You learn it while using it, not before. And every model already knows it.

Every model was trained on fifty years of man pages, shell scripts and arguments about them. Ask one for a pipeline and you get a pipeline that runs. Ask it for a framework's API — shipped eighteen months ago, thin on the ground — and you get methods that never existed. Unix is the highest-confidence knowledge in the machine, which is why the machine can work in it without being taught.

And toast will teach you the rest. Ask what a flag does, ask why a pipeline broke, ask for the loop whose syntax you can never remember. The tutor lives in the pipe, so you learn the system while you are using it — at whichever of the six levels you happen to be working on.

The architecture is boring.

None of which is elegant. Signals are bad, terminal handling is worse, and sh quoting is most of the reason jam exists. But it is documented: someone hit this in 2009 and wrote it down. Stable and documented is a different property from well designed, and it is the rarer one.

Local and cloud, in one pipeline.

$ toasted
$ cat auth.py | toast "draft a fix" | toast -p openai "what did that miss?"
The patch takes a lock, but the old token still validates for 30
seconds after rotation. Gate on the token version, not the clock.

The first stage went local on its own, because toasted was running. The second saw four lines, cost a fraction of a cent, and was trained by someone else — which is why it could see what the first one missed. Neither one knows the other exists.

toast prefers whatever is already running — appled, then toasted, then us — and -p overrides it. The default is the cheapest thing on the machine, and you opt into spending one stage at a time. Most steps in a workflow do not need a frontier model: filtering, extracting, summarising, first drafts. Run those on the laptop. Ours sits close to the frontier and runs on Cerebras, so take it for the steps where waiting is the problem — it answers faster than you can read the prompt back. And when latency is not what you are buying, BYOK reaches any model you already pay for, the biggest ones included. A framework needs a provider abstraction because every step runs inside one process. A pipeline does not — each stage is its own process, and the pipe is the only interface they share.

Switch providers without changing your workflow. Interchangeable at the interface. Not interchangeable in what they get wrong. That second part is the whole reason to cross them.

A model reviewing its own output shares its own blind spots — same corpus, same tuning, same failure modes — so it agrees with itself, confidently. Two training distributions do not fail in the same places, and an error that survives both is rarer than one that survives either. That is what makes the second stage of a pipeline worth running at all. -p and -m are not convenience flags; they are the reliability primitive, and BYOK exists so you can reach a model that is genuinely not ours.

BYOK · no credits OpenAI, Anthropic, Google, Mistral, Groq, Cerebras, Perplexity, xAI, OpenRouter, Together

Local · no credits appled, toasted, Ollama, MLX, LM Studio, llama.cpp, vLLM, LocalAI, Jan

Peers · credits other people's idle Apple Silicon, priced in credits — toast -p peers

Several machines beat one.

One box holds one model. A room holds as many as you own.

# once per machine
$ squawkd &

# on the Mini
$ USER=Paranoid squawk bot Paranoid
# on the Studio
$ USER=Security squawk bot Security

# from the laptop, same LAN
$ squawk
dirk> auth.py rotates tokens inside a 30 second window. anything wrong?
Paranoid> two requests in that window both mint a token. the second wins,
Paranoid> and the first client retries with one that no longer validates.
Security> that window is also long enough to replay a stolen token once.

No broker. No service discovery. No registry. A multicast group and a socket.

squawkd joins 239.255.76.84 on the LAN, so the machines find each other without being told about each other. Off the LAN, squawk tunnels over ssh — nothing listens on an inbound port. Each box runs whatever model it can hold, so a room of Minis answers with several at once. That is the opposite of the Thunderbolt cluster under Business: that one makes a single model larger than any one box, this one puts many models in the same conversation.

ito gives you undo.

Every command. Every improvement. Every reason.

$ ito log "hardened parse_header — unbounded copy on malformed input"
logged 9c4f1a2  hardened parse_header — unbounded copy on malformed input
✓ saved — you can always get back to this

# AUTHOR names who did it — a person, a persona, or a cron job
$ ito history
4a91c07  2026-07-21T09:14:22Z  (dirk)
         switched sessions to JWT so the mobile client can go offline

e2b8f30  2026-07-24T16:02:41Z  (Editor)
         cut chapter 4 — the ledger reveal lands better in 7

9c4f1a2  2026-07-27T11:38:05Z  (dirk)
         hardened parse_header — unbounded copy on malformed input

$ ito undo
undone  9c4f1a2  "hardened parse_header — unbounded copy on malformed input"
✓ your files are back — nothing is ever deleted
back to e2b8f30  "cut chapter 4 — the ledger reveal lands better in 7"

$ ito search jwt
4a91c07  2026-07-21T09:14:22Z  (dirk)
         switched sessions to JWT so the mobile client can go offline

$ ito history | toast "what did we actually change this week"

Read what happened. Search by why, not what. Restore any moment. Machines should be able to explain themselves.

The future is composable.

Not one giant model. Lots of small programs.

Each does one thing well. Exactly like Unix.