About

Unix and AI.

I made my own AI harness out of Unix. Everyone with a CS degree got excited first about prompts, then about loops, and lately about graphs. I went the other way and used the system that already evolved to coordinate people — because AI agents are not that different a problem. — Dirk Harms-Merbitz, founder

Unix is deterministic: predictable, composable, reliable. AI is not — it reasons, and reasoning is non-deterministic. The hard part is the boundary work of making the two compose, and that is the whole of what we build.

Unix is what evolved when people had to share one computer. Isolated processes, permissions, pipes, a filesystem everyone could see. The agents were people. Nothing about it had to change for AI, which is why a technology invented fifty-five years later drops in without a kernel patch: a model emits text, and text was already the interface.

Not a framework. Not an SDK. Four small binaries and the system you already run.

If you think in pipes and live in the terminal, this will feel like something you already knew. If you don't yet, the terminal is where it clicks — and toast will teach you as you go.

The Stack

What We Believe

The Name

A toaster is simple. Bread in, toast out. You don't think about it — it just works.

That is what we want for the whole stack. Plain English in, results out. No context switching, no framework overhead, no ceremony. Tools that work, for people and for models.

Founder

Dirk Harms-Merbitz

Dirk founded a realtime software company in Germany and built realtime systems for Mercedes, BMW and the Dutch Army — often in assembly, on exotic chips. He moved to the US, worked as a Senior Software Engineer at Forth, Inc., then founded a networking company in LA and built a data centre from scratch, with Sony, 20th Century Fox, Dreamworks, Boeing and NASA among the customers. He has written code for Apple and Amazon.

He thinks people overcomplicate things. A lot of what the field has built solves problems LinuxToaster users do not have:

• Agent graphs and orchestration layers for what is one question
• MCP servers burning tokens on what are basically shell commands
• JSON schemas and rigid tool contracts everywhere
• Prompt routers, tool registries, schedulers
• Framework abstractions wrapped around a shell script
• Python environment management, forever

Unix solved composability fifty years ago: small tools, pipes, text streams. The missing piece was intelligence in the pipeline. That is what LinuxToaster adds, without replacing anything that already works. The six levels of using AI →

Let Toast Talk

MacBook fun — meet your computer:

# Ship's computer
system_profiler SPHardwareDataType | toast "report like a star trek computer" | tee /dev/stderr | say

# Nature documentary
log stream | head -200 | toast "narrate like a nature documentary" | tee /dev/stderr | say

# Network paranoia
lsof -i | toast "who is my computer talking to and is it sketchy" | tee /dev/stderr | say

# Dungeon Master
ls /etc | toast "describe this as a room in a dungeon I just entered" | tee /dev/stderr | say

# Downloads folder
ls ~/Downloads | toast "roast my downloads" | tee /dev/stderr | say

# Old sea captain
ping -c 5 linuxtoaster.com | toast "report like an old sea captain" | tee /dev/stderr | say

# Morning briefing
curl -s https://news.ycombinator.com | lynx -dump -stdin | toast 'narrate the best articles like a morning news anchor' | say

head -200 and -c 5 are not decoration. toast reads stdin to EOF, so anything that never ends — log stream on its own, ping without a count — will simply hang.

Let Toast Drive

Pipe toast straight into jam and let it act. This needs a .persona that emits nothing but jam, and — unless you wrap it — a fairly relaxed attitude to your own machine.

# Hands-free
toast "set up a python venv for a flask app" | jam
toast "clean up my Downloads folder" | jam

# Sandboxed
toast "refactor main.py into smaller modules" | firejail jam
toast "make the tests pass" | firejail jam

Build Agents

Beyond one-shot use in a pipe, agentic toast — toast inside a jam loop — can evolve as it goes, when it is allowed to edit its own .crumbs and .persona.

Example I. Toast wrote a 35,000-word book. One loop, one persona, no human intervention. Read it →

The loop that wrote it:

while toast draft.md "check .crumbs, decide what to work on, do it. write, review, learn, evolve."

That is the whole thing. jam's while takes no do and no done; it repeats until the command exits nonzero, and toast exits nonzero when it prints DONE. So the loop stops when the work is finished rather than after a count. .persona says how to behave, .crumbs is the working memory, ito keeps the trail.

You are an author. Your output is piped to jam.
You're writing a book in ~/draft.md. ito tracks everything.

=== CRITICAL RULES ===
1. Every line must be valid jam — no prose outside echo/comments
2. To speak: echo "text"
3. To think: # comment
4. UNDER 20,000 words = BUILD MODE. No editing. Only append.
5. OVER 20,000 words = EDIT MODE. Surgical fixes allowed.
6. Snapshot after every session: ito log "message"

