8.9 KiB
Product Requirements Document (PRD)_ Biomimetic Agentic Orchestration Layer
Date: 2026-04-14
Status: Draft
Product Name: Project Velocity Colony Orchestration Layer
Purpose
This PRD defines the product goals, user value, scope, major capabilities, and measurable outcomes for the biomimetic orchestration layer that will combine Project Velocity's Nemoclaw-derived governance layer with a forked Open Multi Agent execution kernel.
Problem Statement
Project Velocity has many valuable intelligent surfaces, but they are still too fragmented:
- Oracle has strong planning and canvas concepts
- CRM now has a real backend and writeback paths
- Catalyst has real backend behavior and UI
- Sentinel has live signal ingestion and reasoning paths
- MCP and Nemoclaw append layers exist
What is missing is a robust orchestration layer that can coordinate these systems reliably, safely, and modularly.
The current state creates five business problems:
- Valuable domain logic exists in separate islands.
- Prompt engineering is not yet a governed subsystem.
- Tool and data routing are still too implicit.
- Multi-step goals require bespoke chains instead of reusable mission flows.
- Result quality varies because decomposition, evidence gathering, and review are not standardized.
Product Vision
Create a colony-style orchestration platform that receives a high-level user goal and turns it into a governed mission executed by specialized agents that:
- plan
- research
- retrieve internal context
- execute task-specific work
- aggregate results
- review the result once
- return a final answer or domain action
The product must feel cohesive at the user layer and modular at the engineering layer.
Product Goals
Primary Goals
The system must let Project Velocity convert ambiguous goals into structured, auditable, multi-agent execution across Oracle, CRM, Catalyst, and future surfaces.
The system must preserve governance and safety through external policy controls rather than trusting worker prompts alone.
The system must remain extensible, so new agent roles, domain adapters, tools, and model providers can be introduced without redesigning the whole stack.
Secondary Goals
The system should improve latency and quality by parallelizing independent work and reducing unnecessary context sharing.
The system should learn from prior successful patterns through prompt templates, artifact registries, and pheromone-style telemetry.
The system should allow progressive productization:
- internal operator use first
- assisted customer-facing use next
- higher autonomy only after domain hardening
Non-Goals
This release is not intended to be:
- a generic public AI operating system from day one
- a long-running checkpoint-heavy workflow engine in Sprint 1
- a replacement for the root FastAPI backend
- a replacement for Oracle v1 canvas
- a replacement for Sentinel ownership
Product Users
Primary Users
Internal operators using Oracle, CRM, Catalyst, or research workflows.
Secondary Users
Sales and strategy operators who need:
- lead analysis
- project intelligence
- campaign planning
- internal synthesis
System-Level Consumers
Project Velocity modules themselves:
- Oracle
- CRM
- Catalyst
- Sentinel
- future Dream Weaver orchestration
Core User Stories
Mission Decomposition
As an operator, I want to submit a high-level goal and have the system break it into explicit, traceable task units so I can trust how work is being performed.
Prompt Specialization
As an operator, I want the system to create better task-specific prompts than a generic coordinator would produce, so specialist agents receive clearer instructions.
Internal Knowledge Routing
As an operator, I want relevant CRM, Oracle, project, and asset context routed automatically to workers without exposing unrelated data.
External Research
As an operator, I want the system to gather external evidence with citations and provenance so outputs are grounded rather than invented.
Aggregation and Review
As an operator, I want a final result that has already been synthesized and reviewed once so I see a clean answer, not a pile of partial agent outputs.
Safe Writeback
As a product owner, I want writebacks to CRM or Oracle to be explicit, validated, and auditable before they change product state.
Product Capabilities
Capability 1: Mission Intake
The system accepts a goal from:
- Oracle
- CRM
- Catalyst
- internal operations
It normalizes the goal into a mission object with budgets, risk, scope, and output targets.
Capability 2: Planner
The planner converts the mission into a task DAG with:
- dependencies
- role requirements
- evidence needs
- success criteria
Capability 3: Prompt Master
The prompt master produces worker-ready prompt packages using:
- templates
- exemplars
- mission constraints
- task type metadata
Capability 4: Research
The research subsystem acquires public information through search and browsing and returns evidence packets with citations.
Capability 5: Librarian Routing
The librarian subsystem issues scoped access passes for internal knowledge and cached artifacts.
Capability 6: Worker Execution
Workers execute task-specific prompts with bounded tools and scoped context.
Capability 7: Aggregation and Review
Results are aggregated into one structured answer and then reviewed once before final delivery.
Capability 8: Governance
Nemoclaw-style policy controls mediate:
- model routing
- tool access
- external network calls
- writeback actions
- audit logging
Product Requirements
Must-Have Requirements
The product must support mission decomposition, prompt packaging, internal retrieval routing, external research, worker execution, aggregation, review, and final delivery.
The product must expose audit traces for all mission steps.
The product must allow domain adapters for Oracle, CRM, Catalyst, and Sentinel.
The product must separate planning logic from execution logic.
The product must provide structured internal artifacts, not only free-form chat.
Should-Have Requirements
The product should support multiple model providers in one mission.
The product should support human approval gates for sensitive missions.
The product should keep reusable prompt and artifact histories.
The product should expose observability for latency, cost, and failure hotspots.
Could-Have Requirements
The product could later support:
- long-running mission resumes
- colony simulation dashboards
- community-contributed specialist packs
- adaptive self-tuning role selection
Success Metrics
Quality Metrics
- percentage of missions completed without manual intervention
- percentage of final outputs approved without manual rewrite
- evidence citation coverage for research missions
- contradiction detection rate during review
Operational Metrics
- average mission latency by mission type
- average token cost by mission type
- retry frequency
- writeback rejection rate
Product Metrics
- number of Velocity surfaces successfully using the colony layer
- number of mission templates reusable across domains
- reduction in bespoke one-off prompt chains
Release Strategy
Phase 1
Build the colony kernel and run Oracle and CRM missions in assisted mode.
Phase 2
Add Catalyst missions and stronger research workflows.
Phase 3
Introduce Sentinel evidence feeds and more controlled automation.
Key Trade-Offs
Open Multi Agent gives speed, simplicity, and dynamic decomposition, but it does not provide production-grade persistence or governance by itself.
Nemoclaw-style governance gives safety and bounded execution, but if over-applied it can slow down iteration and developer ergonomics.
The correct product strategy is therefore:
- Open Multi Agent fork as execution kernel
- Nemoclaw-derived policy layer as guard plane
- Project Velocity root as source of truth for domain state
Risks
Architectural Risk
If the system becomes too generic, it will not solve Velocity's real domain problems.
Safety Risk
If governance remains prompt-level instead of infrastructure-level, the system will be brittle.
Product Risk
If prompt packaging and librarian routing are not formalized early, the colony will look clever in demos but fail under production variance.
Acceptance Criteria
The PRD is satisfied when the first working product release can:
- receive a real goal from Oracle or CRM
- create a mission and task graph
- assign specialized workers
- route internal and external context correctly
- produce an aggregated and reviewed answer
- log every material step
- block disallowed tool or writeback behavior
Bottom Line
This product is the missing orchestration spine for Project Velocity.
It should not be built as a monolithic assistant. It should be built as a biomimetic colony runtime with strict interfaces, external governance, and domain-aware adapters.