{
  "id": "page:docs-v6-spec-and-roadmap-architecture-comparison",
  "_kind": "Page",
  "_file": "wiki/docs/v6-spec-and-roadmap/architecture-comparison.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/v6-spec-and-roadmap/architecture-comparison.md",
    "sourceKind": "repo-docs",
    "title": "V6 Architecture Comparison",
    "displayName": "V6 Architecture Comparison",
    "slug": "docs/v6-spec-and-roadmap/architecture-comparison",
    "articlePath": "wiki/docs/v6-spec-and-roadmap/architecture-comparison.md",
    "article": "\n# V6 Architecture Comparison\n\n## Overview\n\nThis document provides an architectural comparison between the current a5c.ai agent stack and the V6 architecture, highlighting the key differences in design philosophy, component organization, and system capabilities.\n\n**Target Audience**: Architects, engineers, and system designers evaluating the V6 architectural approach\n\n## Architectural Philosophy Comparison\n\n### Current Architecture Philosophy\n\n**Monolithic Integration**\n- Single large package (`babysitter-agent`) containing all functionality\n- Tight coupling between components\n- All-or-nothing deployment model\n- Shared state and configuration across all features\n\n**Characteristics**:\n- Simple deployment (single package)\n- High coupling, low cohesion\n- Difficult to isolate functionality\n- Large bundle sizes for all use cases\n\n### V6 Architecture Philosophy\n\n**Layered Plugin Architecture**\n- Clear separation between runtime, platform, and application layers\n- Plugin-first design with metaplugins as a higher-order composition layer over plugins and hooks\n- Selective deployment and functionality composition\n- Isolated state management with defined interfaces\n\n**Characteristics**:\n- Selective deployment (compose functionality)\n- High cohesion, low coupling\n- Clear functional boundaries\n- Optimized bundle sizes for specific use cases\n\n## Component Organization Comparison\n\n### Current Component Structure\n\n```\nMonolithic Package Structure\n├── @a5c-ai/babysitter-agent (all functionality)\n│   ├── governance/ (policies, authorities, sandbox)\n│   ├── session/ (state, context, history, memory)\n│   ├── mcp/ (channels, transport, client tools)\n│   ├── harness/ (adapters, agentic tools)\n│   ├── cost/ (tracking, observability)\n│   ├── daemon/ (infrastructure)\n│   └── pi/ (wrapper integration)\n└── Supporting packages\n    ├── @a5c-ai/hooks-mux\n    ├── @a5c-ai/agent-plugins-mux\n    └── @a5c-ai/babysitter-sdk\n```\n\n### V6 Component Structure\n\n```\nLayered Architecture\n├── Infrastructure Layer (Dispatch/Mux)\n│   ├── @a5c-ai/agent-mux (unchanged)\n│   ├── @a5c-ai/hooks-mux (evolved from hooks-mux)\n│   └── @a5c-ai/agent-plugins-mux (evolved from agent-plugins-mux)\n├── Runtime Layer (Engine)\n│   └── @a5c-ai/agent-runtime (filesystem-free core)\n├── Platform Layer (Persistence + Plugins)\n│   ├── @a5c-ai/agent-platform (plugin system host)\n│   └── @a5c-ai/agent-platform-meta-plugins (extensibility)\n├── Orchestration Layer (Domain-Specific)\n│   ├── @a5c-ai/agent-platform-orchestration-plugin\n│   ├── @a5c-ai/babysitter-sdk (unchanged)\n│   └── @a5c-ai/babysitter-agent (complete solution)\n└── Supporting Packages\n    ├── @a5c-ai/catalog\n    ├── @a5c-ai/observer-dashboard\n    └── @a5c-ai/babysitter-tui-plugins\n```\n\n## Key Architectural Differences\n\n### 1. Filesystem Dependencies\n\n**Current**: Mixed filesystem access throughout all components\n**V6**: Clear filesystem boundary - runtime layer filesystem-free, platform layer handles persistence\n\n### 2. Plugin System\n\n**Current**: Limited extensibility, hard-coded functionality\n**V6**: Meta-plugin framework for composing capability concerns above concrete plugin and hook surfaces\n\n### 3. Session Management\n\n**Current**: Monolithic session handling\n**V6**: Layered session management - in-memory runtime sessions + persistent platform sessions\n\n### 4. Tool Integration\n\n**Current**: Direct integration in monolithic package\n**V6**: Plugin-based tool ecosystem with replaceable implementations\n\n### 5. Event System\n\n**Current**: Internal event handling\n**V6**: Structured event-driven protocol between layers\n\n## Deployment Pattern Comparison\n\n### Current Deployment\n\n**Single Package Model**:\n- Install `@a5c-ai/babysitter-agent`\n- Get all functionality regardless of needs\n- Large bundle size for all use cases\n- Monolithic configuration\n\n**Bundle Characteristics**:\n- One deployable carries the full feature set and its resource costs together\n- Memory and startup costs are coupled to the monolith rather than to a selected slice\n- All features are always loaded\n\n### V6 Deployment Options\n\n**Selective Deployment**:\n- **Runtime Only**: `@a5c-ai/agent-runtime` for embedded use\n- **Platform Core**: Add `@a5c-ai/agent-platform` for plugin hosting\n- **Complete Solution**: Add `@a5c-ai/babysitter-agent` for full orchestration\n\n**Bundle Characteristics**:\n- Runtime, platform, and complete deployments can be measured independently once slice-specific commands exist\n- Complete deployments are composed as needed\n- Selective imports can reduce shipped code for narrower deployments, but the amount must be proven per slice\n\n## Functional Capability Comparison\n\n### Current Capabilities\n\n**Integrated Features**:\n- ✅ Pi wrapper integration\n- ✅ Governance and policy system\n- ✅ Session management and continuity\n- ✅ MCP integration\n- ✅ Cost tracking and monitoring\n- ✅ Daemon infrastructure\n- ✅ Observability features\n\n**Limitations**:\n- ❌ Cannot use subset of features\n- ❌ Cannot extend with custom functionality\n- ❌ Cannot replace built-in implementations\n- ❌ Large resource footprint for simple use cases\n\n### V6 Capabilities\n\n**Layered Features**:\n- ✅ All current functionality maintained\n- ✅ Selective functionality composition\n- ✅ Plugin-based extensibility\n- ✅ Custom implementation replacement\n- ✅ Optimized resource usage\n- ✅ Meta-plugin framework\n\n**Enhancements**:\n- ✅ Dynamic plugin loading\n- ✅ Plugin marketplace support\n- ✅ Network-distributed plugins\n- ✅ Plugin dependency management\n- ✅ Hook type extensions\n- ✅ Context variable systems\n\n## Performance Characteristics\n\nThis comparison is intentionally qualitative. Broad bundle, memory, and latency figures were removed from the normative architecture comparison until a benchmark harness and release gate exist for a concrete slice.\n\n### Current Performance Profile\n\n**Resource Usage**:\n- Resource usage is measured at the monolith level rather than at a slice level\n- Startup and tool overhead include the cost of loading the integrated feature set\n- Fine-grained attribution is difficult because the deployment unit is broad\n\n**Characteristics**:\n- All functionality loaded regardless of use\n- No selective optimization possible\n- Fixed performance profile\n\n### V6 Performance Profile\n\n**Resource Usage**:\n- Resource usage should be measured per deployment slice rather than inferred globally\n- Runtime-only, platform, and complete deployments may each carry different baselines\n- Any startup, memory, or overhead target requires a named benchmark command and fallback plan\n\n**Characteristics**:\n- Pay-for-what-you-use resource model\n- Selective optimization opportunities\n- Performance tuning per deployment pattern\n\n## Development Experience Comparison\n\n### Current Development\n\n**Characteristics**:\n- Single large codebase\n- High blast radius for changes\n- Difficult component isolation for testing\n- Monolithic build and deployment\n\n**Developer Impact**:\n- Simple mental model (everything in one place)\n- Difficult to work on isolated features\n- Large-scale coordination required for changes\n- Limited extensibility options\n\n### V6 Development\n\n**Characteristics**:\n- Clear architectural layers and boundaries\n- Isolated component development\n- Focused testing and validation\n- Incremental build and deployment\n\n**Developer Impact**:\n- More complex mental model initially\n- Clear domain boundaries enable focused work\n- Independent component evolution\n- Extensive extensibility through plugins\n\n## Extension and Customization\n\n### Current Extension Model\n\n**Limitations**:\n- Fork-based customization\n- No plugin system\n- Hard-coded functionality\n- Difficult to maintain custom variations\n\n### V6 Extension Model\n\n**Capabilities**:\n- Plugin-based customization\n- Meta-plugin framework for deep extensions built atop plugin and hook surfaces\n- Hook type extensions\n- Network-distributed functionality\n- Plugin marketplace ecosystem\n- Semantic versioning and dependency management\n\n## System Integration Comparison\n\n### Current Integration Patterns\n\n**Agent-Mux Integration**: Direct integration with monolithic interface\n**Hook Integration**: Via hooks-mux with limited extensibility\n**MCP Integration**: Built-in MCP client functionality\n\n### V6 Integration Patterns\n\n**Agent-Mux Integration**: Layered integration with clear protocol boundaries\n**Hook Integration**: Via hooks-mux with meta-plugin composition over concrete hook and plugin surfaces\n**MCP Integration**: Plugin-based MCP integration with replaceable implementations\n\n## Summary\n\nThe V6 architecture represents a fundamental shift from monolithic integration to layered plugin architecture, providing:\n\n**Key Improvements**:\n- **Selective Deployment**: Compose functionality based on actual needs\n- **Extensibility**: Meta-plugin framework enables deep customization\n- **Performance**: Resource optimization through selective loading\n- **Development**: Clear boundaries enable focused development\n\n**Trade-offs**:\n- **Complexity**: More complex initial mental model\n- **Coordination**: More components require interface coordination\n- **Learning**: Plugin development requires understanding of plugin patterns\n\nThe V6 architecture is designed for organizations that need selective functionality, extensibility, and performance optimization, while the current architecture serves well for simple, all-inclusive deployment scenarios.\n\n---\n\n**Document Status**: Draft  \n**Architecture Responsibility**: Architecture Team\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-v6-spec-and-roadmap",
      "to": "page:docs-v6-spec-and-roadmap-architecture-comparison",
      "kind": "contains_page"
    }
  ]
}