Studio dashboard integration and backend follow-up¶
Status: Current | Last reviewed: 2026-09-23
This record covers the dashboard design merged into the standalone prototype in
studio/real/apps/ai-manager. The production app under apps/ai-manager is a
separate source tree.
The non-conversational-generation design has now been ported into the real app; see Studio UI rollout for its implemented contracts, permissions and validation. This document retains the prototype decisions and the original gap assessment below. The conversational workspace remains deferred.
The rollout resolves the editor-preservation, author-visible Home, persisted favorites/recents, creator metadata and draft/failure-count gaps identified here. Conversational authoring, brief persistence, scenario execution and knowledge workspace integration remain separate follow-up work.
Design authority and decisions¶
The real app defines capabilities, permissions, configuration shapes and runtime semantics. The dashboard ZIP is a designer's visual and interaction reference. Its implementation is not an API contract.
Source: trueserve-dashboard.zip, SHA-256
6fa88f8c684a90518c5576745b0e197611116a54eeddaf6cb7677c69e6273b28.
Its single HTML file is preserved in studio/dashboard/index.html.
The running application does not embed that HTML or load its React/Babel/Tailwind CDN scripts.
Decisions confirmed during integration:
- Operational Home is the landing page, with Design with AI opening the existing conversation and design-brief workspace.
- All five agent types stay in one Agents repository. Background agents retain their workflow runtime, IDs and editor.
- Keep the real app's current subagent approach. The designer's nested reusable agent graph is not adopted. Subagent prompts, scopes and transitions remain in the real prompt editor; canvas nodes continue to describe topology.
- Archive and Unpublish stay out of the working UI. They are future lifecycle work, not local status toggles.
Adopted design¶
| Area | Implementation | Functional source |
|---|---|---|
| Brand | Open Sans, teal sidebar #457F7B, bright teal accent #00ABAB, neutral #F5F5F5 surfaces, Deloitte mark and green dot |
Dashboard reference, adapted to existing HSL theme tokens |
| Navigation | Expanded on browse pages, compact in editors; Home, Design with AI, Agents, Tools, Configuration | Existing permission and feature gates |
| Home | Search, creation controls, portfolio, recent activity, attention panel, favorites and conversational design entry | Existing repository/favorites APIs and /api/dashboard/summary |
| Agent repository | Cards by default, optional compact list, search, type/status/date filters, favorites, recent visits, sorting and pagination | Real agent/workflow rows; no designer sample records or invented timestamps |
| Card management | Existing tags, clone, export, delete, access and background-agent activation controls remain in Manage | Original management components |
| Creation | Design with AI plus the original manual wizards, templates, runtime/integration selection and imports | Existing brief flow and real wizards |
| Editor | Teal accents and selection treatment; existing canvas, inspector, expanded editor, prompt/actions, preview, settings, activity, versions and publish controls | Real editor components and config |
| Insights | Deferred; old /dashboard/insights bookmarks return to Home. Conversation history keeps its existing route. |
Reporting composition retained as an unmounted component; protected APIs retained for future review |
Home's attention panel derives failed-run entries from the returned workflow summary and draft entries from the current repository. It is not an exhaustive alert engine: the summary's top-workflow list is bounded. No inactivity, test-recency or percentage-change claims are fabricated. Recent activity is paged in groups of five on Home; Insights retains its ten-row feed. Home also supports users who can only manage background agents.
“My recents” means agents opened by the current user in this browser. It uses
studio:recent-agents:v1:<tenant>:<user>, retains at most 100 IDs/timestamps,
and never writes view state into runtime config. “My agents” needs creator
information; it is unavailable when that information is absent instead of
behaving like the ZIP's ineffective filter.
Capabilities preserved¶
| Capability family | Where it remains available |
|---|---|
| Voice, chat, copilot, translation and background creation | Agents → New agent; original manual wizards and template flows |
| Conversational generation/design | Design with AI → conversation, Flow, Systems, Behavior, Scenarios and Knowledge; saved briefs and agent-draft creation |
| Real runtime/provider/integration choices | Systems and the full agent editor |
| Prompt authoring | Behavior → Main/subagent scopes, @/{{ menus, snippets, action library and action settings |
| Logic and capabilities | Existing conditions, Run/Set statements, variables, response guards, rules, capability settings and auto-injections |
| Pipeline topology | Existing stages, structural nodes, branches, lanes, connections and canvas controls |
| Subagents | Existing in-conversation scopes/transitions and separate-call configuration; no new referenced-agent tree |
| Versioning | Draft creation, autosave, read-only published versions, version selector, publish and existing version restore behavior |
| Agent administration | Settings, branding, sharing/access, export, tags, clone, delete, activity and performance |
| Background automation | Existing graph, node configuration, phases/foreach, triggers, activation, test runs and execution history |
| Preview | Existing phone/chat/media previews and fullscreen controls; the ZIP's static phone does not replace them |
| Platform administration | Tools/templates, integrations, tenants, groups, roles, secrets, settings and feature gates |
| Operational reporting | Original KPI, changes, performance, top-agent/background-agent, tool-health and word-cloud views under Insights |
The unified repository replaces the default table presentation, not its management capabilities. Simulator/emulator navigation stays removed as previously requested; in-editor preview remains.
Applying the design to the current app¶
The following is a source review of apps/ai-manager on 2026-09-10, not a
verification of deployed service availability. The prototype's browser tests
use MSW and do not establish live API permissions, persistence or runner health.
The visual identity, navigation, combined repository and original management controls can largely use existing backend contracts. The conversational workspace has additional integration and persistence work. Its authoring quality also requires a separate conversational authoring research spike: experience probing, grounded template/capability discovery, and coordinated generation of branded multimodal catalogs for the agent. API connectivity alone does not deliver that authoring capability.
| When needed | Gap and evidence | Work to deliver functionality |
|---|---|---|
| Before any production merge | The exported editor predates newer production features. Current SubagentTabs offers Smart/Guided creation; PromptSection also contains guided steps and procedure authoring. ServiceConfigForm includes auxiliary-service and newer provider controls. | Apply the design diff onto current components. Preserve current forms, types, validation, real collab, service definitions and runtime setup. Do not replace the production tree with the ZIP or import prototype startup/mock changes. |
| Before Home rollout | StudioDashboard requests the summary for ManageAgents users, but the summary API requires ManageConfiguration. Authors without that permission would receive 403s. |
Agree which author-visible metrics Home should expose, then use an appropriately scoped summary contract and matching frontend gates. Do not simply expose the entire admin aggregate. Handle background-only users and keep restricted Insights data gated. |
| Before live Design with AI | ChatPanel, description regeneration and suggestions use mock functions and simulated streaming. Generations and assistant sessions already exist in the real app. | Connect real progress, questions, streaming, errors, retry/cancel and draft updates. Reuse AI generation availability: deployment flag, tenant enablement and active runner integration. Verify runner connectivity. This is integration work, not a need for a new model service. |
| Before saving real design work | Brief storage is browser-local and its key has no tenant/user namespace. Existing assistant sessions require an existing agent/workflow target and do not store the structured Studio brief. | Decide between a draft-backed workspace from the start and a standalone brief before agent creation. Persist structured briefs with tenant/user ownership, restore and revision handling; link the conversation and resulting draft. Browser-local storage cannot be the sole authoritative store for production design work. |
| Before promising executable generation | The brief adapter already calls the existing create contract with a selected stack, prompt and tool refs. Flow steps, suggested subagents and behavioral boundaries become prose; they do not become executable graph nodes, subagent config or enforced guards. Further brief edits do not update the created agent. | Define which brief fields become runtime config and which remain planning notes. Use current generation discovery/validation and draft mutation paths, preserve required tool/integration inputs, and reconcile accepted changes with the editor's collab state. Establish one authoritative draft so AI and manual edits do not overwrite each other. |
| Before Knowledge promises ingestion | KnowledgeTab stores references. Production already has source creation, file upload, sync and status APIs; these require ManageTools. |
Map workspace sources to real Knowledge source/tool IDs, upload bytes or configure URLs, show actual indexing errors/status, and attach the resulting tool to the draft. Respect tenant Knowledge configuration and author permissions. Collections need an explicit mapping to the existing source model. |
| Before Run scenarios is a real test | ScenariosTab generates transcripts/outcomes locally with timers. Production scale-testing types already model customer scenarios, execution and assessment; its job API is admin-gated. | Map authored scenarios and expected behavior to test scripts/criteria, select the target version and required test/evaluator integrations, run real jobs, and persist transcripts/results with version attribution. Add an author-appropriate orchestration/permission layer if exposing this outside admin testing. The existing engine does not make this workspace button functional automatically. |
| Repository integration | The production recents API and useRecents/recordRecent helpers already support persisted visits. Creator metadata is missing from the list contract. Workflow lists expose has_draft; the agent list selects one preferred version. |
Replace the prototype's local recents tracker with existing APIs. Expose consistent creator metadata before enabling My agents. Distinguish published state, draft existence, actual unpublished changes and background activation; do not use one status label to infer all four. |
| Before richer attention claims | The summary's top-workflow query is limited to ten busiest workflows and counts only error, while the KPI query counts error and failed. Current draft counts are derived from each repository row's selected version, not every identity with a draft. |
Keep initial wording limited to the data actually returned, or add the comprehensive aggregate. Align failure statuses, define draft-only versus published-with-draft counts, and add last-tested/inactivity/baseline data only when those indicators are introduced. |
The immediate implementation sequence is:
- Merge brand/navigation/repository into the current app, align Home access, reuse recents, and verify existing authoring/management against live APIs.
- Run the separate conversational authoring spike to define guidance, discovery, builder integration and state ownership. Use its findings to scope Design with AI integration with the existing generation/assistant machinery and make the design-to-config boundary explicit.
- Connect Knowledge and scenario execution before presenting those controls as operational. They can remain clearly scoped planning features or be withheld while the basic redesign ships.
The substantial product decision is whether an agent draft exists from the first design message. Creating one early allows reuse of target-bound assistant sessions. Keeping a separate pre-agent brief preserves the current prototype sequence but requires a persistent brief/session contract and a defined handoff to generation. Neither option requires replacing the existing agent runtime.
Live acceptance checks still needed: author/admin/background-only access, tenant switching and brief isolation, create/edit/save/reload, published immutability, current guided/procedure controls, AI/manual collab interaction, imports, real preview, and knowledge/test error recovery where enabled.
Backend follow-up¶
These are gaps or future design items, not features claimed to work now.
| Request from the design | Existing support | Required work / decision | Current prototype treatment |
|---|---|---|---|
| My agents | Agent identity has creator metadata, but the conversational list's buildPipelineSelect/rowToPipeline contract does not expose it; background lists also lack a consistent ownership field |
Expose tenant-scoped created_by/owner metadata consistently on both lists; decide whether “mine” means creator, owner or editable-by-me |
Creator filter only works when metadata is supplied; otherwise unavailable with explanation |
| Recents across devices | Production already has user/tenant-scoped GET/POST /api/recents, plus useRecents and recordRecent; the new prototype does not use them |
Reuse the existing persisted visits API; only add clear/retention behavior if required beyond its current contract | Local browser visits only; integration gap, not a new backend |
| Archive / restore archived | Background activation exists; it is not an archive lifecycle for conversational agents | Identity-level archived state, archive/restore endpoints, list filtering, audit, permissions, runtime eligibility and treatment of schedules/exposures | Omitted |
| Unpublish | Publish/version/traffic APIs exist; there is no conversational-agent unpublish endpoint in this snapshot | Specify whether one version or all exposures are withdrawn; handle traffic, CCaaS/API access, active sessions, rollback and audit atomically | Omitted; never rewrite a published version into a draft |
| Linked reusable subagents | Current config.topics and config.subagents author behavior within the parent; they are not the ZIP's agentId graph |
Product decision first; if needed, define pinned vs floating version references, cross-agent permission checks, context/tool boundaries, cycle/depth limits, delegation and trace attribution | Not adopted; current subagent UX retained |
| Arbitrary canvas groups/branch templates | Real lanes, routers, prompt conditions, workflow graph and lifecycle hooks exist, with specific contracts | Map each desired operation to a supported construct before adding it. Arbitrary fan-out/group nodes need schema, runtime, validation, collab and export changes if no construct fits | Existing topology operations retained; no third graph format |
| Attach a workflow to any structural stage | Start/end lifecycle hooks and workflow tools already exist | Arbitrary-stage hooks require defined cadence, payload/result mapping, timeout/failure behavior and runtime support | Use existing lifecycle/tool configuration |
| Comprehensive Needs attention | Summary has workflow error aggregates; tool-health endpoint exists; per-agent usage is available through optional stats | Add an exhaustive tenant-scoped attention aggregate for errors/inactivity/test recency, thresholds, permissions, timestamp basis and drill-through IDs; acknowledgement/snooze needs persistence if requested | Show only issues supported by returned data; detailed tool health remains in Insights |
| “Not tested in 30 days” | Conversation history distinguishes tests, but current dashboard summary does not expose per-agent last-tested time | Query/aggregate last test by agent and version; distinguish a test attempt from a passing evaluation | Omitted from attention claims |
| “+12% vs average” | Existing KPI counts and range selection | Comparable baseline period and percentage-change definitions in the summary contract | No invented trend percentages |
| Published with unpublished changes on repository cards | Version detail supports draft/published state; workflow lists already expose has_draft, but agent lists do not consistently expose both versions or a meaningful draft diff |
Reuse workflow draft metadata, expose equivalent agent metadata, and define dirty/diff semantics; having a draft alone must not imply changed content | Display the state actually returned; retain full version controls in editor |
| Card brand/customer logos | Real agent branding uses surface_config_id; the ZIP hardcodes customer logos |
Resolve approved brand metadata/assets through existing branding APIs if card logos are required | Use type accents, without invented customer associations |
| Generic queue priority, max queue, storage region, retention selectors | Existing routing/transfer, compliance and recording controls have specific runtime contracts | Validate each proposal against those contracts; per-agent retention/storage placement needs policy enforcement and migration design, not an unconnected select box | Original functional settings retained; mock-only selectors excluded |
| Natural-language repository search | Current search matches names, descriptions, tags, type labels and IDs | Semantic indexing/retrieval, authorization filtering and a query API if intent-based search is wanted | Keyword search, no inference claims |
| Review pins/comments | ZIP has browser-only designer annotations | Shared comment storage, stable anchors/version references, permissions, resolution and notifications if made into a product capability | Designer review tooling not copied into the product |
Existing backend, missing prototype mocks¶
Do not classify these as net-new production capability:
- Import endpoints/reference mapping already exist in the real app. The standalone mock backend does not create imports.
- Copy full prompt has a production renderer; the standalone prototype has an intentional unavailable response.
- Actual model generation, voice/provider calls, scenario execution and knowledge ingestion need live services. The conversation-design brief and scripted scenarios remain explicitly scoped prototype behavior.
Verification¶
Run the prototype on port 3100, then run:
cd studio/real/apps/ai-manager
npm run typecheck
npx eslint components/studio hooks/studio lib/studio components/app-sidebar.tsx
npx playwright test --config playwright.studio.config.ts
Browser coverage should include the landing route, brand styles, dashboard search/filter links, repository cards/list, filters/favorites/recents, permissions, creation/import dialogs, conversation-to-draft flow, prompt typing/autocomplete/action dialogs, persistence and mobile navigation.