Advanced Features

Yes. Click Talk in the agent's header, beside Workspace— Trinity opens the Workspace on that agent and the call starts. From inside the Workspace, the call button — the leftmost control in the composer — starts a call in the chat you are already in. The orb takes the conversation column, the agent's canvas takes the column beside it, and you speak naturally with roughly 280ms response latency. Gemini Live handles the speech-to-speech conversation, while Claude Code stays the agent's reasoning engine: when your request needs real work (files, tools, research), Gemini hands it to the agent, which runs it as a turn in that very chat — with its skills, files and memory — and Gemini speaks the result. When the call ends, the spoken turns sit in that chat as one collapsed Voice call · N min block and the agent's next typed turn knows what was said. A call is one chat with one agent — rooms have no voice mode. Voice replies on messaging channels and phone calls are separate features — see the Channels FAQ. See Voice Chat.

Talkis always there; it takes you to the Workspace, and the Workspace tells you why a call cannot start rather than leaving you with a button that does nothing. The usual reasons: no Gemini key — one saved in Settings → Integrations (Platform Keys) takes precedence over GEMINI_API_KEY in .envand applies without a restart — the VOICE_ENABLEDflag off (it defaults to on when the key is present), the browser refusing microphone permission, or a page served over plain http (a microphone needs a secure page). A call also won't start while a reply to a typed message is still being written — wait for it, then try again — and a pasted or bookmarked link with voice=1in it opens the chat but starts nothing; only the button starts a call. Voice is for signed-in platform users only — it does not appear on public agent links or for external clients signed in to the Workspace with an email code. See Voice Chat.

The call acts as the agent, in the chat it belongs to, over a tool surface that is fixed when the session starts and cannot grow afterwards. The platform offers run_task— Gemini says once that it is checking, hands the request to the agent, and the task runs as a normal resumable turn in that chat, in the background, while the orb shows a pill naming it (the next question covers how the result comes back) — plus six canvas verbs for drawing on the agent's maincanvas as it talks. Nothing fleet-wide is available: a call cannot list agents, message other agents or fan work out. An agent's template.yamlcan narrow that set but never widen it — voice: tools: [run_task, show_markdown]keeps only those two, an empty list means no tools at all, a name the platform doesn't offer is dropped with a warning, and declaring nothing keeps the platform default. Every run_task is written to the audit log. See Voice Chat.

Yes. In a Workspace call run_task is handed off at once and runs in the background, so the conversation goes on; the orb shows a pill for each task (queued or running), and the status line reads Working: run taskonly for the hand-off itself. Up to three tasks can be in flight, run one after another in the chat — at the cap the agent says so instead of queueing silently, and the same request repeated while it runs is refused rather than run twice. When a task finishes (or fails, with its reason) the agent brings it up at the next natural pause — after both of you have been quiet for a moment, and never more than about 20 seconds after it landed — says which request it answers, and its reply is also a turn in the chat. Ending the call cancels nothing: a task still running finishes and lands in the chat. A phone call has no chat behind it, so there run_taskis waited for with a 30-second limit instead — see the Channels FAQ. See Voice Chat.

A Workspace call lasts at most 30 minutes by default (WORKSPACE_VOICE_MAX_DURATION): thirty seconds before the limit the agent is told to wrap up out loud, and at the limit the call ends and the chat records it. End one sooner with End callin the status line, the orb's End button, or Esc— though a file preview or confirm dialog opened mid-call takes the first Esc for itself, and the call ends on the next. Switching chats, New chat, ⌘J or opening a room mid-call asks first — End call and leave or Stay on the call; leaving the page or pressing the browser's back button ends the call and keeps the transcript. The transcript is saved turn by turn on the server, so a dropped connection or a restart mid-call loses nothing already said. Mute on the orb, or the M key, silences your microphone (the status line reads Muted); talking over the agent interrupts it. See Voice Chat.

Both are per-agent settings. Each agent has a persisted Gemini voice (default Kore) that applies to the browser voice call and to outbound phone calls; owners can change it via the voice picker or the /api/agents/{name}/voice/nameendpoint. To change the persona — tone, focus, response style — place a voice-agent-system-prompt.mdfile in the agent's workspace (/home/developer/); this controls Gemini's behavior in voice sessions independently of the agent's main CLAUDE.md. Without one, Trinity auto-generates a prompt from the agent's template info. See Voice Chat.

