Skip to content

Crew Capability Architecture

Date: 2026-04-04 Author: Architect (Sean Galliher) Status: Design Document — connects existing ADs into a unified personnel management model Triggered by: Gap analysis of how ProbOS defines agent Role, Skills, Tools, Qualifications, Duties, and Privileges

1. Problem Statement

ProbOS has built substantial infrastructure for agent identity, skills, memory, trust, and procedures — but these systems are designed in parallel, not connected end-to-end. The result is that we cannot answer the fundamental workforce management question:

"What can this agent do, and why?"

A Navy personnel officer can look up any sailor and see: Rating (job), NECs (qualifications), PQS status (certifications), assigned equipment (tools), current watch station (duty), service record (history), and rank (authority). ProbOS has analogs for all of these, but no unified model connecting them.

The Fragmentation

Capability Aspect ProbOS Component AD Location Connected To
Role definition Standing Orders + Ontology Post AD-339/429a Config + YAML ✅ compose_instructions()
Skill tracking Skill Framework AD-428 skill_framework.py ❌ Not wired to tool access
Qualification testing Qualification Battery AD-566 qualification.py ❌ Not wired to skill proficiency
Tool access Tool capabilities (schema only) AD-423 resources.yaml ❌ No runtime code
Duty assignment Pool + Intent Bus Core agent_onboarding.py ✅ Functional but static
Authority/Privileges Earned Agency AD-357 earned_agency.py ✅ Gates actions
Learned abilities Executable Skills + Cognitive JIT AD-531-539 procedures.py + types.py ✅ Procedural replay works
Personnel records Episodic Memory + Ship's Records AD-434/441 episodic.py + identity.py ✅ Separate systems
Crew roster Agent Fleet startup Core agent_fleet.py ❌ Hardcoded, no manifest

What "Connected" Looks Like

When a new crew member is onboarded, the system should be able to:

  1. Look up their Post (organization.yaml) → determines department, chain of command, authority
  2. Load their Role Template (skills.yaml) → determines required skills and proficiency targets
  3. Assign Tool Access (resources.yaml) → determines which tools they can use, gated by rank
  4. Check Qualification Status (qualification.py) → determines if they've demonstrated competency
  5. Load Procedures (procedure_store.py) → determines what they can do without LLM reasoning
  6. Apply Standing Orders (standing_orders/) → determines behavioral guidance
  7. Set Earned Agency (earned_agency.py) → determines action space based on trust

Currently, steps 1, 6, and 7 work. Steps 2-5 exist as independent systems with no connecting fabric.

2. The Navy Model

The U.S. Navy's personnel management system provides the organizing metaphor. ProbOS already uses naval terminology — this document formalizes the mapping.

