Skip to content
Tavora

Introduction

Tavora is the agent layer for your stack — sandboxed reasoning, code-first authoring, and governance. Bring your own backend.

You ship a SaaS product on PocketBase, Supabase, or your own Go backend. Your customers want agentic features inside your app — a research-and-draft flow, a triage agent, a daily intelligence brief. Building that yourself means models drift, tools misfire, tenants bleed, and billing fragments across OpenAI + Resend + everything else.

Tavora collapses the agent stack to one bill, one audit log, one set of files in your repo — bolted onto the backend you already have via MCP.

How it differs

Section titled “How it differs”

Most agent platforms — LangChain, OpenAI Assistants, Bedrock Agents — share a reasoning model: the LLM picks from a fixed menu of tools, gets a result, picks again. Function-calling in a loop.

Tavora doesn’t. A Tavora agent has one primary reasoning tool: think. It takes a JavaScript snippet, runs it in a Goja sandbox, and returns the output. Inside that snippet the agent can call search(), fetch(), ai(), remember(), require() a skill module, combine their outputs, loop, branch, transform. The program the LLM writes is the plan.

Why this matters:

  1. Expressiveness. Real tasks are compositional (“for each failed invoice last month, look up the customer, post to Slack if Enterprise”). Function-calling forces this into a sequence of model turns. The code-reasoning core does it in one reasoning step that writes a loop.
  2. Observability by construction. Every step produces readable source. The session detail view shows the JS the model wrote, the sandbox primitives it called, and every return value — you can literally read the plan.
  3. Sandbox security is natural. Goja gives zero network + zero filesystem + hard resource limits by default. Every capability is an explicit primitive you registered. No per-tool security review.
  4. AI tools can edit your agents. The whole agent — persona, skills, MCP, evals — lives as files under tavora/agents/<id>/ that Cursor / Claude Code / Copilot can read and edit the way they edit the rest of your codebase.

Three pillars

Section titled “Three pillars”

Everything in the platform organizes around three pillars:

  1. Code-reasoning core. Every agent thinks by writing JS in a sandbox. Skills are require()-able modules. The session detail view is a readable trace over the reasoning.
  2. Code-first authoring. Your tavora/ folder is the source of truth — tavora.jsonc, agent.jsonc, persona.md, skills/*.js, evals/*.json. The tavora dev watch loop syncs drafts as you save; tavora deploy snapshots an immutable published version. AI coding tools can drive the entire loop.
  3. Multi-tenant governance. Team → app → agent is your tenancy (humans, billing, deploy units). Inside an app, an opaque tenant identifier per end-customer isolates state — the platform never models your user / org schema.

How you integrate

Section titled “How you integrate”

Tavora is a backend-to-backend service. Your backend talks to Tavora via the Go or TS SDK (or the REST API directly); your end customers never talk to Tavora.

sequenceDiagram
    box rgba(226,234,247,0.55) Your stack
      participant User as Your end-customer
      participant App as Your backend
    end
    box rgba(251,239,233,0.65) Tavora
      participant SDK as Tavora SDK
      participant API as Tavora API
    end
    box rgba(236,229,250,0.55) Your domain
      participant MCP as Your MCP server
    end

    User->>App: Request
    App->>SDK: createAgentSession(agent_id)
    App->>SDK: runAgent(sessionId, message)
    SDK->>API: SSE: stream events
    API->>MCP: tools/call (your domain API)
    MCP-->>API: result
    API-->>SDK: AgentEvent (execute_js / response / done)
    SDK-->>App: typed events
    App-->>User: rendered turn

Each Tavora app is your tenant inside the platform — its own indexes, agents, secret vaults, and audit log. A SaaS with 100 customers runs one Tavora app + 100 tenant refs, not 100 Tavora apps.

If you need the SDK to run in the browser (a chat surface in your own app, for example), the session-token exchange lets the browser mint short-lived API keys from a logged-in user’s session — see Browser-based chat.

What’s in the box

Section titled “What’s in the box”
  • Code-first authoring — tavora/ folder as source of truth; tavora init / dev / deploy to author and ship.
  • Indexes — RAG containers for semantic search over your docs.
  • Documents — Markdown/PDF/DOCX/XLSX ingest, chunk + embed, versioned by name.
  • Agent sessions — stateful, multi-turn, streamed as SSE.
  • Agent version history — every tavora deploy appends an immutable snapshot; restore any prior version from the control plane.
  • Skills — .js (module) and .md (prompt) files under your agent’s folder, hot-synced via tavora dev.
  • MCP servers — declared inline in agent.jsonc → mcp; the agent can call your domain API from inside a think step.
  • Secret vaults — envelope-encrypted credentials the platform resolves internally for the LLM router, MCP auth, and other tool surfaces. The API never returns plaintext.
  • Chat — OpenAI-compatible chat/completions (stateless gateway) plus stored Conversations (stateful chat threads).
  • Evals (advisory) — eval cases live in evals/*.json files, flow through source-sync, fire per agent on demand.
  • Session forensics — enriched trace with the JS + sandbox calls
    • token costs for any session, plus AI fix analysis.
  • Audit log — every deploy, restore, rename, delete — queryable, exportable.

Next steps

Section titled “Next steps”