Yes, on your side. A speaker button above the composer — Speak replies aloud— reads each reply in the agent's ElevenLabs voice; click it again to mute. It appears only when the agent has a voice configured, and it is hidden during a voice call, when the orb owns playback. It is a viewer-side choice, not something the agent opts into — unlike voice notes on Telegram, Slack and WhatsApp, which the agent chooses per reply with send_voice_reply (see the Channels FAQ). The ElevenLabs voice is unrelated to the Gemini voice a call speaks with. See Voice Replies.

Yes, with the microphone in the composer (Speak your message). It types what you say into the message field and sends nothing until you press Enter. It is not a voice call and needs no Gemini key, and clients signed in with an email code get it too. Trinity transcribes a recorded clip through ElevenLabs when the platform's ElevenLabs key is allowed to call speech-to-text. Otherwise the browser's own speech engine is used, and where neither can work, the microphone is not shown. An admin can check the key under Settings → General → Voice (ElevenLabs): can transcribe, cannot transcribe — reason, or transcription not verified. The same panel shows the last failed transcription and its cause. See Workspace → Dictation.

It was a separate full-page voice surface at /agents/{name}/workspace. That page is gone — its address now redirects to /workspace?agent={name} — and its two valuable halves live on in better places. The canvas— where the agent paints formatted text, Mermaid diagrams, images and static HTML layouts while it talks — is now the agent's own durable canvas, shown beside the orb during a call and on the Canvas tab afterwards. The callis now the Workspace's voice mode, inside a real chat. The Workspace button in the agent header opens the Workspace, and Talkbeside it opens it with the call starting. All canvas content is still sanitized, and HTML panels still render as static layout only — agent-supplied scripts never execute. See Voice Chat.

