Share agent configs across harnesses
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
observal agent createStep-by-step prompts: name, description, which MCP servers, which skills, which hooks. Results in a registry entry you can share by ID.
Option B - the YAML workflow (recommended for teams)
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.
Last updated
Was this helpful?