Skip to main content
Your team has a reviewer agent that works great in Claude Code. Now someone wants to use it in Kiro. Then Cursor. Then they want to tweak the skills. Copy-pasting config snippets across tools doesn’t scale. Observal’s registry gives you one agent definition that installs cleanly into every supported harness.

The shape of an agent

Every agent is a YAML file that bundles:
  • MCP servers it needs
  • Skills to load
  • Hooks to wire into the session lifecycle
  • Prompts (with variables)
  • Sandboxes for code execution
When someone runs observal agent pull <agent>, Observal templates that YAML into the right files for their harness: ~/.claude/agents/*.json, .kiro/agents/*.json, .cursor/mcp.json, and so on.

Publish an agent

Option A - the interactive wizard

Step-by-step prompts: name, description, which MCP servers, which skills, which hooks. Results in a registry entry you can share by ID.
The YAML workflow is PR-reviewable. The file lives in your repo; changes flow through your normal review process.

Install an agent into any harness

Browse what exists:
Install with one command, pick the harness:
The CLI prompts for any environment variables the MCP servers declare as required (GitHub tokens, API keys). These are stored in your harness config, not uploaded to Observal.

Control what gets installed

What portability actually means

The harness feature matrix (defined in packages/observal-shared/observal_shared/harness_registry.py) controls what each harness supports. If an agent uses skills and the target harness doesn’t have skills, the installer:
  • Installs the compatible parts cleanly
  • Warns about the unsupported parts
  • Exits non-zero if the agent requires something the harness cannot provide
Useful when onboarding a new machine or swapping between “work setup” and “personal setup.”

Next

→ Run a team-wide agent registry: once publishing is routine, you need governance.