Frequently asked questions
Tidebase is an open-source checkpoint layer for AI agents: wrap your steps, and failed runs resume from the last safe point — in your own Postgres, without moving execution into a new runtime. These are the questions developers actually ask.
Is it safe to rerun a failed AI agent run?
With Tidebase, yes — if every step that performs external writes declares an idempotency key, and Tidebase makes that condition explicit instead of leaving it to tribal knowledge. Re-invoking a run with the same runId replays completed steps from their checkpoints (they never re-execute), and a failed step is classified by its resume contract: read-only and idempotency-keyed steps are safe to replay automatically, while unkeyed external writes park in manual_review so a retry can’t double-charge a customer.
How do I resume an AI agent workflow from where it crashed?
Re-invoke the same workflow function with the same runId. Completed steps return their checkpointed results from Postgres instantly; execution continues at the first incomplete step. Since v0.5 Tidebase triggers the re-invocation itself for queued runs (retries with backoff, requeue on worker death) and can push signed invocation webhooks to your app — or you keep your own queue/cron.
Can Tidebase replace my job queue or cron?
For agent workloads, yes: v0.5 ships durable queues (dedupe keys, delays, priorities, retries with backoff, per-queue concurrency and rate caps) and five-field UTC cron schedules, with pull-mode workers (tide.work()) or signed push webhooks. A queued job is a run — one lifecycle authority, no status drift. Double-fires on schedules are structurally impossible via fire-time dedupe keys.
How do I cancel a running agent?
tide.runs.cancel(runId, { reason, actor }). Cancellation is authoritative and one-way: in-flight workers observe it at their next step or gate boundary, a gate-blocked worker unwinds immediately, and complete/fail after cancel are refused. Deadlines cancel automatically.
Does Tidebase execute my code?
No, deliberately. Your app, worker, or job process keeps calling your LLMs, tools, and APIs directly. The SDK wraps your workflow function, and a Postgres-backed server stores checkpoints, live state, events, and approval gates around it. You get “completed steps never repeat,” not “your dead process magically restarts.”
Do I need Temporal for an AI agent?
If you’re already all-in on Temporal, use it — it gives true durable execution. But Temporal asks you to move execution into its worker model: deterministic workflow functions, activities, task queues, and a cluster to operate. Tidebase asks you to wrap functions you already have — a smaller guarantee for a much smaller adoption cost, with agent-specific primitives (gates, fanout, state forking, token-cost tracking) built in.
How is Tidebase different from LangGraph checkpointers?
LangGraph checkpointers persist the state of a LangGraph graph; Tidebase checkpoints any code, in any framework or none. It also covers operational ground a graph checkpointer doesn’t try to: run/step leases with zombie-worker fencing, replay-safety classification, durable approval gates deliverable over webhooks, parent/child run trees, a live-state SSE API, and a Studio dashboard.
How do I pause an AI agent for human approval?
Call run.gate('approve-send', { prompt: 'Send it?' }). The workflow blocks on a durable gate stored in Postgres; it can be approved or rejected from Studio, your own product UI, or any webhook surface. Gates resolve exactly once — a second resolve attempt gets a conflict, and an already-resolved gate replays its decision on resume.
Can two workers pick up the same run?
No. Run and step leases are mutually exclusive and fenced, so a zombie worker that wakes up late cannot write back stale results. This is asserted by concurrency-probe tests against real Postgres.
Where does my data live?
In your own Postgres. Tidebase is self-hosted (Docker + Postgres), Apache-2.0 licensed, and never proxies your LLM calls or stores your API keys.
Is Tidebase production-ready?
Not yet — it’s an alpha. API auth is opt-in (set TIDEBASE_API_KEY on server and SDK); without it, run only in trusted local/self-hosted environments. The durability invariants (checkpoint replay, lease fencing, exactly-once gates) are enforced by a 57-test suite against real Postgres, but treat it as ready for local demos and early feedback, not production traffic.
What languages does the SDK support?
TypeScript (@tidebase/sdk) and Python (tidebase on PyPI, zero dependencies). The server is plain HTTP + SSE, so any other language can integrate directly against the API.