Files
Project_Velocity/.Agent Context/Sprint 1/Biomimetic Agentic Orchestration Layer/Sprint 1 Plan_ Biomimetic Agentic Orchestration Layer.md

375 lines
8.2 KiB
Markdown

# Sprint 1 Plan_ Biomimetic Agentic Orchestration Layer
**Date:** 2026-04-14
**Status:** Proposed Sprint 1 execution plan
**Program:** Project Velocity Colony Orchestration Layer
## Purpose
This plan defines the first implementation sprint for the biomimetic colony orchestration layer. The sprint goal is not full autonomy. The sprint goal is to create the minimum production-grade orchestration spine that can be integrated into Project Velocity without destabilizing the current root.
## Sprint 1 Goals
Sprint 1 must validate four architectural truths:
1. A forked Open Multi Agent kernel can be adapted into a Project Velocity orchestration service.
2. Nemoclaw-derived governance can sit outside worker prompts and still allow useful execution.
3. Oracle and CRM can use the colony runtime through explicit adapter boundaries.
4. The biomimicry role model can be implemented as a disciplined architecture rather than only a metaphor.
## Sprint 1 Scope
### In Scope
- fork plan and package structure
- mission envelope schema
- task graph schema
- prompt package schema
- first colony runtime skeleton
- planner role
- prompt master role
- librarian role
- researcher role stub with provider interface
- worker execution
- aggregation and review roles
- policy gateway abstraction
- Oracle adapter
- CRM adapter
- mission and artifact persistence
- observability and audit baseline
### Out of Scope
- autonomous public posting
- full Sentinel autonomy
- long-running checkpoint resume
- multi-tenant public marketplace
- generalized self-modifying colony behavior
## Sprint 1 Deliverables
### Deliverable 1: Architecture Package
This document set plus the PRD, SRS, and first-principles design documents.
### Deliverable 2: Repo Structure Proposal
Recommended structure:
```text
services/
colony-orchestrator/
src/
core/
planner/
prompt-master/
librarian/
researcher/
workers/
aggregator/
reviewer/
policy/
adapters/
schemas/
telemetry/
backend/
services/
colony_gateway.py
api/
routes_colony.py
```
### Deliverable 3: Mission and Artifact Schemas
Versioned JSON contracts for:
- mission envelope
- task graph
- prompt package
- librarian pass
- research artifact
- worker result
- aggregation packet
- review packet
### Deliverable 4: Oracle Adapter MVP
Ability for Oracle to submit one mission class:
- structured advisory mission
- plan
- retrieve
- execute
- aggregate
- return answer and optional writeback proposal
### Deliverable 5: CRM Adapter MVP
Ability for CRM to submit one mission class:
- lead intelligence mission
- internal context retrieval
- optional external research
- worker synthesis
- review
- structured output
### Deliverable 6: Governance MVP
Policy checks for:
- allowed tools
- allowed network families
- allowed writebacks
- model routing class
### Deliverable 7: Observability MVP
Traces and audit events for:
- mission created
- tasks planned
- prompts generated
- tools called
- policy decisions
- final output approved
## Milestones
### Milestone 1: Fork and Runtime Skeleton
Expected outcome:
- create fork boundary
- isolate upstream kernel primitives
- define service packaging
### Milestone 2: Artifact Contracts
Expected outcome:
- all core mission artifacts versioned
- planners and adapters code against stable schemas
### Milestone 3: Planner, Prompt Master, Librarian
Expected outcome:
- decomposition flow exists
- prompt packages exist
- librarian passes exist
### Milestone 4: Oracle and CRM Integration
Expected outcome:
- at least two real mission classes run through the colony
### Milestone 5: Governance and Review Closure
Expected outcome:
- review pass and policy gating both function
## Workstreams
### Workstream A: Fork and Service Boundary
Tasks:
- fork Open Multi Agent into a dedicated service boundary
- preserve MIT license and attribution
- define which upstream files remain core and which become Velocity-specific extensions
Acceptance criteria:
- service starts independently
- upstream kernel compiles
- Project Velocity extension folders exist cleanly
### Workstream B: Artifact and Schema Layer
Tasks:
- define schema files
- version artifact envelopes
- add validation utilities
Acceptance criteria:
- invalid mission and artifact payloads are rejected deterministically
- every pipeline stage reads and writes explicit typed artifacts
### Workstream C: Colony Roles
Tasks:
- implement planner role
- implement prompt master role
- implement librarian role
- implement aggregator role
- implement reviewer role
Acceptance criteria:
- mission can move through all five stages with traceable artifacts
### Workstream D: Research and Tooling
Tasks:
- define external search provider interface
- define browser provider interface
- define citation artifact shape
Acceptance criteria:
- a research task can return structured evidence with provenance
### Workstream E: Governance
Tasks:
- define policy decision contract
- classify tool families
- classify model routing tiers
- validate writeback actions
Acceptance criteria:
- a blocked tool or blocked writeback is rejected before execution and logged
### Workstream F: Velocity Adapters
Tasks:
- Oracle adapter MVP
- CRM adapter MVP
- request and response mapping
- artifact persistence linkage
Acceptance criteria:
- Oracle and CRM can each run one real mission class through the colony
## Suggested Roles
Suggested engineering ownership:
- orchestration kernel engineer
- policy and safety engineer
- backend integration engineer
- prompt systems engineer
- QA and observability engineer
These can be combined if team size is small, but the role boundaries should remain explicit.
## Timeline
### Week 1
- finalize fork boundary
- define schema layer
- stand up runtime skeleton
- implement planner and prompt master contracts
### Week 2
- implement librarian and research interfaces
- implement aggregator and reviewer
- add audit traces
### Week 3
- integrate Oracle mission
- integrate CRM mission
- add governance gates
### Week 4
- run end-to-end test scenarios
- harden observability
- finalize Sprint 1 review package
## Acceptance Criteria by Sprint End
Sprint 1 is successful if the team can demonstrate:
- one Oracle mission running through the colony end to end
- one CRM mission running through the colony end to end
- task DAG decomposition with explicit artifact traces
- prompt packages created by a dedicated prompt master stage
- librarian passes routing internal knowledge
- at least one external research step with citations
- aggregation and one-pass review
- policy rejection for at least one disallowed action
## Risks and Mitigation
### Risk 1: Overbuilding the metaphor
Mitigation:
Treat each ant role as a software responsibility with a schema and interface, not as narrative decoration.
### Risk 2: Open Multi Agent becomes too invasive
Mitigation:
Keep the fork behind a dedicated service boundary. Avoid scattering upstream assumptions through the Python root.
### Risk 3: Governance slows the system too much
Mitigation:
Apply risk-tiered policy. Not every mission needs the heaviest controls.
### Risk 4: Prompt Master becomes an opaque black box
Mitigation:
Version templates, examples, and outputs. Evaluate prompt packages with golden tests.
### Risk 5: Librarian becomes a data leak vector
Mitigation:
Use explicit passes with resource family scopes and expirations.
## Architectural Decisions to Validate in Sprint 1
The sprint should explicitly validate:
- TypeScript colony runtime plus Python root is a workable split
- mission persistence is needed immediately, not later
- one-pass review is enough for normal missions
- librarian-pass routing materially improves quality and cost
- prompt-master separation improves worker quality
## Repository Placement
This Sprint 1 artifact set belongs under:
- `.Agent Context/Sprint 1/`
Implementation work should likely land under:
- `services/colony-orchestrator/`
- `backend/services/`
- `backend/api/`
## Bottom Line
Sprint 1 should not try to build the whole ant colony civilization.
Sprint 1 should prove the minimum viable colony:
- plan
- route
- execute
- review
- govern
- integrate with Oracle and CRM
If those six things work cleanly, the rest of the ecosystem can grow on top of a stable spine.