Studio surfaces¶

Use this reference to find the page or API area for a task. For installation and a first run, start with Get started with Studio. For the relationship between execution and stored definitions, see the Studio model.

Each section names the implementation checked for its available actions. UI source paths below are relative to apps/studio/frontend/src/; service paths are relative to lionagi/studio/services/. Navigation labels follow messages/en.json and components/shell/IconRail.tsx. Backend area names refer to service registrations; the running daemon's generated schema is the reference for exact requests and responses.

Mission Control and Attention¶

Mission Control opens an overview of work running now, recent runs, activity and reported spend, and items needing attention. Select a run to inspect its execution. Activity and spend share a time-window selector. A stale-data indicator distinguishes an interrupted refresh from a current view.

The Attention tab expands the overview's compact queue. Filter active, discharged, or all items. You can acknowledge an item as seen, or resolve, snooze, or mark an eligible item as expected. Acknowledgement keeps the item visible. Pending gates only allow acknowledgement here: follow the item to make the actual approval decision.

Backend areas: runs, invocations, schedules, stats, and attention provide the execution summaries, activity, spend, and persistent attention dispositions.

Sources: UI routes/index.tsx, components/mission/MissionControl.tsx, components/mission/AttentionQueue.tsx, and routes/attention.tsx; services runs.py, invocations.py, schedules.py, stats.py, and attention.py.

Fleet¶

Open Fleet beside Overview to browse active and past runs. Search the list, filter it by status or project, and select a row to open its detail. The project selector includes all projects and runs with no project, plus searchable project names and counts.

Run detail brings together status, recorded messages and tool results, branches, graph activity, and file links when present. Continue this run offers an instruction and branch choice for agent follow-ups. Play, flow, and show-play runs instead offer Continue to replay their saved checkpoint, without an instruction or branch selector. Missing saved state or unsupported run kinds produce an explained refusal. See the Operator guide for live-run queuing, branch selection, and the CLI escape hatch.

Backend areas: runs and sessions provide execution history and branch detail; runs also handles follow-ups, and invocations records launch context.

Sources: UI routes/fleet.tsx, components/fleet/FleetView.tsx, and components/history/ResumeRun.tsx; services runs.py, sessions.py, invocations.py, and run_resume.py.

Operator¶

Operator is a dock available across Studio. Send instructions, follow the stream, decide permission requests, or stop a turn. A successful tool result containing a run ID offers Open run; a text-only reply does not. The daemon stores conversations so they can be restored after a browser reload, and later turns can reuse the conversation's persisted branch and run record.

Backend areas: operator owns conversations, turns, streamed events, and native permission decisions; linked execution appears through runs and invocations. See Use Operator.

Sources: UI components/operator/OperatorPanel.tsx; services operator.py, runs.py, and invocations.py; conversation identity and permissions are implemented in lionagi/studio/operator/engine.py, lionagi/studio/operator/store.py, and lionagi/studio/operator/permission_mcp.py.

Schedules¶

Schedules lists standing automations in cards, a table, or a calendar. Create a schedule, enable or disable it, open its definition, edit it, request a fire, and inspect recent fire history. A fire with a linked invocation can open the corresponding execution view.

Backend area: schedules owns definitions, fire requests, history, and limits. See Automate work with schedules.

Sources: UI routes/schedules/index.tsx and components/schedules/; service schedules.py.

Library¶

Library groups reusable definitions. Browse all visible kinds together or choose a kind tab, search by name, and select an item for its detail.

The kind tabs read Agent, Playbook, Skill, Plugin, MCP Server, and Hooks.

• Agent: named profiles. Inspect their configuration and use the creation and editing controls for profiles that are not protected.
• Playbook: bundled templates and your installed playbooks. Inspect their agent, inputs, and prompt; clone a bundled template to customize it, or use Run to launch it. Bundled templates remain read-only.
• Skill and Plugin: installed instructions and packaged components. Inspect their contents and usage. Install these through their filesystem or plugin tooling; Library has no new-skill or new-plugin form.
• MCP Server: server registrations and their configuration.
• Hooks: hook assemblies and configuration.

