Workspace Features

A guided tour of what you find in the Cinatra sidebar and the administration area, with links into the deeper docs for each surface.

If you are arriving here from the README, this page is the map. If you are looking for the developer reference, start at Concepts and glossary.

---

Sidebar

Chat

/chat is the conversational surface. It is also where most agents are created, run, edited, and managed. The chat assistant follows a discovery-first authoring loop — it looks for an existing agent before offering to write a new one, and asks for explicit confirmation before any write or publish. See Creating agents in chat.

Multi-threaded chats with team chats are supported; built-in handles include @chatgpt today.

Agents

The Agents sidebar item routes to /agents, now an interactive dashboard of recently used and recently run agents. The previous installed-agents listing lives at /agents/status and is reachable from the dashboard’s “Status” affordance. Agent Setup is a sibling sidebar entry that opens the chat-driven authoring flow. See Dashboards for the dashboard side and Creating agents in chat for the authoring side.

Information

• Data — the unified object list with typed views for assets, accounts, contacts, and any registered object type. Browse, filter, drill into individual records.
• Metrics — operating visibility, cost tracking, provider usage. See Configuration for what the underlying metrics surface tracks.

Tools

• Skills — the skill catalog, installed skill packages, and the match overview that shows which skills apply to which agents. When skill autosave is enabled by an admin, your prompt edits inside agent HITL surfaces are captured automatically at run completion and turned into personal skills that prime the next run. See Continuous learning and personal skills.
• Connectors — third-party service connections (Gmail, Google Calendar, Apollo, LinkedIn, WordPress, Drupal, Apify, YouTube, GitHub) wired through the Nango OAuth gateway. Each connector exposes its operations as MCP primitives that agents can call.

---

Other top-level surfaces (not in the sidebar)

A few features ship as routes you reach directly or through the chat assistant, even though they don’t have a dedicated sidebar slot:

• Dashboards at /agents (the default dashboard) and additional dashboards under their own routes. See Dashboards.
• Lists at /lists. Typed groupings agents read from and write to as first-class inputs and outputs. Lists are themselves typed objects (@cinatra/lists:list), reachable as MCP primitives (lists_create, lists_get, lists_list, lists_update, lists_delete, lists_members_add, lists_members_remove, lists_members_count).
• Notifications at /notifications. A Postgres-backed feed surfaced with realtime push via Postgres LISTEN / NOTIFY. The platform writes notifications on background-job completion or failure, on long-running agent run state transitions, and from extensions through the explicit createNotificationForRecipient API. Recipient routing covers per-user, per-team, per-organisation, per-project, and an admins-only sink for system failures. Toasts handle transient in-page feedback; the notifications feed is durable.

---

Administration

The Administration area at /administration/* is the platform-settings surface. Most screens are admin-only.

LLM (/administration/llm)

Provider configuration for OpenAI, Anthropic, and Google Gemini. Keys are stored encrypted under the platform’s encryption key. See Configuration.

MCP (/administration/mcp)

The Cinatra MCP server’s shared configuration: auth, discovery, and OAuth-client management for external clients (Claude Code, ChatGPT connectors, custom agents).

Marketplace (/administration/marketplace)

Discover and install extensions from your connected registries. Public packages are visible to every Cinatra instance; private packages are filtered server-side to the publishing instance’s vendor scope. See Marketplace.

Extensions (/administration/extensions)

The active / archived catalog of every extension installed in this instance, with the lifecycle controls (archive, restore, force-delete, promote to public) and the GitHub-release skill upload entry at /administration/extensions/upload. See Marketplace for the install flows and Extensions for the engineering shape.

Permissions (/administration/permissions)

Platform roles, organisation membership, and the generic Extension Permissions surface used across all four extension kinds (agents, skill packages, dashboards, dashboard cubes). Skill packages additionally support per-skill overrides. See Security.

Skills (/administration/skills)

Skill catalog administration plus the skill autosave controls that govern continuous learning. Three knobs: master enabled, userCanConfigure for per-field opt-out, userCanSeeIndicator for the autosave indicator on HITL surfaces. See Continuous learning and personal skills.

Environment (/administration/environment)

Per-instance environment knobs and the canonical registry-configuration surface. The Registries tab (?tab=registries) is where you submit the registry-connection request, see its pending/connected status, and (post-approval) verify the credential round-trip. Agent install path, registry destinations, and other instance-scoped runtime settings live in adjacent tabs of the same page.

Assistants (/administration/assistants)

Configuration for built-in chat assistants (@chatgpt) — credentials, model selection, persona, default tool catalogs.

Instance (/administration/instance)

Instance identity: display name and namespace. The namespace is the npm scope under which this instance publishes its extensions and the basis for the server-side visibility filter.

Telemetry (/administration/telemetry)

Per-instance telemetry settings — what gets emitted to OpenTelemetry, what gets shipped to the Sentry-compatible error backend if a DSN is configured. See Configuration for the DSN-gated error reporting layer.

Jobs dashboard (/administration/environment/jobs-dashboard)

BullMQ job dashboard (queue depth, in-flight jobs, failed jobs) plus the worker status surface. Reached from the Environment tab.

Workspace (/administration/workspace)

Better Auth organisation management — members, roles, invitations. The route is named “workspace” historically; the underlying entity is the Organisation ownership level.

Apps (/administration/apps)

App-specific integrations that don’t fit a generic connector pattern (Apollo people-search, Gmail aliases, OpenAI Codex). These are visible separately from the user-facing Connectors sidebar group because they configure platform-level capabilities, not per-user OAuth flows.

a2a (/administration/a2a)

A2A dev-peer registration and the outbound A2A endpoint catalog — used during development to wire up sample external A2A agents, and in long-lived deployments to inspect the configured A2A peer set.

---

Where to go next

• The platform vocabulary: Concepts and glossary
• The open protocols every sidebar surface speaks: Open standards in Cinatra
• The architecture behind the sidebar: Architecture