Surfaces & integrations

All the ways a person or another system reaches an agent — and all the ways agents reach out. Every one of them funnels into the same execution path, so the surface changes the ergonomics, never the rules.

Human surfaces

Chat

The primary surface, and the one that shows the most of what a run is doing.

• Streaming — tokens, tool calls, and status arrive live over server-sent events; the same stream can be replayed later.
• Task console — the live task tree for orchestrated goals, plus run metrics for the current turn.
• Attachments — drag documents onto a question to give that run context; attached context flows through delegation too.
• Artifacts — files a run produced appear as download chips, with images and charts rendered inline.
• Interactive cards — approval requests, clarifying questions, and connector consent prompts appear in the thread and are actioned there.
• Conversation management — automatic naming, rename, delete, and a searchable history.
• Per-message actions — copy, re-run, or export a message.
• Replay — jump from any message to a step-by-step timeline of the run behind it.

Every organization gets a default Assistant in the org ring — a general-purpose conversational agent with web search and fetch, available to every member with zero setup.

Canvas

A living document that a person and an agent edit together. The agent writes with write_canvas; you edit in place.

• Revisions are immutable, with the document holding a pointer to the current one — the same model as agent versions.
• The agent sees your edits. If you changed the document since the agent last looked, its next turn receives a diff of what you changed, so it works from your version rather than overwriting it.
• Content is DLP-screened on the way in, like anything else the model produces.

Voice

A spoken conversation with an agent. Each turn runs through the one execution path, the transcript is DLP-redacted before it reaches the model, and the recording is stored as a retention-managed run artifact. The realtime backend sits behind the same provider seam as text models, so swapping in a production voice provider is configuration rather than a rewrite.

Slack and Teams

Threads, DMs, streaming replies, and interactive approval cards in the tools your organization already uses. See Automations & channels.

Browser use

For systems with no API at all, an agent can drive a headless browser under the strictest governance on the platform: reachable domains are default-deny, navigate and extract are reads while click, type, submit, and download are approval-gated writes, extracted text is DLP-screened, and each operation produces a recording artifact.

The Tools Library

One registry for external tool servers, and one resolution path for every caller. An MCP reference in an agent definition, a gateway's published tool list, and the catalog all resolve through the same code — there is no second way to reach a tool.

1. Register

   Add a server with its endpoint and transport. Authentication is stored as a vault reference; the secret itself never round-trips through the API.

2. Discover

   The platform connects and enumerates the tool surface, capturing each tool's read-only and destructive annotations.

3. Review

   The surface is reviewed against policy. A server that has not passed review cannot be promoted to a shared ring.

4. Promote

   Once reachable and reviewed, the server is promoted for wider use — the same ring model as agents and skills.

5. Watch for drift

   Re-discovery diffs the surface. A server that grows a new destructive tool is drift: review is re-queued and the owner notified, rather than the new tool quietly becoming callable.

Agents reference a registered server by slug, optionally pinning and narrowing it:

---
name: ticket-triager
model: default
mcp_servers:
  - slug: jira
    pin: 3               # optional: freeze to a reviewed surface version
    tools: [search_issues, get_issue]   # optional: narrow the surface
---

Virtual servers: REST → MCP

An internal API with an OpenAPI specification can become a library entry without anyone writing an MCP server. Upload the spec and each operation is materialized as a tool with a generated JSON schema, with mutating verbs mapped to destructive annotations — so they are review-flagged and approval-gated by default. Virtual servers are ring-scoped, promotable, and gateway-selectable like any other entry.

The MCP gateway

A gateway publishes a curated selection of tools as one MCP endpoint — a single governed URL an external client can point at, instead of a dozen direct integrations.

Its value is the choke point. Every call through it — whether from the platform's own executor or an outside client — passes one place that enforces:

Access is a scoped API key: gateway:invoke:<slug>.

Agents as tools: the MCP endpoint

The reverse direction. Your organization's agents can be exposed to an MCP client as tools named agent__<slug>, discovered and called over JSON-RPC with OAuth resource metadata published for discovery.

• The same visibility rules apply — a paused or killed agent is simply absent from the tool list.
• A call runs the one execution path, so budgets and the emergency stop are enforced server-side and surfaced as protocol errors.
• Access is a scoped API key: mcp:invoke.

Agent-to-agent (A2A)

Trellaris speaks A2A in both directions.

• Signed cards are verified on registration and on every re-fetch. A tampered signature is refused; a bad re-fetch keeps the last known-good card.
• Protocol negotiation falls back to the older protocol when a peer does not speak the current one, from one client implementation.
• Remote agents get parity — identity, budgets, and kill switches apply to them exactly as to native agents, and an admin control tower inventories every external agent in the organization.
• Resilience — timeouts, jittered retries, and a per-host circuit breaker that opens on repeated failure and recovers on its own.

The REST API

Everything the web app does, it does over the same public API — there is no privileged private surface. The OpenAPI schema is the contract and generates the TypeScript client.

Errors follow one contract everywhere — a problem document with a stable machine-readable code, including on terminal streaming events, so a client handles failures the same way regardless of where they arose.

API keys and secrets

• API keys are personal, hashed at rest, shown once at creation, and carry explicit scopes (a2a:invoke:<slug>, mcp:invoke, gateway:invoke:<slug>, compliance:read, compliance:suspend). Manage them under Settings → Access.
• Secrets are write-only: you store a value and get back a reference. The value is envelope-encrypted, decrypted server-side at the point of use, and never returned by the API. Library server credentials and connector tokens use the same vault.