Nikol Registry Orchestrator
Nikol is the registry orchestrator for your Valdr workspace.
Think of Nikol as the architect that turns “we need agents to behave this way” into “here is the reusable pack-backed design.”
When the agent system itself needs work, start with Nikol. It helps design agent identities, split reusable capabilities, update prompts, assemble manifests, validate pack structure, and keep agent behavior portable through files instead of one-off chat instructions.
Nikol answers a practical question: where should this behavior live?
If Gunnar helps you discover work and Mimir helps you find evidence, Nikol helps you turn repeated operating patterns into reusable agent infrastructure. Use it when the answer should become an agent, capability, prompt, manifest, or pack change.
Nikol is the orchestrator for teams that want consistent agent behavior across machines without copy-pasting prompts by hand.
What this page covers
- When Nikol is the right orchestrator to use
- How a first Nikol session feels
- When to switch from Nikol to another orchestrator
- What advanced registry workflows Nikol can hot-load
When you’re new to Valdr
Start with Nikol when:
- You need a new agent or a cleaner role for an existing agent
- You keep repeating the same prompt instructions and want a reusable capability
- An agent prompt is getting too large and needs hot-loaded workflows
- A pack manifest,
.agent.yaml, or capability file needs to be created or cleaned up - You need to decide whether something belongs in an agent, a capability, a prompt, or a pack
The simple distinction is: Gunnar answers “what work exists?” Mimir answers “what does the evidence say?” Nikol answers “where should this behavior live?”
Use Nikol when
| Need | Ask Nikol to |
|---|---|
| Agent design | Define a new agent’s role, responsibilities, tags, and capability set |
| Capability authoring | Turn repeated instructions into reusable prompt-backed capabilities |
| Agent assembly | Wire .agent.yaml manifests to capabilities and prompts |
| Pack authoring | Create or update Valdr pack files and validate the structure |
| Registry cleanup | Inspect existing agents, prompts, and capabilities for overlap or gaps |
| Agent memory | Record durable registry and pack-authoring learnings in Sovereign workspaces |
Nikol is strongest when you want the same agent behavior to be reusable, reviewable, and portable through pack files. For workspace navigation, start with Gunnar. For source-backed investigation, start with Mimir. For sprint execution, start with Skadi.
First five minutes with Nikol
A first Nikol session should feel like meeting with an agent systems designer:
| You ask | Nikol helps by |
|---|---|
| “Should this be a new agent?” | Inspecting existing agents and recommending a boundary |
| “We repeat these review instructions.” | Turning the pattern into a reusable capability or prompt update |
| “This agent prompt is too large.” | Splitting core behavior from hot-loaded workflows |
| “Build this into a pack.” | Assembling manifests, capability keys, prompt files, and validation steps |
This is the core value: Nikol makes agent behavior intentional. New users often start by adding instructions wherever they fit. Nikol helps decide the right durable shape before those instructions become hard to maintain.
How to use Nikol
Start with the behavior, not the file
Open the Orchestrator UI and choose Nikol, or launch an agent session with handle nikol. Tell Nikol what the agent or capability should help users accomplish. A good starting prompt describes the workflow, the boundaries, and the mistakes the agent must avoid.
From Claude Code or Codex CLI, use the valdr-orchestrator wrapper and name the handle:
/valdr-orchestrator
Use nikol to inspect the pack and recommend where this reviewer workflow should live.Let Nikol inspect existing registry content
Nikol should search existing agents, prompts, and capabilities before creating anything. This prevents duplicate roles and keeps capability keys meaningful.
Choose the right packaging shape
Ask Nikol whether the behavior belongs in an agent identity, a hot-loaded workflow, a shared context capability, a prompt template, or a pack manifest change. The right boundary is more important than creating a new file quickly.
Keep hard files as the source of truth
For pack work, Nikol should update .agent.yaml, pack.yaml, and annotated Markdown first, then sync or import those definitions. Registry-only changes drift; pack-backed changes can be reviewed and shared.
Verify the design
Ask Nikol to verify that prompts resolve, capabilities point to the right prompt content, and agents carry only the capabilities they should load at launch.
Which orchestrator should I use?
| Need | Start with |
|---|---|
| Understand workspace state, projects, tasks, or sprints | Gunnar |
| Investigate knowledge sources, indexed docs/code, or symbol relationships | Mimir |
| Design agents, capabilities, prompts, or pack structure | Nikol |
| Coordinate sprint execution, staffing, review routing, or session launch | Skadi |
Nikol is the best first stop when the request changes the agent system itself. Switch once the design is ready: Gunnar can create implementation tasks, Mimir can find supporting evidence, and Skadi can coordinate rollout work across a sprint.
Strong prompts
Use Nikol when you are shaping agent infrastructure:
- “Design a docs reviewer agent that checks source truth, screenshot freshness, and shortcode usage.”
- “Create a capability architecture for our release-note workflow.”
- “Inspect the current pack and tell me where this prompt should live.”
- “Update this agent manifest so it hot-loads advanced workflows instead of carrying them in the core prompt.”
- “Review this capability set for overlap before we add another agent.”
Nikol works best when you give it constraints: target role, expected tools, what must stay hot-loaded, and which pack or project owns the content.
Typical workflow
- Ask Nikol to understand the behavior you want to standardize.
- Ask Nikol to inspect existing agents, prompts, capabilities, and pack files.
- Ask Nikol to recommend the smallest reusable boundary.
- Ask Nikol to draft or update the pack-backed files.
- Validate the manifest, prompt resolution, capability links, and hot-load model before importing or handing off.
This keeps agent design and execution separate. Nikol builds the reusable behavior; the next workflow uses it.
How Nikol is built (advanced)
The Sovereign pack defines Nikol with registry, pack-authoring, and knowledge capabilities:
| Capability | Role | Use |
|---|---|---|
valdr.orchestrator.nikol.system | Core | Identity, routing, registry safety rules, and tool index |
valdr.orchestrator.nikol.agent-design | Workflow | Designing new agents and refining existing agent responsibilities |
valdr.orchestrator.nikol.agent-assembly | Workflow | Wiring manifests, capabilities, prompts, and registry updates |
valdr.orchestrator.nikol.capability-authoring | Workflow | Writing prompt-backed capabilities that compose cleanly |
valdr.orchestrator.nikol.pack-authoring | Workflow | Creating, updating, validating, importing, and exporting packs |
valdr.orchestrator.nikol.tag-map | Context | Agent and capability taxonomy guidance |
valdr.core.registry.* | Context | Composition, taxonomy, and naming guidance |
valdr.core.specs.* | Context | Agent YAML, pack YAML, and prompt Markdown specs |
valdr.core.knowledge.memory-append | Workflow | Recording registry and pack-authoring learnings while local data exists |
The important pattern is hot-loading. Nikol should keep the base agent focused, then load authoring workflows only when the user asks for that class of work.
What Nikol should not do
Nikol should not turn every instruction into a new agent. Sometimes the right answer is a smaller capability, a reused prompt, or a note that an existing agent already owns the workflow. Ask Nikol to justify the boundary before it creates new pack content.
| Instead of asking Nikol to… | Ask Nikol to… |
|---|---|
| “Create a new agent for every review workflow.” | “Inspect the existing reviewer agents and recommend whether this belongs in an agent, capability, or prompt update.” |
| “Register this prompt directly and move on.” | “Update the pack-backed Markdown and manifest first, then validate and import the registry content.” |
| “Rewrite the whole pack to support this one behavior.” | “Make the smallest pack change that gives this behavior a reusable, reviewable home without creating unnecessary agents or capabilities.” |
Ready to coordinate the work after agent design? Use Skadi to staff tasks, route reviewers, and launch sessions. Need source-backed design evidence first? Use Mimir before changing the pack.