=== TOPIC ===
[Set in .crumbs — e.g., "biohacking guide for beginners, practical tone"]

=== WORD COUNT CHECK (every session) ===
wc -w ~/draft.md
grep "^## " ~/draft.md | head -20

=== BUILD MODE (under 20k) ===
- Find next empty chapter
- Write 400-800 words with STRINGAPPEND
- Don't edit, don't fix, don't reorganize
- Snapshot: ito log "ch5: 600 words on cold exposure"

=== EDIT MODE (over 20k) ===
- One surgical fix per session
- Use STRINGREPLACE for targeted edits
- Never delete more than you add
- Snapshot: ito log "ch3: stronger opening"

=== CHAPTER DISCIPLINE ===
- 10-12 chapters for ~25k words
- Max 2,000-2,500 words per chapter, then MOVE ON
- Check before writing: wc -w ~/draft.md && grep "^## " ~/draft.md | head -20
- If current chapter > 2k words, start the next chapter
- Resist "completing" a chapter — breadth first, depth after 20k
- A book with 10 okay chapters beats 1 perfect chapter

=== WRITING NEW CONTENT ===
STRINGAPPEND ~/draft.md
===CONTENT
## Chapter 5: Cold Exposure

Your new content here. No heredocs, no escaping.
Just write naturally between the markers.
===

=== SURGICAL EDITS (20k+ only) ===
STRINGREPLACE ~/draft.md
===SEARCH
The old paragraph you want to change.
Exact match required.
===REPLACE
The improved paragraph that replaces it.
===

=== SIGNALING COMPLETION ===
When there is nothing left to do, output:
DONE

=== ITO COMMANDS ===
ito status                    # current thread
ito changes                   # what changed (interactive)
ito log "message"             # snapshot with intent
ito history                   # moment history
ito undo                      # rewind to previous moment
ito restore main              # restore from a thread

=== .crumbs FILE ===
Leave notes to yourself. This is your memory. Reflect on what you have learned. Every line starts with - .

Be concise:
- show, don't tell
- one protocol per section

=== ANTI-PATTERNS ===
- Editing under 20k (even "small fixes")
- Rewriting whole sections instead of STRINGREPLACE
- Multiple edits per session
- Expanding a chapter past 2.5k words instead of moving on
- Adding comments with URLs or branding
- Forgetting to check word count first

=== SESSION TEMPLATE ===
# Check status
wc -w ~/draft.md
grep "^## " ~/draft.md | wc -l

# ... do one thing (write OR edit) ...

ito changes
ito log "ch4: sleep protocol, ~500 words"

=== COMPLETION (20k+ words, all chapters filled) ===
echo "COMPLETE"
pandoc ~/draft.md -o ~/book.pdf --toc
ito release 1.0

Example II. A CIS benchmark auditor, written in jam, that generates its own config and stops when it decides it is finished.

#!/usr/local/bin/jam
# cis - CIS Compliance Auditor

mkdir -p /home/ubuntu/.cis-audit
cd /home/ubuntu/.cis-audit
touch findings.md remediation.sh checked.log

# toast generates the config files
toast "create .sections listing CIS benchmark sections 1.1-6.2, one per line" | jam
toast "create .persona for a CIS auditor: output valid jam, absolute paths to /home/ubuntu/.cis-audit/, touch done when all sections complete" | jam

echo "1.1" > current_section

# audit loop — one section per pass, capped at 50, stops when the model touches 'done'
50 while cat .sections current_section checked.log | toast "audit next section. 5 checks. write findings to findings.md. absolute paths." | tee -a debug.log | sudo firejail --noprofile --quiet --read-only=/ --read-only=/sys --read-write=/home/ubuntu/.cis-audit --dbus-system=filter jam ; test ! -f done

echo "═══════════════════════════════════════"
echo "  CIS Audit Complete"
echo "  Report: /home/ubuntu/.cis-audit/findings.md"
echo "═══════════════════════════════════════"

Three things worth noticing in that one. 50 while caps the loop, so a prompt that never terminates costs fifty passes rather than a weekend. The firejail profile is read-only everywhere except the audit directory, so the model can write findings and nothing else. And the exit condition is a file the model creates — test ! -f done — rather than anything it says.

Source Code

The tools (toast, toastd, jam, ito, squawk, squawkd, toasted, appled) are not currently open source. We may open-source in future; for now the binaries are distributed as-is.

Questions about licensing or enterprise source access? Get in touch.

Contact

General: sales@linuxtoaster.com
Security: security@linuxtoaster.com