Control Panel (Web Admin)

Use the control panel when you want a browser UI for chat, orchestrator, automations, memory, live feed, packs, and runtime ops.

The canonical operator flow now starts from @frumu/tandem and its master tandem CLI. The panel is an add-on that you install when you want the web UI.

Choose a path

Official ready-to-run package

Use this when you want the supported packaged control panel with bootstrap and service helpers.

npm i -g @frumu/tandem
tandem install panel
tandem panel init

Editable app scaffold

Use this when you want the actual app source in your own folder so you can customize routes, pages, themes, styles, and runtime behavior.

npm create tandem-panel@latest my-panel
cd my-panel
npm install
npm run dev

The generated app includes editable src/, server/, local runtime scripts, and local config files.

Official package: initialize environment

tandem panel init

This creates/updates .env and ensures an engine token is available.

Official package: run

tandem panel open

Open:

http://127.0.0.1:39732

Aliases:

tandem
tandem-setup
tandem-control-panel
tandem-control-panel-init (init only)

Official package: optional service install (Linux)

sudo tandem service install

Useful options:

--service-mode=both|engine|panel (default both)
--service-user=<linux-user>

Editable scaffold: customize

After scaffolding:

edit src/pages/ and src/app/ for routes and views
edit src/app/themeContract.ts and src/app/themes.js for themes
edit server/ and bin/setup.js for runtime behavior
run npm run build for a production bundle
run npm run start to serve the built app locally

Core Environment Variables

