One Postgres backend for the parts every agent needs. Give each agent an identity and a vault so it calls real APIs without ever seeing the keys, resume from the last checkpoint when a run dies, and get queues, schedules, and approval gates in the same place.
$ docker compose up -d postgres && pnpm dev
To do real work, an agent has to call GitHub, Stripe, your database. The easy path drops the token into the prompt or the environment, where the model and every tool can read it. Tidebase holds the secret and makes the call for the agent, so the key stays on your side of the line.
// Setup once: vault a secret behind a pinned upstream.await tide.resources.connect('github', { provider: 'static', baseUrl: 'https://api.github.com', secret: process.env.GITHUB_TOKEN, scopesAllowed: ['repo.read'] }) // Each agent proves its own keypair identity. No shared key.const { challenge } = await tide.agents.challenge(agentId)const { sessionToken } = await tide.agents.prove(agentId, { challenge, signature: signChallenge(challenge), // agent's private key})const agent = new Tidebase({ agentSessionToken: sessionToken }) // In a run, the agent asks for exactly what it needs.const grant = await agent.auth(runId).request({ resource: 'github:repo:acme/app', action: 'repo.read',}) // Tidebase injects the vaulted secret. The agent never sees it.await agent.auth(runId).use(grant.grantId, { method: 'GET', path: '/user' })An agent registers a keypair, not one shared API key. To act, it signs a server challenge with its private key and gets a short-lived session token it presents on every call.
Envelope-encrypted at rest. The upstream is pinned and scopes are capped, so a leaked grant can't reach an arbitrary host.
The secret is injected into the outbound request. The agent and the model get the response, never the key.
Every grant is a receipt with no secret material. Tighten a scope or revoke access without touching the agent.
A live run, checkpointing each step to Postgres. Kill it mid-flight, re-invoke with the same run id, and completed steps replay in 0ms.
await tide.run('generate-report', { runId }, async (run) => { const plan = await run.step('plan', makePlan) const sources = await run.step('fetch-sources', () => fetchSources(plan)) await run.state.set({ status: 'writing', progress: 0.7 }) const ok = await run.gate('approve-report', { prompt: 'Send the generated report?' }) return run.step('write-report', () => writeReport(sources))})Create or resume a run, then checkpoint each unit of work. Completed steps return from Postgres on replay.
Push status and progress your product UI can subscribe to, in real time.
Open a durable gate and wait. The run resumes only once a decision exists, and it resolves exactly once.
The last step runs once the gate clears, and its result is checkpointed too.
Same calls, same run protocol, so both SDKs can drive the same run. Point either at your server and go.
Zero-dependency Python (stdlib only, 3.9+) with an async tidebase.aio. Or skip the SDK and call the
HTTP API directly.
The run pauses at a durable gate and waits for a decision, in Studio, your own app, or any webhook surface. It resolves exactly once, and every decision is audited.
Every step's state is versioned in Postgres. When a run produces a wrong answer, scrub the timeline to the exact step that poisoned it, no print statements, no rerunning.
run.fanout() runs subagents as child runs, each checkpointed independently. If the parent resumes, existing children are reused, no duplicate subagents, no double spend.
Token and tool spend is attributed per run and per step, without proxying your LLM calls, so a scraping loop gone wrong shows up on a graph, not on an invoice.
The run is the core object. Checkpoints, state and gates are just the start, these services come wired in, so there's no extra infrastructure to build.
Run events stream to any webhook you own, Slack via your bot, an internal tool, or your product, and a pending gate becomes a message your team can approve right there. Decisions happen where people already work, not in yet another dashboard.
Only one worker ever owns a run at a time, and zombie workers are fenced from writing stale results, so a retry can't double-charge a customer or fire the same tool twice.
When a run fails, Tidebase calls a signed endpoint in your app so it can re-invoke the workflow. Every attempt is recorded with its delivery status.
Subagents run as child runs, idempotent by name on resume. State is versioned, so snapshots, time travel, and forks fall out of the same model.
Token spend attributed per run and per step, without proxying your LLM calls, so a runaway agent shows up on a graph before it shows up on the bill.
Secrets are vaulted and injected into the call, so the agent and the model never see them. Every grant is recorded with who approved it and why, with no secret material in the ledger.
Every run is a full trace: step timeline, live state, pending gates, costs, and the event stream. Self-hosted, in your own Postgres, no secret custody.
The docs ship as one file your assistant can read. Open Claude or ChatGPT with it preloaded and have it evaluate Tidebase against your stack, critically.
llms-full.txt · every docs page also serves a raw .md twin
Self-hosted from day one. Point the SDK at Postgres, vault a secret, and let the agent call.