Everything Is a Stream: runtime composability over compile-time plugins
Unix's most famous design slogan is "everything is a file."
It's the wrong emphasis. A file at rest is just named bytes sitting on a disk; nothing composes. What made Unix profoundly powerful is that every file descriptor is something you read from and write to in order — and that stdin, stdout, and the pipe let any program's output feed any other program's input. grep is a filter. sed and awk are maps. sort | uniq -c is an aggregate. wc is a reduce.
The shell pipeline was a stream-processing framework half a century before we coined the term.
"Everything is a file" was always really: everything is a stream.
The Litany
Once you see it, you can't unsee it. Name almost any foundational concept in computing, and the answer comes back the same:
- The Turing machine — the archetype of computation itself, a movable head reading and writing along a linear tape? Stream.
- git — a repository state built out of commits? An append-only directed acyclic graph of snapshots, with your working tree as a transient projection. Stream.
- TCP — it says so right on the label. Stream.
- Databases — the write-ahead log (WAL) is the truth; the tables, materialized views, and indexes are mere projections. Stream.
- Compilers — the very first thing a compiler does to your code is lex it into a literal token stream. Stream.
- The LLM itself — an attention head crawling along a context window, reading tokens and appending tokens? The most sophisticated computational artifact humanity has built is, at its core, a stream transducer. Stream.
- Even you, asleep — the brain replaying the day's event log to consolidate memory and decide what to keep? We gave that playback a softer name: a dream. Stream.
A stream is also what a protocol is. Strip any durable protocol to its skeleton — HTTP, the git wire protocol, an Erlang mailbox — and you find the exact same primitive: an ordered flow of messages between parties that share nothing except the grammar of the flow. No shared address space, no shared language runtime, no synchronized deployment schedule.
That is why protocol seams age so well: either side can be rewritten, rehosted, or replaced independently, as long as the stream keeps its shape.
Everything Is a Plugin — Except for the Plugged
Recently, DeepSeek shipped dsh under a striking tagline: everything is a plugin. Models, tools, sessions, storage, UI elements — even the agent loop itself — swappable. pi has followed a similar conviction: a minimal core, rich TypeScript extensions, every installation bespoke.
For the surfaces users see and touch, this philosophy is undeniably right. The lineage backs it up: Emacs, Vim, VS Code. Malleability wins at the edge, and it will win even harder now that coding agents can write their own extensions on the fly.
Yet taken to its logical conclusion, "everything is a plugin" carries its own critical fine print.
A plugin architecture requires one thing that cannot be a plugin: the socket being plugged into. However far the tagline is pushed, something underneath still decides what a plugin is, when it loads, what resources it can touch, and how state transitions occur. There is always a plugged.
In an autonomous coding agent, the plugged is the agent core — the layer with the longest, most expensive verification loop in modern software.
If you reskin a terminal UI or tweak an editor theme, you know in half a second whether it's better. You are the oracle, and your feedback is instant and cheap.
Cheap & Immediate Feedback
(You are the Oracle)
│
┌────────────────────────────▼───────────────────────────┐
│ MALLEABLE SURFACE (UI / PLUGINS) │
│ Custom TUI • Zed/VSCode • Slack/Discord Bots │
└────────────────────────────┬───────────────────────────┘
│ ◄── WIRE PROTOCOL SEAM
│ (Operations & Events)
┌────────────────────────────▼───────────────────────────┐
│ THE PLUGGED (AGENT CORE ENGINE) │
│ Context Management • Tool Dispatch • Inference │
└────────────────────────────▲───────────────────────────┘
│
Expensive Eval Sweeps
(Billions of Verified Tokens)
But change the agent loop, the context-compaction policy, the subagent scheduler, or the tool-dispatch heuristics, and nobody can eyeball whether the agent just got 3% worse at complex multi-file refactors. The only reliable oracle is an exhaustive evaluation sweep across multiple frontier models, benchmark suites, and random seeds to drown out the noise — burning billions of tokens to verify a single architectural shift.
AI collapsed the cost of writing code; it did not touch the cost of verifying it.
A plugin surface directly over the agent core buys the wrong trade-off: thousands of cheap, unverified variants of the most mission-critical code in the system, coupled with leaky interface promises that freeze the core right where it most needs to evolve.
Slow and stable isn't the core's weakness; it is its defining feature. Plugin the surface. Protect the plugged.
And extend the plugged not by injecting arbitrary foreign code into its memory space, but by speaking to it over a clean, typed stream.
The Foundation: Introducing ante serve
With Ante v0.2.0, we are stabilizing Ante's wire protocol and establishing our official SemVer guarantees.
Ante completely decouples the agent engine from its presentation layer through typed message passing:
- Operations go in: starting sessions, submitting prompts, answering tool approvals, and sending non-blocking interrupts.
- Events come out: streaming token deltas, reasoning traces, tool start and completion notifications, diff previews, and approval requests.
The terminal interface you see when running ante is not the engine itself — it is simply one client implementation consuming this event stream.
Through ante serve, that engine runs as a standalone, long-lived daemon across three standard transports:
- Stdio (
--stdio): The default 1:1 transport. When an editor or custom CLI spawns Ante, it communicates over standard input/output with newline-delimited JSON (JSONL). Closingstdingracefully shuts down the engine. - Unix Domain Sockets (
--sock): Designed for local multi-client setups. A singleante servebackground process listens on a local socket, serving multiple concurrent, isolated agent sessions. - Authenticated WebSockets (
--ws): Multi-peer networking over loopback or secure reverse proxies (wss://), authenticated via bearer tokens.
Because control operations are handled independently from event emission, high-priority commands (like interrupting a run or shutting down) never stall behind large streaming token flushes.
To support developers building against this protocol, we have published four core crates on crates.io: ante-protocol-shape (wire types and schemas), ante-sdk (async client library), ante-llm (streaming provider layer), and ante-exec (sandboxed execution primitives).
Three Proof Points: What You Can Build Today
To show what becomes possible when the agent engine is protected behind a stream, we built and open-sourced three distinct integration patterns:
1. Build Your Own Coding Agent Harness
Want a bespoke terminal assistant or a specialized CLI tailored to your team's workflow? You don't have to build an LLM harness, streaming parser, or execution sandbox from scratch.
To prove it, we built mini-tui: a complete, interactive chat terminal written in about 220 lines of Rust on top of ante-sdk. It connects to Ante over stdio, streams tokens and thoughts in real time, displays running tools, prompts the user interactively (y/n) whenever Ante requests tool approval, and forwards Esc as an immediate interrupt. The entire implementation is smaller than most configuration files because the hard work of agent execution lives safely on the other side of the stream.
2. Integrate with Your IDE or Workflow Orchestrator
Modern editors are coalescing around open standards like the Agent Client Protocol (ACP). To bring Ante into editors like Zed and JetBrains, we didn't touch a single line of Ante's core engine.
Instead, we built ante-acp: a lightweight protocol bridge. It accepts ACP calls from the editor, drives an ante serve child process underneath, forwards editor context (@-mentions, selections) into Ante turns, renders tool diffs directly into native editor views, and translates Ante's approval pauses into native IDE permission dialogs. Because Ante speaks a structured protocol, adapting it to an industry standard is a straightforward translation layer, not an architectural rewrite.
3. Build Your Own Claude for Your Team (Slack & Discord)
What if you want an autonomous coding assistant for your entire engineering team inside team chat without sending internal discussions to proprietary third-party SaaS wrappers?
We built ante-gateway to run Ante as a persistent bot inside Slack and Discord. Backed by a shared ante serve daemon, it maps each channel thread or direct message to its own isolated agent session — meaning dozens of engineers can collaborate with Ante simultaneously without crossing conversation state or file workspaces. When Ante needs to run a command or edit code, it asks for permission directly in the chat thread; team members approve with a quick reply, and fine-grained workspace allowlists keep access secure.
Streams at the Seams
Ante's architecture is a bet on where different software traditions belong:
- Plugins at the surface: Where humans look, tweak, and customize.
- Streams at the seams: Where independent systems, editors, and processes converse.
- Files at rest: Where artifacts, code, and configurations endure.
By stabilizing ante serve and the wire protocol in v0.2.0, we are offering developers a clean contract: let Ante handle the hard, eval-verified engine work of tool calling, model abstraction, context compaction, and execution safety. Build your own interfaces, IDE plugins, and automation pipelines around the stream.
Explore the code, read the protocol specification, and start building:
- 🌐 GitHub: github.com/AntigmaLabs/ante
- 📖 Protocol Documentation: docs.antigma.ai/reference/protocol-reference/
- 📦 crates.io:
ante-protocol-shape·ante-sdk·ante-llm·ante-exec - 💡 Examples:
mini-tui·ante-acp·ante-gateway
Pipe it forward.