TANDEM_CONTROL_PANEL_PORT (default 39732)
TANDEM_ENGINE_URL (default http://127.0.0.1:39731)
TANDEM_CONTROL_PANEL_AUTO_START_ENGINE (1 or 0)
TANDEM_CONTROL_PANEL_ENGINE_TOKEN (engine API token)
TANDEM_SEARCH_BACKEND (tandem, brave, exa, searxng, or none)
TANDEM_SEARCH_URL (default hosted Tandem search endpoint for official installs)
TANDEM_BRAVE_SEARCH_API_KEY / TANDEM_EXA_API_KEY (optional direct-provider overrides in engine.env)

Automations + Cost (Dashboard)

The main dashboard includes a first-class Automations + Cost section that aggregates:

Token usage (24h, 7d) from run telemetry.
Estimated USD cost (24h, 7d).
Top automation/routine IDs by estimated cost, token volume, and run count.

This includes legacy automations/routines and advanced multi-agent automation runs.

Cost estimation uses the engine rate:

TANDEM_TOKEN_COST_PER_1K_USD (USD per 1,000 tokens, default 0).

Control Panel Shell

The control panel now uses a shell with:

an icon rail for primary navigation
a context rail for system status and actions
a main workspace with animated route transitions and page headers

The web app intentionally pushes motion a bit further than the Tauri app while keeping the same overall visual language.

Enterprise Admin

Hosted enterprise operators can open #/enterprise-admin for tenant-scoped data governance. The page covers organization-unit taxonomy, memberships, resource/data-class grants, connector lifecycle, secret-reference credential metadata, source bindings, Google Drive preflight/import/reindex operations, quarantine review, source-object lifecycle actions, and connector impact reports.

For a client rollout, start with the Enterprise Client Onboarding Runbook, then use Enterprise Data Governance for the endpoint and policy details before using the page in a hosted deployment.

Automations Workspace (Tabbed + Wizard)

The left nav Automations page (#/automations) now uses task-focused tabs:

Create
Calendar
List
Tasks
Optimize
Active Teams
AI Composer when the feature flag is enabled

A built-in walkthrough wizard can be launched from the page header and also auto-opens for first-time empty workspaces.

The optional composer tab is designed for prompt-first workflow authoring. It reuses the existing planner chat transport, so the UI can draft an automation, ask a clarification question, preview the resulting automationsV2 payload, and then create or run it directly.

Enable it with ?composer=1 or #composer=true when the workspace has the feature flag turned on.

Legacy #/agents links continue to redirect for backwards compatibility.

AI Composer: Agent-Creation Test Mode

The AI Composer includes a test switch for agents:

send create/run requests with x-tandem-agent-test-mode: 1
set x-tandem-request-source: agent
set x-tandem-agent-id to a synthetic id you control

Use this mode only for validation:

to confirm your target agent id and capability set
to verify AUTOMATION_V2_* governance failures during development
to rehearse approval and review behavior before shipping a real external workflow creator

Create calls still use the panel engine token and the same local engine instance; only the actor classification and resulting governance checks are switched to agent mode.

Deep-link query state is supported on #/automations:

tab
wizard
flow (routine or advanced)
step
composer (1, true, on, or yes)

Studio Workflow Builder

The Studio page (#/studio) provides a template-first workflow builder for creating multi-agent workflows.

Key features:

Starter templates with editable per-agent role prompts, stage/dependency editing
Saved Studio workflow cards with latest run status and stability snapshots
Shared workspace browser for selecting workflow root folders
Direct save/run flows into automation_v2

Studio templates compile research-heavy workflows into explicit stages:

discover — File/content discovery
local-source — Local file research
external-research — Web research
finalize — Artifact writing

Planner previews also surface project-scoped knowledge defaults and rollout guardrails so operators can see when Tandem will reuse promoted knowledge before recomputing.

When you are authoring staged workflows or missions, use Prompting Workflows And Missions as the recommended guide for turning human intent into reliable Tandem prompts and handoffs.

If you want the prompt-first automation builder specifically, start with Build an Automation With the AI Assistant.

If an external agent needs to create or run those missions through the engine APIs, also use Creating And Running Workflows And Missions and Engine Authentication For Agents.

For a copy-paste, proof-style runbook for this exact path, see Automation Examples For Teams.

Saved workflows auto-migrate to workflow_structure_version = 2 while preserving automation IDs and original research node IDs used by downstream nodes.

Edit Workflow Automation Dialog (Connected Agents)

The Edit workflow automation dialog (Automations page → three-dot menu → Edit) includes a Connected agents section for three V2 automation fields:

Handoff config

Controls the directory layout for staged handoff artifacts, relative to the automation’s workspace root.

Auto-approve toggle — when on (default), deposits go directly to the approved directory; when off, they remain in the inbox until an external process or operator moves the envelope
Inbox directory — where agents write new output artifacts (default: shared/handoffs/inbox)
Approved directory — where promoted artifacts land (default: shared/handoffs/approved)
Archived directory — where old artifacts are retired (default: shared/handoffs/archived)
Reset — restores all fields to system defaults

Scope policy

Defines the filesystem sandbox for all agents in the automation. Empty = open access.

Readable paths — agents may read files at or under these paths
Writable paths — agents may write to these paths (should be a subset of readable)
Denied paths — always blocked, takes priority over readable/writable
Watch paths — paths the watch evaluator may scan; defaults to readable paths if empty
Clear — removes all restrictions (reverts to open policy)

Path entries use one path per line, prefix matching relative to workspace root.

Watch conditions

The editor currently supports only HandoffAvailable. You can optionally filter it by source automation and artifact type. It watches approved handoff envelopes; it is not a general filesystem-condition editor.

See Connected-Agent Handoffs for the supported handoff envelope, HandoffAvailable filters, scope policy, and current reliability limits.

Optimize Tab (AutoResearch)

The Optimize tab (#/automations?tab=optimize) provides a UI for workflow prompt/objective optimization campaigns.

Features:

Campaign creation with workflow selection and artifact references
Campaign detail view with experiment listing and status
Experiment inspection for reviewing candidate evaluation results
Approve/Reject/Apply controls for promotion workflow

Campaigns generate bounded candidate prompts, evaluate them against baseline runs, and apply approved winners back to the live workflow.

Available campaign actions:

queue_replay — Queue a baseline replay run to re-establish metrics
generate_candidate — Generate the next bounded candidate for evaluation
approve / reject — Mark an experiment as approved or rejected
apply — Apply an approved winner to the live workflow with drift checks and audit metadata

Workflow Operations (Packs)

The Packs area includes workflow operations so operators can validate workflow packs without leaving the control panel.

From the workflow operations view you can:

inspect loaded workflows and hooks
toggle workflow hooks on or off
run workflow validation/reload
simulate workflow events
run workflows directly
stream workflow events live while testing

This UI maps to engine workflow endpoints including:

GET /workflows
GET /workflows/{id}
POST /workflows/validate
POST /workflows/simulate
POST /workflows/{id}/run
GET /workflows/events
GET /workflow-hooks
PATCH /workflow-hooks/{id}

Orchestrator Event Streaming

The orchestrator UI supports multiplex run event streaming so multiple run timelines can stay live at once.

prefers GET /context/runs/events/stream when available on the connected engine
exposes control-panel stream health via /api/orchestrator/events/health
falls back to per-run event bridging if multiplex streaming is unavailable

Browser Diagnostics in Settings

Settings includes a Browser Diagnostics panel for operator checks.

You can use it to:

read current readiness from GET /browser/status
trigger sidecar install with POST /browser/install
run an end-to-end browser check with POST /browser/smoke-test

This panel is for browser host diagnostics. Actual browser automation still runs through the engine tool system using tools such as browser_open, browser_click, and browser_screenshot.

Provider Settings in Settings

The Providers section in Settings opens expanded by default so provider setup is visible immediately when you land there.

The control panel only asks the engine for live provider catalog data when a section actually needs it. Providers that require an API key are skipped if no key is configured, which keeps the Settings page from waiting on discovery work that cannot succeed yet.

OpenAI Codex still shows its starter catalog even before live discovery is available, so you can set defaults and connect the account without waiting for a remote model scan.

Verify Engine + Panel

curl -s http://127.0.0.1:39731/global/health \
  -H "X-Agent-Token: tk_your_token"