DURABLE EXECUTION FOR AGENTS
Workflows your agent can rewrite while they run.
Tickr runs any program — Python next to Go next to a shell script — as a durable, resumable graph. When your agent changes the plan mid-run, the graph changes with it. Retries, receipts, and one record of everything that happened.
No SDK in your code. Any language. Any tool.
Open-source data plane · managed control plane · your code and data never leave your compute.
# 1. run the data plane
docker run -p 7373:7373 tickr/dataplane
# 2. scaffold a workflow
npx tickr init my-agent
# 3. run it
npx tickr run my-agent Your agent improvises.
Your orchestrator doesn’t.
Durable execution solved the crash-and-resume problem. It didn’t solve the agent problem.
Every orchestrator asks you to declare the whole graph up front. But an agent decides what to do while it’s working — it discovers a source, picks an approach, and only then knows there’s a six-hour warehouse job at the end that had better not vanish when a pod restarts.
So teams end up running two systems. The agent improvises in one. The durable work runs in the other. Nobody has a single record of what actually happened.
Tickr is one graph that covers both.
One workflow. One record. However many drivers.
An agent explores, decides, acts. Tickr keeps the ledger: every external step it took lands in the workflow as a shadow task — the record of something that already happened. A ledger records; it doesn’t replay.
Then the durable tail shows up — the warehouse job, the long batch, the send. The agent hands it to Tickr with a patch, and Tickr runs it with retries and receipts. Improvised work and durable work, in one graph, in one audit trail.
The graph grows mid-flight.
A running instance is a graph, and the graph can change while it runs. The builder can be a task already inside the run, deciding from variables the run has produced — or an external caller, or your agent.
Extensions are typed constructors, validated exactly like a workflow definition, applied atomically. A malformed extension is rejected before it touches a live run.
Not the same as mutable state. Other engines let you edit a running workflow’s variables. Tickr lets you change its structure — add tasks, edges, and gates to a run already in progress — with the same validation a fresh definition gets.
Note: Not to be confused with Temporal’s Patching API — that is a versioning mechanism that protects in-flight runs from code changes. Tickr’s extension adds tasks and edges to a run that is already executing.
let patch = mkChain { anchor = "L4", # plan's graph code steps = [ { handle = "search", task = search }, { handle = "synthesize", task = synthesize }, { handle = "report", task = report }, ],}Any program is a valid task.
No SDK. No bindings. No base class. No skeleton to inherit.
A Tickr task is a plain program that reads inputs and publishes outputs through one binary — tickr-ctx.
Agent stacks are not monolingual. They’re a Python planner, a TypeScript tool server, three CLIs, an MCP server, and a shell script somebody wrote in 2019. Every other durable execution engine asks you to rewrite that inside their SDK, in a language they support.
Tickr asks you to change nothing. The contract is an envelope shape and key-value semantics — an open format with no platform API to fall behind. Your integration outlives any single runtime, including ours.
# Python
subprocess.run(["tickr-ctx", "get", "table_name"])
# Go
exec.Command("tickr-ctx", "get", "region").Output()
# Bash
report_url=$(tickr-ctx get report_url --wait 30s)Loops, gates, and branches — as readable config.
Author workflows declaratively in a typed DSL. Tasks, edges, gates, loops. You state the graph; Tickr owns running it. The definition is data — read it, diff it, review it in a PR.
Start it every way.
Cron schedules, external signals over HTTP or the queue, a manual fire-now, or a wakeup from another workflow. All of it lands on one timer wheel.
Cycles are legal here.
Loops are first-class: a ring of tasks that iterates until its exit condition. The ring turning is “continue”; the one arrow that leaves is the one real decision. Drawn as an actual ring — not unrolled into a lie.
Hold an edge until the world is ready.
Signal gates park a workflow mid-graph until an external event matching a predicate arrives — with expiry for the case where it never does. The payload it captures flows into downstream tasks’ context.
Route on what the run produces.
A task produces a routing variable at runtime; downstream edges each carry a predicate over it. The edge whose predicate holds fires; the other stays parked. Branching is data.
PLATE II — ANATOMY OF A WORKFLOW · AS THE CONSOLE DRAWS IT
Reproducible, when you want it to be.
A task can be any command. When you want the stronger guarantee, a task can also be a Nix build — hermetic, pinned, identical every run, all the way down to the compiler.
Same graph, same DSL. You opt into reproducibility per task, not per project. Nix is offered as a benefit and an upgrade, never charged as a toll.
# Nix task opt-in
let build_task = mkTask {
name = "reproducible-build",
nix_expression_path = "build.nix", # Pinned, hermetic Nix derivation
args = ["--release"],
}Open at the edges. Managed at the core.
The Tickr data plane — conductor, executor, CLI, and Console — is open source. It’s the part that touches your code, your data, and your compute, so you can read every line of it.
It pairs with the managed control plane: triggers, state, versions, patches, and control-flip. Your data and execution never leave the data plane. Only the metadata needed to drive those controls crosses over.
- Cloud
Both planes on our infrastructure. Zero ops.
- Self-hosted data plane
Run the open-source data plane on your compute, connected to the managed control plane.
How Tickr is different.
| Tickr | Temporal / Restate | Inngest | LangGraph | |
|---|---|---|---|---|
| Write tasks in any language | Any program | SDK languages only | SDK languages only | Python / JS |
| SDK required in your code | No | Yes | Yes | Yes |
| Workflow is inspectable data | Yes — typed config | No — it’s code | Partly | Yes — in code |
| Change structure of a running instance | Yes — typed patches | No | No | Limited |
| Records work an external agent already did | Yes — shadow tasks | No | No | No |
| Per-task hermetic builds | Yes — optional Nix | No | No | No |
Comparisons reflect our reading of each project’s public docs as of July 2026. Corrections welcome — contact us at team@tickr.run.
Built for agents. Good at everything else.
-
Agent-delegated jobs
The durable tail of an agent’s plan, with retries and receipts.
-
Looping agents
critique ▸ revise rings that run until they’re done.
-
Approval chains
Signal gates that happily wait three days.
-
Nightly warehouse loads
Retried, hermetic, on the tick.
-
Release trains
Build → gate on approval → promote.
-
Backfills & migrations
Long, idempotent, resumable.
Free while we’re in beta.
Tickr is pre-1.0 and we’re working closely with our first teams. The control plane is free, the data plane is open source, and there’s no usage cap while we’re in beta.
We’re looking for teams running agents.
If you’re orchestrating agents and losing track of what actually ran, we want to build the next three months of Tickr with you. Direct access to the people writing it, and your problems jump the queue.