Currently unavailable Library kinds¶

Workflow and Engine tabs are hidden, and their items are excluded from the combined list. Their backend definition services exist, but there is no usable Designer page in the current navigation. Playbooks is available.

This boundary comes from UNFINISHED_KINDS in apps/studio/frontend/src/routes/library.tsx, currently containing workflow and engine. Update this callout when entries are removed, and remove it when the set is empty. The Studio information architecture decision records the intended navigation and its implementation boundaries.

Backend areas: agents, playbooks, skills, plugins, mcp, hooks, and operator supply the visible definitions and hook settings. The workflow-defs and engine-defs areas exist independently of their hidden tabs.

Sources: UI routes/library.tsx and components/library/; services agents.py, playbooks.py, skills.py, plugins.py, mcp_servers.py, hooks_library.py, operator_hooks.py, workflow_defs.py, and engine_defs.py.

Teams¶

Teams browses crews created with li team. The list shows a team's name, member count, and last modification. Open a team to inspect its members and shared message history, shown newest first. Refresh the list or load more teams as needed. This page is a read-only browser; team creation and message sending remain in the team coordination tools.

Backend area: teams reads the team JSON files under ~/.lionagi/teams. The page is separate from Operator conversation history and Fleet runs.

Sources: UI routes/teams/index.tsx; service teams.py.

System¶

System, near the bottom of the rail, places these sections on one page:

Theme is a browser preference. Language is stored in a browser cookie and changing it reloads the page. The displayed API base and build version are read-only. This settings section does not configure provider credentials or edit the daemon's environment.

Backend area: admin supplies health, maintenance, and audit events. Data links open the engine-runs and definitions areas; appearance and language are client preferences.

Sources: UI routes/system.tsx, lib/theme.ts, and i18n/locales.ts; services admin.py, db_maintenance.py, engine_runs.py, and definitions.py.

Approvals¶

Approvals are a mechanism used by work that needs a decision, rather than a separate page. Open an attention item or the relevant run to inspect a gate. Operator displays its native permission requests directly in the conversation. Granting one request does not approve all later work.

Backend areas: approvals stores approval requests and decisions; operator handles its conversation-specific permission flow. Acknowledging an item in Attention does not grant its pending approval.

Sources: UI components/mission/AttentionQueue.tsx, components/history/RunDetail.tsx, and components/operator/OperatorPanel.tsx; services approvals.py, attention.py, and operator.py.

Projects¶

Projects attribute work to a named context. Fleet's project filter helps you find matching runs, including those with no attribution. There is no dedicated Projects page or project-management form in the current UI.

The API also provides a project registry with source, local path, repository, description, timestamps, and session counts. Its detail includes agents and playbooks used by the project's sessions. Integrations can create a Studio-managed project, update its path/repository/description, and assign specific sessions or all unassigned sessions. Assignment records a manual attribution. Deleting a registry entry is restricted to Studio-managed projects and does not delete their sessions.

Backend area: projects owns the registry and assignment operations. Fleet's project choices come from the runs area, so the filter represents attributed runs rather than a project-management screen.

Sources: UI components/fleet/ProjectFilter.tsx; services projects.py and runs.py.

Generated API reference¶

With the daemon running, open its OpenAPI schema. Use your daemon's host and port if they differ from the default. Token-protected deployments require the same bearer authentication for the schema as for API calls.

The schema is generated from the routes mounted by lionagi/studio/app.py and registered through lionagi/studio/registry.py. It describes the API of that running version, including request schemas and response shapes. Consult it for exact endpoints instead of inferring an API path from a page name.

Sources: lionagi/studio/app.py, lionagi/studio/registry.py, and the registered service modules.

For scheduling behavior, see ADR-0070.