# 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: 1. Valuable domain logic exists in separate islands. 2. Prompt engineering is not yet a governed subsystem. 3. Tool and data routing are still too implicit. 4. Multi-step goals require bespoke chains instead of reusable mission flows. 5. 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.