Skip to content
Cinatra Docs

Why Cinatra

Cinatra is the platform you reach for when you want agents to do real work, on data you control, for as long as the work takes, with a paper trail you can audit. This page gathers the concrete benefits the platform unlocks — what it adds over isolated chat tools, managed-agent products, and one-off SDK integrations.

For the comparisons against specific alternatives, see the comparisons section.

Work that doesn’t disappear

Section titled “Work that doesn’t disappear”

Most AI tools are optimised for a single chat session. Close the tab and the work is gone. Cinatra is built for the opposite case: workflows that take minutes, hours, or days; agents that pause for human review and resume cleanly; runs that survive page reloads, network drops, and process restarts.

  • Every agent run is durable in Postgres with a typed AG-UI event stream backed by Redis Streams. Disconnect and reconnect; the stream picks up exactly where it left off.
  • The platform exposes runs over both the chat UI and MCP, so a workflow you started in chat can be inspected and continued from Claude Code, ChatGPT connectors, or any other MCP client.
  • Background work is owned by BullMQ on Redis. Even when nobody is watching the run page, the work continues — and the user gets a notification when it lands.

Multi-provider LLMs with one interface

Section titled “Multi-provider LLMs with one interface”

You never write OpenAI / Anthropic / Gemini code by hand. Everything routes through one orchestration interface that owns provider selection, tool injection, skill matching, retries, and observability.

  • Add a new provider once; every agent benefits.
  • Switch a model on a per-agent or per-instance basis without touching agent code.
  • Cost and usage are tracked centrally with per-agent and per-provider breakdowns in the metrics dashboard.

A real marketplace, not a vendor catalog

Section titled “A real marketplace, not a vendor catalog”

Agents and skill packages are first-class extensions: versioned, signed, installable, archivable. The marketplace at /administration/marketplace is a registry that can be shared across Cinatra instances — any deployment with a configured public registry can publish and install.

  • Private packages stay scoped to the publishing instance (server-side filtered, not just UI-gated). The private path works out of the box against the instance’s own Verdaccio.
  • Public packages are universally visible to every connected instance. Public publish requires the operator to configure a public registry destination under Administration → Environment → Registries.
  • Promotion from private to public is one-way and audited; nothing escapes the trail.
  • Install from GitHub for skill packages — paste a repo URL, pick a release, the platform validates and installs.

See Registry and marketplace.

Agents authored conversationally

Section titled “Agents authored conversationally”

You don’t open a code editor to author an agent. You describe the problem in chat, the assistant discovers whether an existing agent already solves it, asks you to confirm before building anything new, validates the agent against a deterministic review gate, compiles it, and (when you confirm) publishes it.

  • Discovery-first: the chat assistant probes installed agents, the marketplace, and remote A2A endpoints before offering to write anything new.
  • Nothing implements without explicit confirmation; the assistant stays in conditional language until you say yes.
  • The same MCP primitives that drive chat authoring are reachable from any MCP client — Claude Code, automation scripts, CI workflows.

See Creating agents in chat.

Continuous learning built in

Section titled “Continuous learning built in”

When you edit a prompt inside a HITL surface during an agent run, the platform notices. If your admin enables skill autosave, those edits are consolidated into a per-user, per-agent personal skill that primes the next run of the same agent. Your phrasing, your examples, your exclusion lists — they accumulate over time instead of evaporating.

  • Personal skills are scoped to you. Your editing style doesn’t contaminate the shared catalog.
  • Capture is non-blocking and admin-gated; the feature is off by default and audited when enabled.
  • Promotion to team or org scope is a deliberate manual step, not something the platform decides for you.

See Continuous learning and personal skills.

Cross-instance collaboration that respects boundaries

Section titled “Cross-instance collaboration that respects boundaries”

When two Cinatra instances need to work together — a vendor publishing tools, two teams sharing research agents, a consultancy serving multiple clients — the platform makes the seams explicit:

  • Shared marketplace with server-side visibility filtering.
  • A2A inter-instance calls so one instance’s agent can invoke another’s as a tool, with auth handled by the OAuth-provider plugin.
  • Run data stays where the run runs. A2A calls carry the request and response; neither instance gets a back door into the other’s database.
  • Every install / update / archive / promote / cross-instance call writes an audit row.

See Cross-instance collaboration.

Standards-aligned by design

Section titled “Standards-aligned by design”

Cinatra speaks four open agent standards so agents authored here are portable, and agents from elsewhere plug in:

  • OAS (Open Agent Specification) — every agent is a declarative file readable by any OAS-compliant runtime.
  • A2A — every agent is callable from any A2A client; the platform also calls remote A2A agents as local tools.
  • AG-UI — typed lifecycle events any AG-UI client can render.
  • A2UI — declarative HITL surfaces on a parallel channel.

You are not locked into a Cinatra-shaped data format. See Open standards in Cinatra.

Dashboards out of the box

Section titled “Dashboards out of the box”

The /agents route is a real, editable dashboard backed by a shared semantic-layer engine. You add widgets, resize them, swap them, save the layout. New dashboards are persisted with a draft / published / archived lifecycle, governed by per-resource permissions, exposed as MCP primitives, and audited end-to-end. See Dashboards.

Notifications and operational awareness

Section titled “Notifications and operational awareness”

Background work tells you when it finishes. Failed jobs route to admins. Long-running agent runs notify the user that started them. The notification feed lives in Postgres, surfaces in realtime over LISTEN/NOTIFY, and is durable across sessions. Toasts handle transient in-page feedback; the feed catches everything else.

Open source, self-hosted, your data

Section titled “Open source, self-hosted, your data”

Cinatra is open source under Apache 2.0. You run it on your own infrastructure, with your own database, your own LLM provider keys, your own connector credentials. There is no Cinatra cloud you have to give your data to. If you decide to leave the platform, every agent you wrote is an OAS Flow file in git; another OAS-compliant runtime can load it without modification.

Where to go next

Section titled “Where to go next”