AI is a first-class step
A pinned prompt version, an output schema and a cost budget. The engine enforces all three.
In design · open source · spec published
Everything flows.
Nothing passes unmeasured.
Weir is the workflow engine built for AI. Five kinds of step, one contract, budgets that are enforced and a full record of every attempt. It runs on Postgres and scales to zero.
- 5 step kinds
- 1 contract
- 0 always-on servers
Why it exists
Agents are easy to start and hard to trust.
Most workflow engines were built for code calling code. An agent is something else: it costs money every time it runs, it can be talked into things, and its output has to be checked.
Weir treats that as the normal case. A prompt is pinned. An output is validated. A budget is a limit, not a report. A person signs off where it matters, and the record shows who and why.
Five kinds of step
Every kind of work, under one contract.
A step is done by a classifier, an agent, your code, a person or another system. All five share the same inputs, outputs, retries, timeouts and audit record, so the trail does not depend on who did the work.
Runs now
An agent with a pinned prompt, a short list of tools, a typed result and a hard budget.
You declare
- A pinned prompt version
- The tools it may call
- An output schema
- A budget
Weir guarantees
- Output that fails the schema is rejected.
- The run stops when the budget is spent.
- The full transcript is stored with the attempt.
- id: fix
kind: ai
prompt: fix-incident@7 # pinned, immutable
tools:
read: [scm.read_file, scm.search]
write: [scm.create_branch] # writes are listed by name
output: { schema: schemas/change.json }
budget: { usd: 15.00, minutes: 45 }
on_failure: block
Two mechanisms, five kinds. Decide, AI and deterministic steps run now: a worker claims the step and returns a result. Human and external steps wait: the step is parked, costing nothing, until someone returns its token.
Spend fewer tokens
A model call is the last resort.
Work goes to the cheapest tier that can do it. A larger model is used only when a smaller one cannot decide. This is built into the contract, so the cheap path is the default path.
- 1
Rule
Code. No model, no tokens.
The answer can be computed.
- 2
Classifier
A small model returns one label.
The answer is one of a few known labels.
- 3
Small agent
An agent on a small model with a lean context.
The work is simple, like replying to "thanks".
- 4
Large agent
An agent on a large model, with tools.
The work needs judgement or several steps.
The AI gateway
Every model call passes through one gateway. It picks a small or large model for each input, meters tokens against the attempt, refuses calls that would break the budget, and falls back when a provider fails.
The trigger ladder
Inbound events meet a rule first, which costs nothing. A classifier sees only what the rule lets through. A run starts only for what the classifier says is worth it.
Shadow mode
Record what the router would have chosen while the usual model still runs. Compare quality and latency by label before you switch it on.
What makes it different
Eleven reasons to use it.
One contract, five kinds of work
Decide, AI, deterministic, human and external steps share inputs, outputs, retries, timeouts and audit.
Governance that is enforced
Budgets stop runs. Schemas reject outputs. Nobody approves their own request.
Evidence for every attempt
Prompt, transcript, tool calls, output, actor, cost and decision, on a log that cannot be rewritten.
The cheapest tier goes first
Rules before classifiers, classifiers before agents. A large model is the last resort.
Workflows are data
Versioned YAML, immutable once published. A new workflow needs no change to the engine.
Callbacks in both directions
Third parties resume a parked step with a token. Weir notifies them through signed hooks.
Postgres only. Scales to zero
No cluster, no broker, no always-on server. When nothing is running, you pay for the database.
The detector decides "done"
A fix counts only when the system that raised the problem confirms it has gone.
A governed tool marketplace
Add any MCP server. Agents reach tools only through Weir, with an allow-list on every step.
Pipes plumb any system in
One installable unit per system: its connection, its events, its notifications and its tools.
Pipes
Plumb it in wherever you need a workflow.
A Pipe connects one outside system to Weir. Install it once and use its parts in any workflow. Swap the Pipe behind a name and the same workflow runs against a different provider.
- Source control
- Error tracking
- Cloud accounts
- Scanners
- Chat
- Ticketing
weir
- Connection Both ways
- The address and how to authenticate. Credentials stay out of your workflows.
- Inlets In
- Events that start a run or resume a parked step.
- Outlets Out
- Notifications and calls Weir makes to the system.
- Tools Out
- Actions an agent may call, each classed as a read or a write.
- Handlers Out
- Actions your deterministic steps may call.
pipe: scm-github
version: 2.1.0
connection:
auth: oauth
sites: [api.github.com]
inlets:
- issue_opened
- pull_request_merged
tools:
read: [read_file, search]
write: [create_branch]
handlers:
- open_issue
- merge
A Pipe is not a pipeline. A Pipe connects a system; a workflow is what runs.
Governance
Enforced by the engine, not left to good intentions.
A workflow author cannot switch these off, and a worker cannot bypass them.
Prompts are pinned
Versions are immutable. Each attempt stores a hash of the prompt it actually ran.
Outputs are checked
Every AI output is validated against its schema before the run moves on.
Budgets stop work
Spend is counted per attempt, step and run. Hitting the limit ends it.
Duties are separated
The engine checks who the actor is. The requester cannot be the approver.
Agents never hold credentials
Weir makes every tool call on the agent's behalf, after the allow-list check.
Tool lists are pinned
If a server changes its tools after approval, its writes pause until someone reviews.
Decisions fail safe
An unsure or unavailable classifier returns the default you declared.
The log cannot be rewritten
Events are append-only, enforced in the database.
When things go wrong
Built for the bad day.
A failure policy on every step
Say what happens next when a step fails for good.
- block: stop here and resume later
- cancel: end the run and undo completed steps
- continue: carry on, with the failure recorded
Circuit breakers
One in front of every model provider and third party.
- A failing service is cut off at once
- Steps are rescheduled without using a retry
- One broken provider cannot burn your budget
A token per attempt
Every try at a step gets a fresh, unguessable token.
- Whoever returns it completes the step
- It rotates on retry
- A late reply from a dead attempt is refused
Runtime
One service. One database. Nothing running when nothing is happening.
Weir is a stateless Go service on Postgres. Because workflows are data and step kinds are fixed, it stores the current step and each step's output, and never replays your code.
A step waiting on a person or a third party consumes nothing. When work appears, a wake-up message starts a worker; a scheduled sweep catches anything that was missed.
- No cluster
- No broker
- No always-on server
- Events on an append-only log
How it compares
What other engines leave to you.
| Capability | Weir | Temporal | Conductor | Step Functions |
|---|---|---|---|---|
| Workflows defined as data | Yes | Code | Yes | Yes |
| Pinned prompt versions and enforced cost budgets | Yes | Build it yourself | No | No |
| Approval with roles and escalation, in the open-source version | Yes | Build it yourself | Commercial edition | Build it yourself |
| Cheap classifier step with a safe default | Yes | Build it yourself | No | No |
| Self-hosted on Postgres alone, scaling to zero | Yes | No | No | Managed service only |
| Tool calls proxied with an allow-list per step | Yes | Build it yourself | No | No |
Based on our reading of each project's documentation in November 2026. Weir's column describes its design, not a released product.
Open source
The contract is the product. Come and build it.
Weir is designed as a small, stable contract with a reference engine, and many independent places to add value. A problem shared is a problem halved.
- 0.1
Contract
The definition schema, the event catalogue and the implementation guide.
- 0.2
Engine
Runs, the five step kinds, tokens, retries, failure policies, on Postgres.
- 0.3
Scale to zero
The wake-up and sweep path, with a measured idle cost.
- 0.4
Governance
Budgets, the AI gateway, circuit breakers, the approval inbox.
- 0.5
Pipes
The Pipe manifest, hooks, the tool proxy and the first source control Pipes.
- 1.0
Frozen contract
A passing conformance suite, proven by a real platform running on it.
Good first contributions
- A Pipe for a system you use
- A transport adapter: SQS, NATS, Kafka
- A model provider
- A handler for a common task
- An example workflow with its test
Weir is at the contract stage.
The spec is written. The best time to shape it is before it is frozen.
Links are placeholders in this preview.