┌─────────────────────────────────────────────────────────────┐
│  SAILOR'S SERVICE RECORD                                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  RATING (Job Category)                                      │
│  ├─ e.g., MM (Machinist's Mate), ET (Electronics Tech)     │
│  ├─ Determines: training pipeline, career path, billets    │
│  └─ ProbOS: Agent Type + Ontology Post                     │
│                                                             │
│  NECs (Navy Enlisted Classifications)                       │
│  ├─ Specific skill qualifications beyond rating             │
│  ├─ Earned through: schools, OJT, demonstrated competency  │
│  ├─ e.g., NEC 4234 (Nuclear Propulsion Plant Operator)     │
│  └─ ProbOS: Skill Framework (AD-428) proficiency records   │
│                                                             │
│  PQS (Personnel Qualification Standards)                    │
│  ├─ Formal competency certification process                 │
│  ├─ Study → Practical Demo → Oral Board → Sign-off         │
│  ├─ Required before standing a watch                        │
│  └─ ProbOS: Qualification Battery (AD-566)                 │
│                                                             │
│  AUTHORIZED EQUIPMENT                                       │
│  ├─ Ship's equipment the sailor is qualified to operate     │
│  ├─ Gated by: NEC + PQS + rank + commanding officer        │
│  ├─ e.g., can operate the lathe, cannot operate the reactor │
│  └─ ProbOS: Tool Registry (AD-423) — NOT YET BUILT         │
│                                                             │
│  WATCH STATION                                              │
│  ├─ Current duty assignment on the watch bill               │
│  ├─ Requires: PQS qualification for that station            │
│  ├─ Rotation: 3-section, port/starboard, etc.              │
│  └─ ProbOS: Pool + Intent Bus + Watch Manager              │
│                                                             │
│  PMS CARDS (Planned Maintenance System)                     │
│  ├─ Procedural checklists for maintenance tasks             │
│  ├─ Define: steps, tools required, qualifications needed    │
│  ├─ Tracked: completion, periodicity, deferred items        │
│  └─ ProbOS: Cognitive JIT Procedures (AD-531-539)          │
│                                                             │
│  STANDING ORDERS                                            │
│  ├─ Rules of engagement for the watch                       │
│  ├─ Hierarchy: OPNAV → fleet → ship → department → watch   │
│  └─ ProbOS: Standing Orders (AD-339) 4-tier hierarchy      │
│                                                             │
│  RANK / RATE                                                │
│  ├─ Authority level determining scope of action             │
│  ├─ Earned through: time-in-rate + PQS + eval + board      │
│  └─ ProbOS: Earned Agency (AD-357) trust-based rank        │
│                                                             │
│  SERVICE RECORD                                             │
│  ├─ Complete career history                                 │
│  ├─ Evaluations, awards, qualifications, assignments        │
│  └─ ProbOS: Episodic Memory + Ship's Records + DIDs        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Key Navy Insight: Tools ≠ Personnel

In the Navy, a wrench has no personality. A Machinist's Mate is qualified to operate a lathe (NEC/PQS), and the lathe is ship's equipment (inventoried, maintained, tracked). The MM's qualification certifies they can use the tool safely. Different MMs may have different tool qualifications.

ProbOS's "everything is an agent" model conflated the sailor and the lathe. FileReaderAgent is both "the tool" and "the agent." The Three-Tier Architecture (AD-398) acknowledged this by classifying agents as infrastructure/utility/crew, and Asset Tags (AD-441c) formalized the identity split ("Even microwaves get serial numbers. But a serial number is not a birth certificate."). The next step is making infrastructure/utility agents into tools that crew agents can use.

3. The Hybrid Architecture

Design Decision: Keep Both, Connect Them

The "everything is an agent" model provides genuine architectural advantages at the infrastructure layer:

  1. Observability — every operation flows through the intent bus, auditable and interceptable
  2. Distributability — in federation, any agent could be on a different node
  3. Evolvability — infrastructure agents can get smarter over time
  4. Uniform protocol — IntentMessage/IntentResult for everything

These advantages are real and worth preserving. The solution is not to replace agents-as-tools, but to add a tool binding layer on top that gives crew agents composable capabilities while infrastructure agents continue doing the actual work.

Four Capability Tiers for Crew Agents

The original three-type model (Tools, Learned Skills, Cognitive Capabilities) is refined into four tiers that separate agent identity from task-specific cognitive skills. This distinction was driven by BF-146 (standing orders conflating identity and capabilities caused confabulation) and research into the AgentSkills.io ecosystem (AD-596).

┌─────────────────────────────────────────────────────────────┐
│  CREW MEMBER CAPABILITY PROFILE                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  T1. STANDING ORDERS (identity + behavioral standards)      │
│  ├─ Defined by: 4-tier .md hierarchy (federation/ship/      │
│  │   dept/agent) — WHO the agent IS                         │
│  ├─ Always loaded: full content in system prompt every cycle│
│  ├─ Not task-specific — defines role, personality, values,  │
│  │   chain of command, communication protocols              │
│  └─ Examples: federation.md, science.md, architect.md       │
│                                                             │
│  T2. COGNITIVE SKILLS (task-specific instruction-defined)    │
│  ├─ Defined by: SKILL.md files (AgentSkills.io standard)   │
│  ├─ Discovered by: description matching at intent time      │
│  ├─ Loaded on-demand: descriptions in context, full         │
│  │   instructions injected when skill activates             │
│  ├─ Gated by: department, rank, proficiency (optional)     │
│  ├─ Interoperable: standard format shared with 30+ tools   │
│  ├─ Self-improving: usage feeds Cognitive JIT (T2→T3)      │
│  └─ Examples: architecture-review, trust-analysis,          │
│     threat-assessment — things requiring LLM judgment       │
│                                                             │
│  T3. EXECUTABLE SKILLS (deterministic procedures)           │
│  ├─ Acquired through: Cognitive JIT (experience, AD-531+)  │
│  ├─ Proficiency tracked: Skill Framework (Dreyfus levels)  │
│  ├─ Execute: directly on agent (no bus, no LLM at L4+)     │
│  ├─ Trust-gated: compilation level by rank                 │
│  └─ Examples: agent-specific procedures, optimized flows   │
│                                                             │
│  T4. ASSIGNED TOOLS (ship's equipment)                      │
│  ├─ Defined by: Role Template (ontology) + Rank            │
│  ├─ Gated by: Trust tier (Earned Agency) + Qualification   │
│  ├─ Execute via: Infrastructure Agents (intent bus)         │
│  ├─ Registered in: Tool Registry (AD-423)                  │
│  └─ Examples: read_file, search_codebase, ward_room_post   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

T2→T3 Self-Improvement Pathway

Cognitive skills (T2) feed into executable skills (T3) through the Cognitive JIT pipeline:

Agent uses T2 cognitive skill (LLM-mediated, SKILL.md instructions)
        │
        │ Cognitive JIT observes execution (AD-531)
        ▼
Procedure extracted (AD-532) → stored (AD-533)
        │
        │ Graduated compilation through Dreyfus levels (AD-535)
        ▼
At L4+ (Autonomous): becomes T3 executable skill (zero tokens)
        │
        │ If T3 replay fails (AD-534b):
        ▼
Fallback to T2 cognitive skill (LLM re-engagement)

This is the "skills that self-improve through use" pattern observed in Hermes Agent. ProbOS already has the pipeline (AD-531-539); AD-596 provides the T2 file format to feed it.

How They Interact

Intent arrives at agent
        │
        ▼
   ┌─────────┐
   │  T3     │──yes──► Executable Skill handler (no LLM, no bus)
   │ Skill?  │         Learned through Cognitive JIT
   └────┬────┘
        │ no
        ▼
   ┌─────────┐
   │  T2     │──yes──► Load SKILL.md instructions → LLM decide()
   │ Skill?  │         Discovered by description, loaded on-demand
   └────┬────┘
        │ no
        ▼
   ┌─────────┐
   │  T4     │──yes──► Tool binding → Infrastructure Agent (via bus)
   │  Tool?  │         Assigned by role, gated by rank
   └────┬────┘
        │ no
        ▼
   ┌─────────┐
   │ Handled │──yes──► Full cognitive lifecycle (perceive/decide/act)
   │ Intent? │         LLM-powered reasoning per Standing Orders (T1)
   └────┬────┘
        │ no
        ▼
    Decline (return None)

4. Tool Type Taxonomy

A "tool" in ProbOS is any capability a crew agent can invoke. The delivery mechanism is irrelevant — what matters is: does the agent have access, and can it execute? AD-422 defines 8 categories; this section maps those to the runtime abstraction the Tool Registry (AD-423) must support.

Tool Types

Type Description Execution Model Examples
Onboard Utility Agent ProbOS agents that provide capabilities as tools. No sovereign identity. Intent bus → agent.handle_intent() BuilderAgent, CodeReviewerAgent, SkillEngine
Infrastructure Service Ship's Computer services. Shared substrate, always available. Direct function call (same process) CodebaseIndex, EpisodicMemory, TrustNetwork
MCP Server Standardized JSON-RPC protocol tools. Hot-pluggable. stdio/HTTP JSON-RPC per MCP spec Filesystem MCP, Postgres MCP, Serena (LSP)
Remote API / LLM Gateway Cloud services over HTTP/SDK. Token-metered. HTTP request/response or SDK call Copilot SDK, GitHub API, Anthropic API
Computer Use Desktop/GUI automation. Highest risk category. Vision model + input simulation PyAutoGUI, Anthropic Computer Use
Browser Automation Web interaction via DOM or accessibility tree. Playwright/Puppeteer + browser DevTools Page navigation, form filling, screen reading
Communication Channel Outbound messaging to humans/external systems. Protocol-specific adapter Discord, Slack, Email, Webhooks
Federation Service Capabilities sourced from other ProbOS ships. Federation gossip protocol Cross-ship queries, fleet-wide Hebbian
Deterministic Function Pure code procedures with no LLM. Executable Skills from Cognitive JIT. Direct function call (handler invocation) Learned procedures at L4+, compiled skills

Key Design Insight: Adapter Uniformity

From the crew member's perspective, all tool types look identical. The crew member says "search the codebase" — whether that invokes CodebaseIndex directly, an MCP server, or a federated query on another ship is an adapter implementation detail behind the Tool protocol (AD-423a).

The AgenticToolAdapter (AD-543/unified-tool-layer.md) is a specialization for tools that run their own agentic loop (e.g., BuilderAgent, Copilot SDK). A single ToolRegistry registers both simple tools and agentic tools — the difference is execution duration and token cost, not protocol.

Deterministic Functions (Executable Skills as Tools)

This is the OpenClaw pattern. Cognitive JIT (AD-531-539) extracts procedures from LLM-guided experience and compiles them into deterministic handlers. At Dreyfus Level 4+ (Autonomous), these execute with zero tokens — no LLM call, pure code replay.

These are both skills (tracked in Skill Framework for proficiency) and tools (registered in Tool Registry for access). The distinction: - As a skill: Proficiency level, how it was learned, when it was last used, Ebbinghaus decay - As a tool: Can it be invoked right now? Does this agent have permission? What inputs/outputs?

This dual registration is how the capability profile stays unified — one system tracks competency, another tracks access.

Cognitive Skills (AgentSkills.io Format — AD-596)

Cognitive skills are the T2 capability tier: task-specific, instruction-defined capabilities stored as SKILL.md files following the AgentSkills.io open standard. They fill the gap between standing orders (T1, always-loaded identity) and executable skills (T3, deterministic procedures).

AgentSkills.io standard format:

skill-name/
  SKILL.md          # Required: YAML frontmatter + markdown instructions
  scripts/          # Optional: executable code
  references/       # Optional: documentation
  assets/           # Optional: templates, resources

Progressive disclosure model: 1. Discovery (~100 tokens per skill): Name + description loaded at startup into CognitiveSkillCatalog 2. Activation (<5000 tokens): Full SKILL.md instructions loaded when intent matches description 3. Resources (as needed): Supporting files loaded only when referenced

ProbOS metadata extensions (via standard metadata field — external skills work without these): - probos-department — department scoping for discovery - probos-skill-id — bridge to SkillRegistry (AD-428) proficiency tracking - probos-min-proficiency — Dreyfus-level activation gate - probos-min-rank — Earned Agency activation gate - probos-intents — declares handled intents (replaces hardcoded _handled_intents)

Interoperability: AgentSkills.io is adopted by 30+ tools including Claude Code, Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenHands, Hermes Agent, Roo Code, OpenAI Codex, and JetBrains Junie. Skills authored for any of these tools can be consumed by ProbOS agents, and ProbOS-authored skills can be consumed by other platforms. The ProbOS metadata extensions are ignored by other platforms (they use the standard metadata field, which is explicitly extensible).

Validation: The AgentSkills.io ecosystem provides skills-ref — a Python library (Apache 2.0) with validate(), read_properties(), and to_prompt(). ProbOS extends this with domain-specific linting: ontology cross-references, callsign detection (BF-146 pattern), instruction staleness detection. This addresses the "Natural Language as Code" design principle — instruction-defined capabilities need structural validation, not just output evaluation.

Prior art comparison:

System Format Discovery Governance Self-Improvement
AgentSkills.io SKILL.md (YAML + markdown) Description matching File-based (git) None natively
Microsoft Business Skills Dataverse entity Metadata query Dataverse RBAC None
Hermes Agent AgentSkills.io Skills Hub (644 skills) 4 registries Procedural memory evolution
ProbOS (AD-596) AgentSkills.io + metadata Description + ontology Department/rank/proficiency Cognitive JIT (T2→T3)

5. Task → Skill → Tool Execution Flow

The Question

"What happens when an agent receives a task that requires a skill, and that skill requires a tool?"

This is the core execution flow that connects all the capability systems. Three scenarios:

Scenario 1: LLM Reasoning Needs Tool Mid-Thought

The agent is doing cognitive work (perceive/decide/act) and needs to invoke a tool as part of its reasoning.

Intent: "analyze module X for performance issues"
Agent: LaForge (Engineering Chief)

1. handle_intent() → no matching executable skill
2. decide() invoked → LLM begins reasoning
3. LLM identifies need: "I need to read the module source"
4. Tool call: read_file(path="src/probos/module_x.py")
   ├─ Check: Does LaForge have read_file tool assigned? → Yes (role: chief_engineer)
   ├─ Check: Does LaForge's rank permit this? → Yes (Lieutenant+ for filesystem read)
   └─ Execute: FileReaderAgent via intent bus → returns file content
5. LLM continues reasoning with file content
6. LLM identifies need: "I need to check performance metrics"
7. Tool call: query_metrics(agent_id="module_x")
   ├─ Check: tool assigned? → Yes
   ├─ Check: rank permits? → Yes
   └─ Execute: VitalsMonitor via intent bus → returns metrics
8. LLM completes analysis → act() returns IntentResult

This is the AD-543 (Native SWE Harness) model. The AgenticLoop manages the interleaved text + tool_use + tool_result conversation. ToolExecutor handles permission checks and execution dispatch. Each tool call goes through the Tool Registry for authorization.

Scenario 2: Learned Procedure Has Steps Requiring Tools

The agent has a Cognitive JIT procedure for this task, compiled to Level 3+ (Validated). The procedure steps reference tools.

Intent: "run standard health check on module X"
Agent: Chapel (Chief Medical)

1. handle_intent() → matches executable skill "standard_health_check"
2. Skill handler invoked (no LLM call)
3. ProcedureStep 1: collect_vitals
   ├─ required_tools: [vitals_query]          ← NEW FIELD on ProcedureStep
   ├─ tool_context.has_tool("vitals_query")   ← NEW: scoped tool access
   └─ Execute: tool_context.invoke("vitals_query", params={...})
4. ProcedureStep 2: compare_baselines
   ├─ required_tools: [knowledge_query]
   └─ Execute: tool_context.invoke("knowledge_query", params={...})
5. ProcedureStep 3: generate_report
   ├─ required_tools: []  (pure computation)
   └─ Execute: handler logic only
6. Return result (zero LLM tokens consumed)

What needs to be added: - ProcedureStep.required_tools: list[str] — declares which tools each step needs - ToolContext — a scoped, permission-filtered view of the Tool Registry passed to skill handlers - SkillHandler(intent, tool_context) — skill handlers receive tool access as a parameter

Scenario 3: Skill Handler Can't Complete Without Tool — Fallback

The procedure exists but a required tool is unavailable (permission denied, tool offline, federation timeout).

Intent: "search for security vulnerabilities in module X"
Agent: Worf (Chief Security)

1. handle_intent() → matches executable skill "vulnerability_scan"
2. Skill handler invoked
3. ProcedureStep 1: read_module_source
   ├─ required_tools: [read_file]
   └─ Execute: tool_context.invoke("read_file", params={...}) → SUCCESS
4. ProcedureStep 2: run_static_analysis
   ├─ required_tools: [static_analyzer]
   └─ Execute: tool_context.invoke("static_analyzer") → TOOL UNAVAILABLE
5. FALLBACK CASCADE:
   ├─ Level 1: Retry with alternative tool (if registered)
   ├─ Level 2: Degrade to LLM-guided reasoning (re-enter decide() for this step)
   └─ Level 3: Escalate via chain of command (report inability, request assistance)
6. Worf escalates step 2 to LaForge who has static_analyzer access

The Fallback Cascade

Executable Skill (zero tokens)
        │
        │ tool unavailable / step failure
        ▼
LLM-Guided (decide() with tool context, costs tokens)
        │
        │ LLM can't resolve / permission denied
        ▼
Chain of Command Escalation (request assistance from peer/superior)
        │
        │ no one can help / critical failure
        ▼
Report to Bridge (Captain/XO informed of capability gap)

This cascade means agents degrade gracefully rather than failing hard. A missing tool doesn't halt the agent — it triggers the same chain of command that a human crew would use: try yourself, ask for help, escalate to command.

ToolContext: The Permission-Filtered View

ToolContext is NOT the full Tool Registry. It is a scoped view created for each agent based on:

  1. Role template — which tools the agent's post is assigned (from resources.yaml/skills.yaml)
  2. Rank — Earned Agency level determines read/write/execute permissions per tool
  3. Qualification — PQS completion may unlock additional tool access (AD-566f bridge)
  4. Department — some tools are department-scoped (e.g., security tools only for Security dept)
  5. Captain overrides — explicit grants/denials from the Captain
# Conceptual API (AD-423a design target)
class ToolContext:
    """Scoped, permission-filtered tool access for a specific agent."""

    def available_tools(self) -> list[ToolDescriptor]: ...
    def has_tool(self, tool_id: str) -> bool: ...
    async def invoke(self, tool_id: str, **params) -> ToolResult: ...
    # invoke() checks permissions internally — no way to bypass

The ToolContext is constructed at onboarding (wire_agent()) and updated when rank changes, qualifications are earned, or Captain overrides are applied. Crew agents never see the raw Tool Registry — they see their ToolContext.

6. The Connection Map

What's Built (solid lines) vs What's Needed (dashed lines)

                    STANDING ORDERS (AD-339) ✅
                    ┌─────────────────────┐
                    │  Federation → Ship  │
                    │  → Dept → Agent     │
                    │  Behavioral guidance │
                    └─────────┬───────────┘
                              │ shapes reasoning
                              ▼
┌──────────────┐    ┌─────────────────────┐    ┌──────────────────┐
│  VESSEL      │    │  CREW MEMBER        │    │  EARNED AGENCY   │
│  ONTOLOGY    │───►│                     │◄───│  (AD-357) ✅     │
│  (AD-429) ✅ │    │  Agent Type + Post  │    │  Trust → Rank    │
│              │    │  Department         │    │  Rank → Actions  │
│  8 domains   │    │  Chain of Command   │    │  Gates tool use  │
└──────┬───────┘    └────────┬────────────┘    └──────────────────┘
       │                     │
       │ defines             │ has
       ▼                     ▼
┌──────────────┐    ┌─────────────────────┐    ┌──────────────────┐
│  ROLE        │- - │  SKILL PROFILE      │    │  QUALIFICATION   │
│  TEMPLATE    │    │  (AD-428) ✅        │◄ - │  BATTERY         │
│  skills.yaml │    │                     │    │  (AD-566) 🔧     │
│  ✅ schema   │    │  PCCs + Role Skills  │    │  Tests → scores  │
│  ❌ not wired│    │  + Acquired Skills   │    │  Baseline + drift│
│  at onboard  │    │  Proficiency levels  │    │  ❌ not wired to │
└──────┬───────┘    └────────┬────────────┘    │  skill proficiency│
       │                     │                 └──────────────────┘
       │ requires            │ qualifies for
       ▼                     ▼
┌──────────────┐    ┌─────────────────────┐    ┌──────────────────┐
│  TOOL        │- - │  TOOL ACCESS        │    │  COGNITIVE JIT   │
│  REGISTRY    │    │  (TOOL BINDINGS)    │    │  (AD-531-539) ✅ │
│  (AD-423) ❌ │    │                     │    │                  │
│  Designed    │    │  Which tools this   │    │  Procedures →    │
│  Not built   │    │  agent can invoke   │    │  Executable      │
│              │    │  Gated by rank +    │    │  Skills          │
│              │    │  qualification      │    │  Zero-token      │
└──────┬───────┘    └────────┬────────────┘    │  replay at L4+   │
       │                     │                 └──────────────────┘
       │ provides            │ executes via
       ▼                     ▼
┌──────────────┐    ┌─────────────────────┐
│  INFRA       │    │  INTENT BUS         │
│  AGENTS      │◄───│  (Core) ✅          │
│  (AD-398) ✅ │    │                     │
│              │    │  Observable,         │
│  FileReader  │    │  distributable,     │
│  FileWriter  │    │  auditable          │
│  Shell       │    │                     │
│  HttpFetch   │    │                     │
│  CodebaseIdx │    │                     │
└──────────────┘    └─────────────────────┘

Legend: ✅ Built | 🔧 Building | ❌ Not built | - - Connection needed

The Six Missing Connections

# Connection From → To What It Does Enabling AD
C1 Role → Tool Assignment skills.yaml role_template → Tool Registry At onboarding, assign tools to agent based on role AD-423 + new wiring
C2 Qualification → Skill Proficiency AD-566 test results → AD-428 AgentSkillService Passing a qualification test updates skill proficiency AD-566f (new)
C3 Qualification → Tool Authorization AD-566 completion → Tool Registry permissions Completing PQS unlocks tool access AD-423 + AD-566f
C4 Skill Proficiency → Earned Agency AD-428 proficiency levels → promotion requirements Qualification paths gate rank advancement AD-566/428 bridge (exists in AD-539 gap predictor, needs formalization)
C5 Tool Registry → Onboarding AD-423 → agent_onboarding.py Wire tool bindings during wire_agent() AD-423
C6 Crew Manifest → Unified Query All systems → single API "What can this agent do?" query AD-513

7. The AD Landscape

Built ADs (Foundation Layer)

AD Name What It Provides Status
AD-339 Standing Orders 4-tier behavioral guidance hierarchy ✅ Complete
AD-357 Earned Agency Trust-based rank gating action space ✅ Complete
AD-398 Three-Tier Architecture Crew/Utility/Infrastructure classification ✅ Complete
AD-422 Tool Taxonomy 8-category tool classification + design doc ✅ Complete
AD-428 Skill Framework Competency tracking, proficiency, qualification paths ✅ Complete
AD-429a-e Vessel Ontology 8-domain formal model (org, crew, skills, resources, etc.) ✅ Complete
AD-441a-c Persistent Identity DIDs, birth certificates, asset tags ✅ Complete
AD-496-498 Workforce Scheduling Work items, bookings, calendars, scrumban ✅ Complete
AD-531-539 Cognitive JIT Procedure extraction, replay, gap detection, qualification triggering ✅ Complete

Building ADs (In Progress)

AD Name What It Provides Status
AD-566a Qualification Harness Test protocol, store, harness engine ✅ Complete
AD-566b Tier 1 Baseline Tests Personality, memory, confabulation probes 🔧 Builder
AD-566c Drift Detection Pipeline Scheduled testing, statistical thresholds, alerts Planned
AD-566d Tier 2 Domain Tests Role-specific competency tests Planned
AD-566e Tier 3 Collective Tests Crew-wide coordination measurement Planned

Unbuilt ADs (Connection Layer)

AD Name What It Provides Gap It Fills Dependencies
AD-423 Tool Registry Runtime tool catalog, permissions, scoping, discovery C1, C3, C5 AD-422 (done), AD-398 (done)
AD-483 Tool Layer — Instruments Tool base class, ToolRegistry class, tool trust C1 (programming model) AD-423 (scope overlap — reconcile)
AD-438 Ontology-Based Task Routing Directed assignment using role + skills + tools Routing optimization AD-429 (done), AD-428 (done), AD-423
AD-513 Crew Manifest Unified queryable crew roster C6 AD-429 (done), AD-441 (done), AD-357 (done)
AD-543-549 Native SWE Harness ToolCall protocol, agentic loop Tool execution model AD-423

New ADs Needed

AD Name What It Provides Gap It Fills
AD-566f (new) Qualification → Skill Bridge Test results update Skill Framework proficiency C2
AD-423+ (new scope) Role-Based Tool Assignment At onboarding, assign tools from role template C1, C5
AD-423+ (new scope) Qualification-Gated Tool Access PQS completion unlocks tool permissions C3

8. AD-423 and AD-483: Reconciliation

AD-423 and AD-483 both define "Tool Registry" but from different angles:

Aspect AD-423 AD-483
Focus Operational management Programming abstraction
Scope Permissions, scoping, lifecycle, discovery Tool base class, ToolRegistry class, trust
Designed in tool-taxonomy.md (detailed) roadmap feature spec
Key features CRUD+O permissions, dept scoping, Captain overrides Tool base class, Beta-distribution trust, MCP compat
Overlapping ToolRegistry class, tool registration ToolRegistry class, tool registration

Recommendation: Merge into a single AD sequence (AD-423a/b/c):

  • AD-423a: Tool Foundation — Tool protocol + ToolRegistry class + registration schema (absorbs AD-483's programming model)
  • AD-423b: Tool Permissions & Scoping — CRUD+O permissions, department scoping, Earned Agency gates, Captain overrides (AD-423's operational model)
  • AD-423c: Role-Based Tool Assignment — Onboarding wiring, role template → tool bindings, qualification gates (the new connection layer)

This gives us the Tool abstraction, the permission model, and the onboarding wiring in a clean build sequence.

9. Build Order

The build order respects dependencies and maximizes value at each step:

Phase A: Complete Testing Infrastructure (current)

AD-566a ✅ → AD-566b 🔧 → AD-566c → AD-566d → AD-566e

Establishes the measurement framework before making changes. All testing infrastructure in place.

Phase B: Tool Foundation

AD-423a (Tool protocol + ToolRegistry)
  → AD-423b (Permissions + scoping + Earned Agency gates)
    → AD-423c (Role-based assignment at onboarding)

The keystone. Gives crew agents composable tool access. Infrastructure agents become "ship's equipment" that crew agents can use through tool bindings.

Phase C: Connect the Dots

AD-566f (Qualification → Skill Bridge)
  → AD-513 (Crew Manifest — unified query)
    → AD-438 (Ontology-Based Task Routing)

Closes the remaining connections. Qualification results flow into skill proficiency. Crew Manifest provides the "what can this agent do?" query. Task routing uses the full capability profile for intelligent assignment.

Phase D: Memory Architecture (existing plan)

AD-567a → AD-567b (absorbs AD-462) → AD-567c → AD-567d
  → AD-566 re-run (measure impact)
    → AD-567e → AD-567f → AD-567g

Memory improvements, measured against the baselines established in Phase A.

Phase E: Advanced Integration

AD-543-549 (Native SWE Harness — ToolCall protocol + agentic loop)
AD-439 (Emergent Leadership Detection)
AD-440 (Chain of Command Delegation)

Higher-order capabilities that build on the connected fabric.

10. The Complete Crew Member Capability Profile

When all phases are complete, querying an agent's capability profile returns:

agent_id: "did:probos:ship-001:agent-meridian-uuid"
callsign: "Meridian"
agent_type: architect
post: first_officer
department: science
rank: commander
trust_score: 0.82
lifecycle_state: active

# Character (Personality)
personality:
  openness: 0.9
  conscientiousness: 0.8
  extraversion: 0.5
  agreeableness: 0.7
  neuroticism: 0.2
  drift_from_seed: 0.08  # Euclidean distance

# Standing Orders — T1 (Identity + Behavioral Guidance)
standing_orders:
  federation: "config/standing_orders/federation.md"
  ship: "config/standing_orders/ship.md"
  department: "config/standing_orders/science.md"
  personal: "config/standing_orders/architect.md"

# Cognitive Skills — T2 (AgentSkills.io, from CognitiveSkillCatalog)
cognitive_skills:
  - name: architecture-review
    origin: internal
    description: "Analyze proposed system designs against ProbOS architectural principles"
    department: science
    min_rank: lieutenant
    skill_id: architecture_review  # bridge to SkillRegistry
    proficiency: 5  # Advise
  - name: code-review
    origin: external  # imported from AgentSkills.io ecosystem
    description: "Review code changes for correctness, style, and security"
    # no ProbOS metadata — ungoverned external skill

# Handled Intents (derived from T2 cognitive skills + T3 executable skills)
handled_intents:
  - name: design_feature
    source: cognitive_skill  # from architecture-review SKILL.md
    tier: deep
    description: "Analyze codebase and produce architectural proposals"

# Assigned Tools (from role template + rank + qualification)
tools:
  - tool_id: codebase_query
    provider: codebase_index
    permission: ORW
    qualified: true
    qualification_date: "2026-04-01"
  - tool_id: ward_room_post
    provider: ward_room
    permission: ORW
    gated_by: earned_agency
    qualified: true
  - tool_id: ward_room_endorse
    provider: ward_room
    permission: ORW
    gated_by: lieutenant_plus
    qualified: true
  - tool_id: episodic_recall
    provider: episodic_memory
    permission: OR
    scope: own_shard_only
    qualified: true
  - tool_id: knowledge_query
    provider: knowledge_store
    permission: OR
    qualified: true

# Learned Skills (from Cognitive JIT)
executable_skills:
  - name: codebase_knowledge
    origin: built_in
    compilation_level: 3
  # ... additional learned skills from experience

# Skill Proficiency (from Skill Framework)
skill_profile:
  pccs:
    - skill_id: chain_of_command
      proficiency: 5  # Advise
    - skill_id: communication
      proficiency: 5
    - skill_id: collaboration
      proficiency: 4  # Enable
  role_skills:
    - skill_id: architecture_review
      proficiency: 5
    - skill_id: pattern_recognition
      proficiency: 4
  acquired_skills: []

# Qualification Status (from AD-566)
qualifications:
  baseline_set: true
  latest_battery:
    bfi2_personality_probe: { score: 0.87, passed: true }
    episodic_recall_accuracy: { score: 0.92, passed: true }
    confabulation_resistance: { score: 0.95, passed: true }
  qualification_path: lieutenant_to_commander
  path_progress: "4/5 requirements met"

# Procedures (from Cognitive JIT)
procedures:
  total: 12
  by_level:
    novice: 0
    guided: 3
    validated: 5
    autonomous: 3
    expert: 1

# Duty Assignment
current_duty:
  pool: architect
  watch: alpha
  intent_subscriptions: ["design_feature"]

# Service Record
service_record:
  birth_date: "2026-03-15T08:00:00Z"
  total_episodes: 847
  success_rate: 0.91
  trust_trajectory: improving
  promotions: ["ensign→lieutenant (2026-03-18)", "lieutenant→commander (2026-03-25)"]

This is the Crew Manifest (AD-513) query result — the unified view that connects every system.

11. Relationship to Commercial Systems

Agent Capital Management (ACM)

ACM is the commercial financial backbone that builds on the OSS capability profile:

OSS (Crew Capability Profile) Commercial (ACM)
What the agent CAN do What the agent COSTS
Skill proficiency Billable skill rates
Tool access Tool licensing costs
Qualification status Certification revenue
Duty assignment Project assignment
Service record Performance evaluation

Boundary rule: "How it works" → OSS. "How it makes money" → Commercial. The capability profile is OSS. Billing, scheduling optimization, capacity planning, and customer-facing management are commercial.

Agent Services Automation (ASA)

ASA (AD-C-010 through AD-C-015) is the commercial execution engine. It consumes the capability profile to: - Match agents to work items based on skills + tools + availability - Schedule agents across ProbOS instances (workforce mobility) - Track billable time via BookingJournals - Optimize resource allocation

The OSS capability profile is the input. ASA is the consumer.

12. Design Principles

  1. Tools are not personnel. Infrastructure agents remain agents (for observability, distributability, evolvability). But crew agents get tool bindings — composable capabilities assigned by role.

  2. Qualification gates access. Completing PQS (AD-566) updates skill proficiency (AD-428) which unlocks tool permissions (AD-423). No shortcuts. The pathway is: learn → test → qualify → access.

  3. Rank modulates scope. Same tool, different permission level by rank. Ensigns get read-only. Commanders get full access. Seniors get cross-department access. Captain overrides everything.

  4. Skills are dual-path. Assigned skills come from role templates (what you're EXPECTED to know). Learned skills come from Cognitive JIT (what you FIGURED OUT). Both tracked in the same Skill Framework.

  5. The ontology is the schema of truth. All capability definitions live in YAML (organization.yaml, skills.yaml, resources.yaml). Runtime code reads from the ontology. Changes to capability structure are ontology changes, not code changes.

  6. Crew Manifest is the query surface. One API call returns the complete capability profile. No agent should need to query 8 different services to understand itself. AD-513 assembles the view.

  7. Preserve Society of Mind at infrastructure layer. The intent bus, infrastructure agents, and uniform protocol are genuine architectural advantages. The tool binding layer is additive, not a replacement.

  8. Tools are delivery-mechanism agnostic. A tool can be an onboard utility agent, an MCP server, a remote API, a desktop automation session, a browser, a federation service, or a deterministic function. The crew member doesn't know or care. The Tool protocol and ToolContext abstract the delivery mechanism. What matters is: can I use it, and does it work?

  9. Graceful degradation through chain of command. When a tool is unavailable or a skill can't complete, the agent doesn't fail — it falls back to LLM reasoning, then escalates via chain of command. The fallback cascade mirrors how a human crew handles missing equipment: try yourself, ask for help, report to command.

13. Prior Work Absorbed

Source What Was Absorbed
U.S. Navy personnel management (BUPERS/PQS/NEC/3-M) Organizing metaphor for the entire architecture
AD-422 tool-taxonomy.md 8-category tool classification, CRUD+O permissions, department scoping
AD-423 roadmap spec Tool Registry design, registration schema, discovery flow
AD-483 unified-tool-layer.md AgenticToolAdapter protocol, skill-to-tool binding concept
AD-429 Vessel Ontology (all 8 domains) Formal model connecting org, crew, skills, resources
AD-428 Skill Framework Three-category taxonomy, Dreyfus proficiency, role templates
AD-441c Asset Tags Two-tier identity (birth certificates vs serial numbers)
AD-531-539 Cognitive JIT Learned procedures as Executable Skills
AD-566a Qualification Harness Test protocol, store, comparison API
MOISE+ (organizational specification) Structural specification for agent organizations
O*NET / ESCO (competency taxonomies) Skill taxonomy design (referenced in ontology research)
Fokoue et al. (2026) Same LLM + different contexts = different analytical lenses
Ge et al. (2026, IRT) Decomposing LLM ability from scaffold ability
Jeong (2026, MTI) Behavioral profiling for drift detection
Claude Code / OpenClaw analysis Plug-and-play skill/tool composition patterns
AD-422 tool-taxonomy.md (8 categories) Tool type diversity — 8 categories from utility agents to federation services
AD-543 unified-tool-layer.md AgenticToolAdapter protocol, ToolContext concept, adapter uniformity
AD-543 ToolCall protocol spec (roadmap) ToolCallRequest/ToolCallResult/ContentBlock wire format, ToolExecutor, agentic loop
AgentSkills.io (Anthropic, open standard) SKILL.md format, progressive disclosure (description→instructions→resources), skills-ref validation library
Claude Code Skills Description-based auto-discovery, on-demand loading, $ARGUMENTS substitution, three storage scopes, context: fork subagent execution
Microsoft Business Skills (Dataverse) "Natural-language instructions that capture how your organization gets work done." Metadata-for-discovery / instructions-for-execution pattern. RBAC governance.
Hermes Agent Skills Hub (NousResearch) 644 skills across 4 registries, category taxonomy (16 categories), AgentSkills.io adoption, skills as procedural memory that self-improve through use
Anthropic anthropics/skills repository Reference skill implementations (document skills, development skills), template structure for skill authoring
BF-146 (standing order confabulation) Concrete demonstration that instruction-defined capabilities have same defect surface as code — stale references cause confabulation
Design Principle: "Natural Language as Code" Instruction validation (structural, pre-execution) distinct from output evaluation (stochastic, post-execution evals). Three capability types need different validation.

14. Deferred Items and Future ADs

Item Proposed AD Dependencies Notes
AD-423/483 reconciliation into AD-423a/b/c AD-423a/b/c AD-422 (done) Merge scope, build in sequence
Qualification → Skill proficiency bridge AD-566f AD-566a-e, AD-428 New AD needed
Role-based tool assignment at onboarding Part of AD-423c AD-423a/b Wiring in agent_onboarding.py
Qualification-gated tool authorization Part of AD-423c AD-423a/b, AD-566 PQS completion → tool unlock
Crew Manifest unified query AD-513 AD-423, AD-429, AD-441 Already planned
Ontology-Based Task Routing AD-438 AD-423, AD-428, AD-429 Already planned
Emergent Leadership Detection AD-439 AD-429, Hebbian Already planned
Chain of Command Delegation AD-440 AD-429 Already planned
Business Process Execution AD-618 (Bill System) AD-423, AD-496, AD-438, AD-434 Multi-agent SOPs with role-based assignment, BPMN-vocabulary decision points, Cognitive JIT bridge. Research: docs/research/standard-operating-procedures.md
Personal Ontology (from research) Future AD-429 Agent's self-model of own capabilities
ToolContext scoped view construction Part of AD-423c AD-423a/b Permission-filtered tool view per agent, wired at onboarding
ProcedureStep.required_tools field Part of AD-423c or AD-539+ AD-423a, AD-531-539 Declares which tools each procedure step needs
Fallback cascade (skill→LLM→escalate) Part of AD-534b+ AD-534 (done), AD-423 Graceful degradation when tools unavailable
Cognitive Skill Registry (AgentSkills.io) AD-596a-e AD-428, AD-429, AD-339 T2 cognitive skills as SKILL.md files, progressive disclosure, external skill import, validation
External skill interop Part of AD-596d AD-596a Consume AgentSkills.io skills from Claude Code, Hermes, etc.
Instruction linting Part of AD-596e AD-596a Structural validation for instruction-defined capabilities (BF-146 class of defects)

All deferred items now have AD assignments.

15. Canonical Validation Scenario: Social Media Marketing Agent

This is the end-to-end test case that proves the Crew Capability Architecture works. Every layer must execute for this flow to complete. If this scenario passes, the system is wired correctly.

The Flow

┌─────────────────────────────────────────────────────────────────┐
│  VALIDATION SCENARIO: LinkedIn Post Creation                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Step 1: CREATE AGENT                                           │
│  ├─ New crew agent instantiated                                 │
│  ├─ Gets DID, birth certificate, sovereign identity             │
│  ├─ wire_agent() in agent_onboarding.py                         │
│  └─ Systems: Identity (AD-441), Onboarding (Core)               │
│                                                                 │
│  Step 2: ASSIGN ROLE                                            │
│  ├─ Post: "social_media_marketer" (from ontology)               │
│  ├─ Department: Communications (or Operations)                  │
│  ├─ Role template loaded from skills.yaml                       │
│  ├─ Standing Orders composed: Federation → Ship → Dept → Agent  │
│  └─ Systems: Ontology (AD-429), Standing Orders (AD-339)        │
│                                                                 │
│  Step 3: ASSIGN SKILLS FROM ROLE TEMPLATE                       │
│  ├─ Role template defines required skills:                      │
│  │   - content_creation (PCC: communication)                    │
│  │   - social_media_post_writing (ROLE skill)                   │
│  │   - audience_analysis (ROLE skill)                           │
│  │   - brand_voice_adherence (ROLE skill)                       │
│  ├─ commission_agent() assigns skills at FOLLOW proficiency     │
│  ├─ Prerequisite DAG enforced (post_writing requires            │
│  │   content_creation)                                          │
│  └─ Systems: Skill Framework (AD-428), Ontology (AD-429)        │
│                                                                 │
│  Step 4: SKILL → INTENT MAPPING                                 │
│  ├─ social_media_post_writing skill handles intent:             │
│  │   "create_linkedin_post"                                     │
│  ├─ IntentDescriptor registered for this intent                 │
│  ├─ Intent bus routes "create_linkedin_post" → this agent       │
│  ├─ Could be executable skill (Cognitive JIT L4+) or            │
│  │   LLM-mediated (cognitive lifecycle)                         │
│  └─ Systems: Intent Bus (Core), Cognitive JIT (AD-531-539)      │
│                                                                 │
│  Step 5: TOOL REQUIRED — LINKEDIN API                           │
│  ├─ Skill execution needs tool: "linkedin_post_api"             │
│  ├─ ToolContext.has_tool("linkedin_post_api") → checked         │
│  ├─ Permission check: agent rank allows W (write) on this tool  │
│  ├─ Tool type: Remote API (or MCP Server)                       │
│  ├─ ToolContext.invoke("linkedin_post_api", {                   │
│  │     content: "...", audience: "...", hashtags: [...]          │
│  │   }) → ToolResult                                            │
│  └─ Systems: Tool Registry (AD-423a), Permissions (AD-423b),    │
│     ToolContext (AD-423c)                                        │
│                                                                 │
│  Step 6: EXECUTION + AUDIT                                      │
│  ├─ Tool adapter invokes LinkedIn API                           │
│  ├─ Result flows back through intent bus                        │
│  ├─ Episode recorded in EpisodicMemory                          │
│  ├─ Skill exercise recorded (AgentSkillService.record_exercise) │
│  ├─ Tool usage audited in Tool Registry                         │
│  ├─ Trust updated based on outcome                              │
│  └─ Systems: EpisodicMemory, Skill Framework (AD-428),          │
│     TrustNetwork, Tool Registry audit                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

What Each Step Validates

Step Validates Currently
1. Create Agent Identity + onboarding pipeline ✅ Works
2. Assign Role Ontology role templates → Standing Orders composition 🔧 Ontology schema exists, not wired at onboarding
3. Assign Skills Role template → skill commissioning from config (not hardcoded Python) 🔧 Commissioning works, but templates are Python dict, not YAML
4. Skill → Intent Skill maps to intent, intent bus routes correctly ✅ Works (executable skills dispatch in handle_intent)
5. Tool Access ToolContext permission check + tool invocation ❌ AD-423a/b/c not built
6. Audit Trail Exercise recorded, trust updated, episode stored 🔧 Partial (episode + trust work, skill exercise not wired)

Gap: Role Templates Must Come From Config

Currently ROLE_SKILL_TEMPLATES is a Python dict in skill_framework.py — hardcoded for 7 agent types (security_officer, engineering_officer, etc.). For this scenario to work with dynamic roles like "social_media_marketer", role templates must be loaded from config/ontology/skills.yaml at commission time. The Python dict becomes the default fallback for built-in agent types; custom roles are defined in YAML.

This is critical for Nooplex commercial use cases where customers define their own agent roles. A consulting firm needs "data_analyst", "project_manager", "client_liaison" — roles that don't exist in the OSS built-in types.

Success Criteria

The validation scenario passes when:

  1. A new agent with type social_media_marketer can be created with no code changes (config only)
  2. The agent receives skills from a YAML role template, not hardcoded Python
  3. The agent can handle a create_linkedin_post intent
  4. The intent execution invokes a LinkedIn tool through ToolContext with permission checks
  5. The skill exercise is recorded, trust is updated, and the episode is stored
  6. The full chain is queryable via Crew Manifest (/api/ontology/crew-manifest): agent → role → skills → tools → recent activity

Nooplex Commercial Extension

This scenario is the foundation for Nooplex's "crew-for-hire" model:

  • Customer defines role → YAML role template (skills, tools, standing orders)
  • Nooplex assigns agent → DID-portable agent, Clean Room memory policy
  • Agent works → uses customer's tools (LinkedIn, Salesforce, HubSpot via MCP)
  • ACM tracks → billable hours, skill utilization, tool costs
  • ASA schedules → work items, capacity planning, auto-escalation

The OSS capability architecture makes all of this possible. The commercial layer adds billing, scheduling, and multi-tenant management.