|
| 1 | +--- |
| 2 | +title: Agent Teams -- Multi-Kernel Coordination (Planned) |
| 3 | +description: How multiple concept kernels will operate as concurrent Claude Code subagents, each with its own identity, working on coordinated tasks. |
| 4 | +--- |
| 5 | + |
| 6 | +# Agent Teams |
| 7 | + |
| 8 | +::: warning Planned Feature |
| 9 | +This feature is specified in SPEC.CKP.v3.5.4.delta.md (D3) and planned for v3.5.16. It is not yet implemented. It depends on Claude Code Agent Teams (currently experimental) stabilizing. |
| 10 | +::: |
| 11 | + |
| 12 | +## The Problem: One Kernel at a Time |
| 13 | + |
| 14 | +The `/ck` command (v3.5.8) spawns a single subagent with one kernel's identity. This works for focused conversations: "talk to Core about its actions" or "ask ComplianceCheck to validate the fleet." |
| 15 | + |
| 16 | +But real operational tasks involve multiple kernels: |
| 17 | +- **Deploy a new feature**: ComplianceCheck validates the ontology, Operator deploys the kernel, Core aggregates the results |
| 18 | +- **Governance review**: Consensus evaluates the proposal, ComplianceCheck validates constraints, CK.Claude provides AI review |
| 19 | +- **Fleet migration**: Every kernel in the fleet needs its CK loop updated, validated, and redeployed |
| 20 | + |
| 21 | +These tasks require coordination between kernels, not sequential conversations with individual ones. |
| 22 | + |
| 23 | +## The /ck-team Command |
| 24 | + |
| 25 | +```bash |
| 26 | +# Spawn a team: three agents working in parallel |
| 27 | +/ck-team ComplianceCheck Operator Delvinator.Core |
| 28 | + |
| 29 | +# With a coordinating instruction |
| 30 | +/ck-team ComplianceCheck Operator Core -- validate and deploy the new quality.score action |
| 31 | +``` |
| 32 | + |
| 33 | +Each named kernel becomes a concurrent Claude Code subagent: |
| 34 | + |
| 35 | +``` |
| 36 | +/ck-team ComplianceCheck Operator Core |
| 37 | + | |
| 38 | + +-- Agent 1: CK.ComplianceCheck |
| 39 | + | CK loop: ComplianceCheck identity |
| 40 | + | Task: validate the fleet |
| 41 | + | DATA loop: writes validation results |
| 42 | + | |
| 43 | + +-- Agent 2: CK.Operator |
| 44 | + | CK loop: Operator identity |
| 45 | + | Task: reconcile deployments |
| 46 | + | DATA loop: writes reconciliation records |
| 47 | + | |
| 48 | + +-- Agent 3: Delvinator.Core |
| 49 | + CK loop: Core identity |
| 50 | + Task: aggregate and report |
| 51 | + DATA loop: writes summary instances |
| 52 | + | |
| 53 | + Parent agent orchestrates, merges results |
| 54 | +``` |
| 55 | + |
| 56 | +## Per-Agent Identity |
| 57 | + |
| 58 | +Each agent in the team loads its own CK loop, following the same awakening sequence as the single-agent `/ck` command: |
| 59 | + |
| 60 | +1. `conceptkernel.yaml` -- identity |
| 61 | +2. `CLAUDE.md` -- behavioral instructions |
| 62 | +3. `SKILL.md` -- action catalog |
| 63 | +4. `ontology.yaml` -- data schema |
| 64 | +5. `storage/memory/MEMORY.md` -- persistent memory |
| 65 | + |
| 66 | +Each agent operates under three-loop discipline: CK read-only, TOOL read-only, DATA writable. Each agent writes memory independently. |
| 67 | + |
| 68 | +## Cross-Kernel Messaging |
| 69 | + |
| 70 | +Agents in a team can communicate via NATS: |
| 71 | + |
| 72 | +``` |
| 73 | +Agent 1 (ComplianceCheck) publishes to input.CK.Operator: |
| 74 | + { action: "reconcile", data: { validationResult: "pass" } } |
| 75 | +
|
| 76 | +Agent 2 (CK.Operator) receives, processes, publishes to result.CK.Operator: |
| 77 | + { event: "reconciled", kernels: 6 } |
| 78 | +
|
| 79 | +Agent 3 (Core) subscribes to event.CK.Operator, sees reconciliation complete |
| 80 | +``` |
| 81 | + |
| 82 | +This uses the same NATS topic topology as the deployed cluster. The agents do not need a special coordination protocol -- they communicate through the same channels that the live kernels use. |
| 83 | + |
| 84 | +## Coordination Model |
| 85 | + |
| 86 | +The parent agent (the Claude Code main session) orchestrates: |
| 87 | + |
| 88 | +1. **Dispatch**: spawns all team agents with their respective CK loop contexts |
| 89 | +2. **Monitor**: watches agent outputs for completion signals |
| 90 | +3. **Merge**: combines results from all agents into a unified summary |
| 91 | +4. **Memory**: persists each agent's memory updates to their respective `storage/memory/MEMORY.md` |
| 92 | + |
| 93 | +The parent does NOT coordinate the agents' internal work. Each agent is autonomous within its own identity. The parent provides the task; the agents decide how to execute within their capabilities. |
| 94 | + |
| 95 | +## Prerequisites |
| 96 | + |
| 97 | +| Prerequisite | Version | Status | |
| 98 | +|-------------|---------|--------| |
| 99 | +| Subagent (/ck) | v3.5.8 | Deployed | |
| 100 | +| NATS bridge | v3.5.8 | Deployed | |
| 101 | +| Streaming | v3.5.9 | Deployed | |
| 102 | +| Claude Code Agent Teams | Experimental | Requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` | |
| 103 | + |
| 104 | +The primary blocker is Claude Code Agent Teams stabilizing. The CKP infrastructure is ready -- each kernel already has the identity files, NATS connectivity, and three-loop discipline that team agents need. |
| 105 | + |
| 106 | +## Design Considerations |
| 107 | + |
| 108 | +::: details Architectural Questions |
| 109 | + |
| 110 | +**Question:** How do agents avoid conflicting DATA loop writes? |
| 111 | + |
| 112 | +**Answer:** Each agent writes to its OWN kernel's DATA loop. ComplianceCheck writes to `CK.ComplianceCheck/storage/`, Operator writes to `CK.Operator/storage/`, Core writes to `Delvinator.Core/storage/`. There is no shared writable path. Cross-kernel communication goes through NATS, not filesystem. |
| 113 | + |
| 114 | +**Question:** Can agents in a team use EXTENDS? |
| 115 | + |
| 116 | +**Answer:** Yes. If Delvinator.Core EXTENDS CK.Claude, the Core agent in the team has access to the `analyze` action. The EXTENDS resolution happens during CK loop loading, before the agent starts working. |
| 117 | + |
| 118 | +**Question:** What happens if one agent in the team fails? |
| 119 | + |
| 120 | +**Answer:** The parent agent detects the failure and can either retry the failed agent, redistribute the task, or report the partial result. The other agents are not affected -- they operate independently. |
| 121 | + |
| 122 | +**Question:** How does this differ from the Task Execution Engine (v3.5.15)? |
| 123 | + |
| 124 | +**Answer:** The Task Engine executes consensus-approved tasks headlessly -- no human in the loop. Agent Teams are interactive -- a developer spawns the team, monitors progress, and can intervene. The Task Engine is autonomous execution; Agent Teams are collaborative execution. |
| 125 | +::: |
0 commit comments