A canvas is a surface the agent keeps current— a status board, a running tally, the latest version of an analysis — rewritten in place, where reports accumulate as a record and dashboard.yamlwidgets belong to the Dashboard tab. It shows on the agent's Canvastab, on the Workspace rail's Canvas tab, and beside the orb during a voice call, which draws on the same default maincanvas — so an agent and its call share one board, and named canvases keep separate surfaces. A canvas is an ordered list of blocks — kpi, table, chart (bar, stacked bar, line, area, pie, donut), timeline, markdown (which may carry chart, kpi, table and mermaid fences that render as figures inside the prose), html, image, diagram (Mermaid) and json— optionally arranged on a starter layout (dashboard, report, brief, status-board) with named slots, and styled with a small platform design kit (ck-card, ck-grid-2/3/4, ck-callout, …) so it looks designed in light and dark without the agent touching CSS. The header states two facts — when the canvas was last updated and when the agent last finished a run — and draws no conclusion from them. Every canvas surface has PDF(your browser's own print-to-PDF), and the Canvas tab on Agent Detail has Share; both are covered in the Chat & Sessions FAQ. Everything is sanitized before it renders: scripts never run, <style>is stripped, and only the kit's classes survive. See Agent Canvas.

Just ask in chat: “Put a dashboard of this week's pipeline on your canvas.” In the Workspace, the rail's Canvas tab shows Ask for a canvaswhile the agent has none, which pre-fills the request. No skill is needed — the platform prompt every agent receives teaches the block kinds, the fences, the four layouts and the design kit, so a fresh agent produces a designed canvas without coaching (a fuller canvasreference skill is planned for the skills library but is not yet published, so there is nothing to assign). Ask for changes the same way: the agent patches only the blocks that changed and the header's Updated time moves; the header's agent last rantime beside it tells you whether the agent has worked since without refreshing — two timestamps, no verdict. Prefer data blocks — ask for “a KPI row” or “a table of open items” — over raw HTML. See Agent Canvas.

Its audience decides. operator (the default) shows a canvas on Agent Detail and to signed-in platform users in the Workspace; rosteralso shows it to the people the agent is shared with, in their Workspace — an external client signed in to the Workspace with an email code sees rostercanvases only. Ask the agent to “share this canvas with the team” to widen it. When the agent writes a canvas during a conversation, the write tells it whether the person asking can actually see the result, so it can widen the audience instead of reporting a success nobody sees. Reaching someone who cannot see the agent at all is a share link, which only a person can mint — see the Chat & Sessions FAQ. See Agent Canvas.

Through the canvas context of the turn. When set_canvas, patch_canvas or get_canvas is called without a canvas_id, the tool first asks GET /api/agents/{name}/canvas/context?execution_id=…, which answers with the resolved canvas_id and a source saying why: explicit(the agent named one — an explicit id always wins), open (the canvas you have open on the Workspace rail, which travels with each message you send from that chat), or default (main, when nothing is open). It is context, not permission — the agent reaches only the canvases it could already reach — and a canvas you deleted mid-conversation resolves to nothing, so the agent's next write does not recreate it. The Chat tab on Agent Detail carries no open canvas, so name the canvas there; when you did not name one, the agent says which canvas it changed. How this looks from the chat is in the Chat & Sessions FAQ. See Agent Canvas → MCP Tools.

No — those are a person's decisions. Through MCP an agent can write a canvas and choose its audience (operator or roster) with set_canvas, and remove one of its own with clear_canvas, but pin, bulk delete and the share routes have no MCP tool by design, and the REST routes refuse an agent's own key outright: a pin decides what everyone who can see the agent sees first, and a share link can reach the open internet. Only the agent's owner or an admin, signed in as a platform user, can pin, delete, share or revoke — pinning and deleting from either Canvas tab, sharing from Agent Detail only. The controls are in the Chat & Sessions FAQ and the reasoning in the Security FAQ. See Agent Canvas.

Yes. POST /api/images/generate takes a prompt, an optional use_case (general, thumbnail, diagram, social, avatar) and an optional aspect_ratio (1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3), and runs a two-step Gemini pipeline: it first refines your prompt with best-practice templates for the use case (send refine_prompt: falseto use your prompt as written), then generates the image from the refined prompt. The response is base64 only — image_base64 and mime_type, with the refined_prompt, original_prompt and model_used alongside; there is no hosted URL. It needs a Gemini key saved in Settings → Integrations or set as GEMINI_API_KEY: without one the endpoint answers 501, and a generation the provider rejects answers 422 with the reason and the refined prompt that was tried. GET /api/images/models tells you whether generation is available and which models, use cases and aspect ratios are in play. The same pipeline powers agent avatars. See Image Generation.

Every agent can have an AI-generated avatar. You can generate one from an identity prompt, upload a reference image so the avatar matches its style, and regenerate fresh variations from an existing avatar at any time — a regenerated avatar shows up straight away rather than keeping its old face cached. The Agent Detail page cycles through emotion-based variants every 30 seconds, and an admin button in Settings generates default robot-style avatars for every agent that doesn't have a custom one. See Agent Avatars.

Because no image exists for it yet. The first-run templates (scout, sage, scribe) ship an avatar.webp beside their template.yaml, installed at creation as the agent's default avatar, so a fresh install shows faces before any image-generation key exists; any local: template that declares an avatar_prompt can bundle an avatar.webp or avatar.png (up to 2 MB) the same way, and a missing or unreadable image falls back to the prompt-only seed. An agent seeded from a GitHub template shows initials until a Gemini key is configured and an admin runs Generate Default Avatars in Settings — which also replaces the bundled images, since they count as default avatars rather than custom ones. See Agent Avatars.

The Generate dialog shows a classified reason rather than a generic error. not_configuredmeans no image-generation API key is set — add a Gemini key in Settings → Integrations (Platform Keys). safety_filter means the upstream model blocked the request — reword the identity prompt. invalid_input means the prompt or reference image was rejected, while rate_limited and timeout usually just need a retry. See Agent Avatars.

Yes. An agent controls its Dashboard tab entirely by writing a dashboard.yamlfile in its workspace — no API call needed, the file is read on each dashboard request. Eleven widget types are supported (metric, status, progress, text, markdown, table, list, link, image, divider, spacer) — markdown renders formatted text, and there is no chart widget: give a metric or progress widget a stable id and the platform records its value on every fetch and draws the sparkline and trend arrow for you. A Platform Metrics section (tasks, success rate, cost, health) is auto-injected at the bottom of every dashboard unless the file sets platform_metrics: false. This is separate from the agent's canvas, which is a free-form surface rather than a widget grid. See Dynamic Dashboards.

Because dashboard.yaml used a widget type outside the closed set of eleven, or left out a required field. chart, badge and countdownhave never been widget types — an agent that writes type: chartgets that widget stripped by the agent server before the dashboard reaches the UI, listed in the tab's widgets skipped due to validation errorsbanner, and named in the agent's compatibility report; the rest of the dashboard still renders. For a trend line, use a metric or progress widget with a stable id: its sparkline is drawn from recorded history once it has more than one point, and a widget without an id is keyed by position, so moving it starts a new series. Only a missing title or an empty sections list invalidates the whole dashboard. See Dynamic Dashboards.

Source mode (the default) is pull-only: the agent pulls from the repo but never pushes — used for deploying agent code from a canonical source. Working Branch mode is bidirectional: the agent gets its own branch and pushes changes back, which suits agents that modify their own code; each working branch is ownership-locked to a single agent so concurrent pushes can't clobber each other. To sync from a specific branch, use the github:owner/repo@branch syntax at creation or the source_branch parameter in MCP. See GitHub Sync.

In Working Branch mode, yes: an auto-sync heartbeat inside the agent stages, commits, and pushes in-container changes about every 15 minutes, and you can toggle it per agent. Trinity also polls sync health every 60 seconds by default (SYNC_HEALTH_POLL_INTERVAL_SECONDSchanges it) without taking the agent's git index lock — after 3 consecutive failures (broken remote, expired PAT, upstream divergence) an alert appears in the Operating Room's Needs Response tab, and the fleet dashboard shows a per-agent sync health indicator. You can always trigger a manual Pull or Sync from the agent detail page. See GitHub Sync and Operating Room.

Yes, as long as a GitHub token resolves for it. Git gets the token from Trinity's credential helper on each fetch or push — the remote URL itself carries no token — and the gh CLI and REST calls read GH_TOKEN/GITHUB_TOKEN, which Trinity sets from the same token. A rotated or newly added token reaches git on its next operation, with no restart. An agent with no token is pull-only: its push URL is deliberately disabled, so a push fails immediately with an error telling you to fork to own or add a GitHub token. See GitHub PAT Setup → How Git Gets the Token.

Some templates declare fork_to_own: required in their template.yaml, meaning they're meant to be owned by you rather than run from the shared upstream repo. At creation, Trinity copies the template into a repository under your own GitHub account (private by default) using your PAT, points the agent's origin at it so everything the agent commits stays in a repo you control, and keeps a read-only upstream remote so you can pull in later template updates with a single git pull upstream <branch>. You need a GitHub PAT with repo-creation scope configured first. See Creating Agents and GitHub PAT Setup.

It's a standardized discovery endpoint — GET /api/agents/{name}/a2a/agent-card— that publishes an agent's capabilities in A2A 0.3.0 format so external orchestrators (AWS Bedrock, Azure Copilot, Google ADK) can discover and call the agent without knowing Trinity's internal API. The card is generated from the agent's template.yaml and container labels, works even when the agent is stopped (it falls back to a partial card), and never returns a server error. This endpoint requires authentication.

Agents you explicitly expose for A2A also get a public discovery card at GET /a2a/{name}/.well-known/agent-card.json and a JSON-RPC task endpoint at POST /a2a/{name}, so an outside orchestrator can task them. Exposure is per-agent and off by default; tasking always requires a Trinity MCP API key. See A2A Protocol.

Yes — pipelines are owned by the agent, not by Trinity. The /agent-dev:add-pipeline skill scaffolds a long-running, multi-stage pipeline inside the agent (a pipeline.yaml definition, per-instance state, tick/status/recover/pause/resume skills, and a heartbeat schedule that advances stages). The agent publishes its pipeline definitions and state to a read surface under ~/.trinity/, and Trinity exposes them read-only through the list_agent_pipelines and get_agent_pipeline_stateMCP tools — the platform displays progress but never runs a central DAG engine. See the agent-dev Plugin.

Reports are structured results — a table, a KPI set, markdown, a timeline — that an agent publishes once via the report MCP tool (and reads back with list_reports / get_report) so you can see its output without digging through chat transcripts. Published reports appear on the agent's Reports tab and, in the Workspace, under Delivered hereat the end of the chat they belong to and on the rail's Info tab. A report is the published-once counterpart of the canvas, which is rewritten in place. See Agent Reports.

It's the official agent development toolkit for Claude Code: a curated registry of plugins covering the full agent lifecycle, added once with /plugin marketplace add abilityai/abilities. Five plugins are available: create-agent (the custom interview that scaffolds any agent, a website scaffold, and review, adjust and clone for existing agents), agent-dev (playbooks, memory systems, backlog workflow, pipelines, orchestration, a shared canon layer, fleet analysis and migration), trinity (connect, onboard, deploy, and sync agents on Trinity), dev-methodology (documentation-driven development workflow), and utilities (ops and productivity skills). Install each with /plugin install <name>@abilityai. See Abilities Marketplace.

create-agent 2.0.0 retired its eight pre-built domain scaffolds: /create-agent:custombuilds every one of those shapes from the same interview — role, skills, schedules, credentials and Trinity wiring — and a knowledge-base agent is custom plus /agent-dev:add-memory. /create-agent:website (a Next.js site, no agent), clone, review and adjust remain, and /create-agent:create still lists what is available. Every agent custom creates includes CLAUDE.md, starter skills, a template.yaml with plugins:, schedules: and credential declarations, a dashboard.yaml and an onboarding tracker. See create-agent Plugin.

Yes, per agent: set TRINITY_PLATFORM_PLUGINS=0 on the agent container and the boot step that re-installs trinity@abilityaiis skipped for that agent; the platform's compatibility report then shows the plugin state it recorded. The plugins the agent declares in its own template.yaml are unaffected. For an air-gapped install, an agent image built with --build-arg TRINITY_PREINSTALL_PLUGINS=0skips the pre-install instead — the boot step still runs, and what it could not fetch is reported in the compatibility report rather than failing the start. See Abilities Marketplace → Plugins Inside a Deployed Agent.

Run /trinity:connectonce per machine — it authenticates against your Trinity instance and saves the MCP connection config — and add a GitHub token under Settings → GitHub token (a fine-grained PAT with Contents: Read; public repos need none). Then push the agent to a GitHub repo and run /trinity:onboard in its directory: it checks the agent for Trinity compatibility, creates any required files (template.yaml with declared credentials, schedules and plugins, .env.example, .mcp.json.template), and deploys from the repository— Trinity clones it and tracks the branch, so later updates are git push followed by /trinity:sync. Deploying from local files remains a fallback when there is no repo yet. Remember to turn on the new agent's autonomy toggle in the UI before you expect its schedules to fire. See Building Agents.

You don't have to adapt the repo locally. Trinity tolerates a repo with no template.yaml (the agent just lands with no declared resources, schedules, or plugins), so create the agent as-is, then run /trinity:onboard insidethat agent — send it /trinity:onboard in-place as a chat message. The skill detects it is running in a deployed agent, writes the Trinity files (including a plugins: block that declares at least trinity@abilityai), installs the declared plugins immediately, commits and pushes the result back to the repo, reconciles declared schedules, and finishes with the platform's own compatibility report. The push-back matters: a repo-deployed agent tracks its branch pull-only, so a file written only in the container is lost on the next reset — if the agent has no write credentials the skill says so and prints the patch rather than pretending. No bootstrap is needed first: the trinityplugin is provided by the platform — the agent image ships with trinity@abilityaiinstalled and every container boot re-installs it if it's missing, whether or not template.yamldeclares it — so a new agent runs /trinity:onboard in-place straight away; only an agent still on an agent image built before that pre-install needs the one-time terminal bootstrap the docs describe. See Onboarding a deployed agent in place.

Run /trinity:sync schedules and /trinity:sync plugins (both also run automatically after a push, pull, or deploy, and read-only under status). Each treats template.yaml as the design truth: it creates schedules or installs plugins that are declared but missing on the instance, and reportsanything live that isn't declared — never deleting a schedule or uninstalling a plugin, since removals are the operator's act. Schedules are matched by name; a plugin installed by reconciliation loads on the agent's next execution. See trinity Plugin.

The core set: a CLAUDE.md(the agent's identity and instructions — it becomes the system prompt), a template.yaml (Trinity deployment config), and a .mcp.json.template declaring MCP servers with ${VAR} placeholders that resolve from injected credentials at runtime. Optional but recommended: skills in .claude/skills/, a dashboard.yaml for custom metrics, and an .env.exampledocumenting expected credentials. Everything in the template repository is copied into the agent's home directory at creation, and /trinity:onboard can generate the required files for you. See Building Agents and Creating Agents.

The Brain Orb is a self-rendering "mind" page for knowledge-base agents like the bundled Cornelius second brain: a live 3D knowledge graph drawn from the agent's own notes, edges, and activity, shown on the agent's Braintab. It's capability-gated — it appears only for agents that ship the brain-orb capability and only when the platform's Brain Orb flag is enabled (off by default). The agent owns the graph's generation and scope; Trinity just reads and renders it. See Dynamic Dashboards.