Skip to main content

Platform Layer Implementation

→ Implementation Index | Previous: Foundation Layer | Next: Application Layer

Phase 2: Platform Layer​

The platform layer builds on the foundation by hardening plugin, session, and extensibility behavior in the current stack. It does not assume that deferred agent-platform* package names have already been approved as V6 deliverables.

Core Platform Implementation​

Plugin Framework

  • Improve plugin lifecycle behavior through existing SDK, compiler, and plugins/* surfaces → Plugin Ecosystem
  • Validate plugin dependency and manifest handling against current install and packaging flows
  • Treat marketplace, governance, and isolation work as measured slices, not abstract platform promises
  • Describe metaplugins as capability composition above concrete plugin and hook bundles, without requiring a new package boundary

Session Management Evolution

  • Clarify session ownership across packages/babysitter-agent, packages/sdk, and plugin integration points
  • Improve persistence, context propagation, and recovery only where the current runtime already exposes those seams
  • Keep session changes rollbackable and testable without introducing broad cross-package churn

Candidate Slice Areas​

Metaplugin Composition

  • Document composition rules for higher-order capability bundles on top of current plugin and hook surfaces
  • Validate whether hook-type extension or pipeline processing can remain internal to current packages
  • Promote a standalone package only if a later ADR proves that the seam reduces coupling more than it adds API surface

Orchestration Integration

  • Keep Babysitter orchestration integration expressed through current packages and plugin bundles
  • Treat orchestration-plugin vocabulary as exploratory only unless a decision record changes its classification
  • Preserve process-library and SDK integration as present-day implementation surfaces

If a future standalone package is ever pursued here, it should host proved composition logic rather than replace concrete plugin packaging. The current repository evidence still treats unified plugins and per-harness bundles as the install surfaces, with agent-plugins-mux compiling those outputs.

Deliverables​

  • Improved plugin/session documentation and implementation slices within current packages
  • Manifest, install, and recovery validation for the plugin and session flows actually shipped today
  • Evidence for or against deeper platform extraction recorded as ADR inputs
  • Tooling and plugin integration still working through the current architecture surfaces

Technical Validation​

Plugin Compatibility Testing: Manifest correctness, install flows, and generated bundle behavior → Testing Framework

Session Persistence Validation: Recovery and consistency verification in the packages that currently own session state

Dependency Resolution Checks: Correctness verification only for logic that already exists or is being added as a bounded slice

Cross-Platform Compatibility: Windows, macOS, Linux validation for current commands and plugins

Deferred Vocabulary Guardrail: @a5c-ai/agent-platform, @a5c-ai/agent-platform-meta-plugins, and @a5c-ai/agent-platform-orchestration-plugin remain non-deliverables in this phase

Explicit Non-Deliverables​

This phase does not create new agent-platform* top-level packages. It only earns the right to propose them later by proving real seams in current-package work.

Related Documents: Foundation Layer | Plugin Ecosystem | Security Architecture