Why Millstream
Most of the automation a team builds around LLMs has the same shape: a chain of steps where each one's output is the next one's input. Some steps are plain code, some are agents, and some need a person to approve. Millstream exists because that shape deserves a runtime of its own.
Agent systems have moved from best-effort chains of prompts toward engineered reliability: output validated before it is used, plans kept apart from execution, every step recorded, and improvements drawn from what was recorded. Millstream builds those practices into the runtime, so every pipeline starts with them.
The same plumbing, every time
A team that ships its first agent workflow writes a script. The second one adds retries, a queue, a table of what was processed and a way to resume after a crash. By the third, it has a scheduler, a cost spreadsheet, a Slack channel where people approve things, and logs nobody can search. None of it carries over to the next project, and nobody can answer a simple question without reading those logs:
How many items did we score yesterday, what did it cost, which ones failed, and how often did someone have to correct the agent?
Millstream answers that question for every pipeline, from its first run.
What existing tools leave to you
Durable execution engines make a function survive failures, but they think in workflows of code, not in streams of items flowing through agents and people. Data orchestrators schedule batch tasks, mostly in Python. Low-code tools draw nice graphs but keep your code and your history at arm's length. Agent frameworks orchestrate inside one agent, and stop at its edge.
None of them treats an LLM call as a step with a schema, a sandbox, a budget, a transcript and an eval, a review as a step with an inbox and a measured intervention rate, or production history as the input for the next improvement. The comparisons go through each in detail, including where each one is the better fit.
What Millstream is
- A standard way to define pipelines: a declarative file of triggers, streams and steps, validated before it runs.
- A standard action contract: any program that speaks a small JSON-lines protocol is an action, in any language, and agents are actions like any other.
- A durable, observable runtime: every item persisted, every change an event, and metrics, lineage and a live view for free.
- One engine from laptop to server: SQLite on a laptop, Postgres with a hot standby and remote nodes on a server, the same package on both.
- Pipelines that learn: insights from production, proposals validated in development, accepted by a person.
The principles behind it
Durable by construction
- A persisted item log is the only state
- Deterministic, immutable items
- Outputs publish only when a delivery is done
- Crash-tested at every unit boundary
Declarative, in git
- The pipeline file is the source of truth
- Revisions by content hash, runs pinned to theirs
- Thresholds visible in
filtersteps - No graphical editor to drift from the code
Agents under control
- Schemas on every answer
- Sandboxes, allowlists and budgets
- Transcripts and record-and-replay
- Output treated as untrusted data
People in the loop, measured
- Reviews are steps, with inboxes and reason codes
- Rules approve, samples keep them honest
- The intervention rate as the headline figure
- Every decision becomes evidence
Learn in production, change in development
- Insights computed from the log, with no LLM
- Evidence redacted and expiring
- Proposals backtested before anyone reads them
- Nothing ships without a person and a diff
Yours to run
- One deployment per customer, on their infrastructure
- One Go binary, a Compose file, systemd units
- An open protocol any language can implement
- An Apache-2.0 core with the whole UI
Built for teams that deliver
Millstream comes from forward-deployed engineering: building automation for a customer, on the customer's infrastructure, and handing it over in a state someone else can run. That is why a deployment belongs to one customer, why the pipeline file reads like a contract, why the UI explains itself to an operator who never saw the code, and why the platform measures, in figures a customer understands, whether the work is getting cheaper and better.