Skip to main content

Workstream 07: Ecosystem And Delegation

Status On develop

  • Workstream 07 is only partially shipped on develop.

Paired Research

Shipped On develop

  • SKILL.md-based skill loading
  • MCP-powered extension surface
  • runtime-managed MCP server configuration
  • catalog/install APIs for skills and MCP servers
  • recursive delegation foundations behind a feature flag
  • dynamic specialist generation for connected MCP servers
  • reusable workflow definitions that can activate across native tools, skills, specialists, and connected MCP capabilities
  • cockpit-native operator surface for workflow availability, tools, skills, starter packs, MCP server state, blocked-state reasons, and live runtime-policy visibility
  • first starter-pack bundles for recommended default skills and workflows
  • first workflow-runs history surface with boundary-aware replay metadata and artifact lineage
  • searchable capability command palette for tools, skills, workflows, starter packs, MCP actions, repair actions, and installable catalog items
  • denser operator terminal with recommendations, runbooks, repair actions, installable catalog entries, and deeper workflow timeline visibility
  • guided repair and install flows for blocked skills, workflows, tools, and MCP servers instead of only static blocked-state reasons
  • policy-aware starter-pack repair guidance, live operator-feed status, saved runbook macros, and approval-aware workflow timeline actions in the cockpit
  • capability preflight and autorepair payloads for workflows, starter packs, and runbooks before execution
  • bounded capability bootstrap that can apply safe install/repair actions for workflows, runbooks, and starter packs from the cockpit
  • workflow diagnostics that expose stored load errors plus richer step timing, error summaries, and recovery hints for extension debugging
  • threaded operator timeline surfaces for workflow runs, approvals, notifications, queued continuity, recent interventions, and surfaced failures
  • separate activity-ledger surfaces for workflow runs, approvals, notifications, queued continuity, recent interventions, surfaced failures, and attributed LLM spend instead of leaving autonomous work opaque
  • cockpit-native extension studio for workflows, skills, and MCP configs with validation, diagnostics, save flows, and repair handoff
  • first workflow branch/resume control with checkpoint candidates, lineage metadata, approval-gated resume plans, and resume drafts tied to existing inputs

Working On Now

  • this workstream shipped the first operator workflow-control slice through workflow-control-and-artifact-roundtrips-v1
  • this workstream partnered on cockpit-workflow-views-v1
  • this workstream now ships artifact-evidence-roundtrip-v2
  • this workstream now ships extension-operator-surface-v1
  • this workstream now ships capability-discovery-and-activation-v1, starter-skill-and-workflow-packs-v1, workflow-history-and-replay-v1, and extension-debugging-and-recovery-v1
  • this workstream now also ships capability-preflight-and-autorepair-v1, threaded-operator-timeline-v1, and workflow-runbooks-and-parameterized-replay-v1
  • this workstream now hands the queue forward to the full extension-platform transition program rather than isolated extension UX slices
  • the first extension-platform foundation slices now cover terminology cleanup, canonical manifests, the transitional registry seam, and structured doctor diagnostics
  • the extension-platform foundation now also pins one canonical on-disk package layout and package-boundary resolution rules for contribution files
  • the authoring path now includes first local scaffold and validation commands for capability-pack package creation instead of forcing hand-authored manifests
  • the authoring path now also includes first-class public docs for extension overview, package creation, manifest fields, contribution types, validation, and migration instead of leaving the new architecture trapped in research docs
  • the authoring path now includes one canonical in-repo example package that is validated in tests and pinned to current scaffold output so contributors and docs share the same golden reference
  • the runtime now loads manifest-backed skill contributions through the extension registry while still preserving legacy loose-skill compatibility during the coexistence window
  • the runtime now also loads manifest-backed workflow contributions through the same registry seam, including packaged workflow diagnostics and manifest-preferred duplicate resolution during the coexistence window
  • the runtime now also loads manifest-backed starter packs and explicit runbooks through the same registry seam, and the capabilities surface now publishes packaged starter-pack metadata plus extension-backed runbook entries instead of treating both surfaces as legacy-only inventory
  • startup/runtime loading now serves bundled default skills, workflows, starter packs, and explicit runbooks from a real seraph.core-capabilities package under backend/src/defaults/extensions/, with workspace extension packs taking precedence over bundled defaults while install/bootstrap/catalog flows and legacy loose-file coexistence are still being migrated
  • the backend now ships one /api/extensions lifecycle surface for list, inspect, validate, install, enable, disable, configure, and remove so automation no longer has to talk directly to per-surface skill/workflow/package seams even though the workspace UI still needs to adopt that API and the current configure step is metadata-only until typed runtime config contracts land
  • extension studio is now manifest-aware for installed packages, with package manifests and package-backed workflow/skill sources loaded and saved through /api/extensions/{id}/source instead of always collapsing edits back into loose managed-file save paths
  • new authored skills/workflows now land in the managed workspace/extensions/workspace-capabilities/ package, while bundled catalog skill installs now land as manifest-backed extension packages under workspace/extensions/; old loose loaders remain read-only compatibility during the final cleanup window
  • the trusted-code-plugins RFC is now closed for the current architecture with an explicit negative decision: Seraph continues with typed extension packs, MCP, managed connectors, and bundled native tools, not a general arbitrary-code plugin runtime

