# 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.