Still To Do On develop

  • bundled capability-pack auto-install and stronger policy/dependency repair beyond the first install/recommendation, preflight/autorepair, policy-aware recovery actions, installable catalog surfaces, bounded bootstrap flow, and first extension-studio save path
  • workspace lifecycle controls, richer extension health/test surfaces, and connector-aware lifecycle handling beyond the new backend /api/extensions API
  • deeper workflow operating surfaces and richer workflow history beyond the current cockpit timeline, step records, branch/resume checkpoints, replay guardrails, parameterized reruns, approval-aware recovery, diagnostics endpoint, and operator terminal
  • clearer extension ergonomics for third-party and user-authored capabilities beyond the cockpit-native operator surface, repair actions, live logs, runbooks, preflight surfaces, diagnostics, and first extension studio
  • better leverage of delegation without making the product harder to trust or reason about

Extension Platform Execution Rules

  • every numbered item below is an internal PR-sized slice, even if multiple slices are later batched into one GitHub PR
  • each slice must end with a subagent review pass for bugs, missing tests, design drift, and hallucinated assumptions before it is marked complete
  • public docs, scaffolding scripts, validation tooling, and a canonical example pack are part of the architecture transition itself, not follow-up polish
  • built-in declarative capabilities must migrate onto the same packaged extension model as user-authored capabilities before this program is considered complete
  • trusted arbitrary-code plugins are not part of the implementation path unless the final RFC explicitly approves them
  • the canonical ordered slice queue lives in the roadmap; this workstream doc summarizes the same program by phase so the queue definition does not drift across docs
  • the result of each mandatory subagent review pass must be rolled into the eventual GitHub PR Validation section before any slice is marked complete in the implementation docs

Transition Phases

Phase 1: Foundation

  • terminology cleanup for plugins versus native_tools, connectors, and capability packs
  • canonical manifest schema and typed contributes contract
  • unified extension registry and loader
  • validation and doctor outputs
  • standardized package layout

Phase 2: Authoring Path

  • scaffold and validation tools for package authors
  • first-class public docs for adding new capability packs
  • one canonical schema-valid example package for docs, tests, and future contributors

Phase 3: Declarative Capability Migration

  • manifest-backed packaging for skills
  • manifest-backed packaging for workflows
  • manifest-backed packaging for runbooks and starter packs
  • migration of bundled declarative defaults onto the same packaged extension model

Phase 4: Lifecycle And Studio

  • unified extension lifecycle API
  • manifest-aware extension studio with package manifest plus package-backed workflow/skill source editing
  • unified workspace lifecycle UI for install, validate, health, enablement, configuration, and removal, including approval-aware lifecycle recovery through Pending approvals and the inspector

Phase 5: Connector Unification

  • connector manifests and health hooks, including one normalized connector-health contract plus extension-native connector list/test endpoints
  • MCP packaging and install flow inside the extension platform, including package-owned MCP runtime metadata, extension-native connector enable/disable control, cockpit routing for packaged MCP test/toggle actions, raw /api/mcp mutation paths now blocked for extension-owned servers, and package-owned MCP definitions now read-only in Extension Studio until package-backed MCP source editing lands
  • managed connectors for curated high-trust integrations, including bundled managed connector packs plus config-aware enable/disable routed through the shared extension lifecycle instead of staying passive metadata

Phase 6: Reach Surface Migration

  • observer-source extensions, including lifecycle-backed enable/disable for observer_definitions, runtime selector overrides wired into observer refresh, and connector health that now distinguishes active, disabled, invalid, and overridden packaged observer sources
  • channel-adapter extensions, including lifecycle-backed enable/disable for channel_adapters, delivery transport selector overrides wired into proactive delivery, connector health that now distinguishes active, degraded, disabled, invalid, and overridden packaged channel transports, and an explicit boundary that the concrete websocket/native delivery implementations remain core-owned even though packaged adapters now drive selector state

Phase 7: Hardening And Completion

  • extension permissions and approvals
  • extension audit and activity visibility
  • extension versioning and update flow
  • legacy loader cleanup for primary authoring/install paths
  • trusted-code-plugins RFC concluded that privileged third-party code plugins stay out of scope for the current platform unless a future RFC reopens the decision under a much higher safety bar

Required Authoring Docs And Tools

  • public extension overview that explains typed contributions, trust tiers, and what stays core
  • step-by-step guide for creating a new capability pack
  • manifest reference with every supported field documented
  • contribution-type reference for skills, workflows, runbooks, starter packs, presets, connectors, and later observer/channel adapters
  • validation and doctor guide for package errors and repair flows
  • migration guide from loose skills/workflows/MCP configs to packaged extensions
  • local scaffold tool for generating a new extension package
  • local validation tool for checking a package before install
  • canonical example package in-repo that docs, tests, and contributors can all rely on; it should be schema-valid immediately and become runtime-backed once the packaging slices land

Non-Goals

  • extension sprawl without product coherence
  • delegation depth for its own sake

Acceptance Checklist

  • Seraph can load reusable skills and external MCP tool surfaces
  • Seraph can expose a specialist/delegation shape beyond a single monolithic agent
  • Seraph can expose reusable workflows across tools, skills, delegation, and connected MCP capabilities
  • Seraph can round-trip workflow artifacts back into both the command surface and compatible follow-on workflow drafts
  • Seraph now exposes a first cockpit-native operator surface for extension and workflow state
  • Seraph now exposes first starter packs and workflow replay history instead of leaving capability activation entirely implicit
  • Seraph now has a first "available now / blocked now / enable, install, or repair next" surface instead of only starter-pack visibility
  • Seraph now has a first live operator console for capability state, repair actions, saved runbooks, and workflow timeline recovery
  • Seraph now has a first preflight/autorepair layer for workflows, starter packs, and runbooks instead of forcing blind execution attempts
  • Seraph now has a first bounded bootstrap layer that can safely apply capability repair/install steps rather than only describing what must change
  • Seraph compounds capability through extensions and workflows in a way that is simple to operate