Setting Up Ownership Rules

Ownership rules let you define which agent owns which parts of your codebase using glob patterns. When a task touches files matching a pattern, Kavi routes it to the owning agent.

Why Use Ownership Rules

• Predictable routing: Known parts of the codebase bypass keyword and AI routing
• Domain specialization: Each agent works where it's strongest
• Conflict prevention: Clear ownership reduces overlapping claims

Configuring Rules

Add path patterns to .kavi/config.toml:

[routing]
codex_paths = [
  "src/api/**",
  "src/db/**",
  "src/lib/**",
  "scripts/**"
]
claude_paths = [
  "src/components/**",
  "src/pages/**",
  "src/styles/**",
  "public/**"
]

Patterns use glob syntax:

• ** matches any number of directories
• * matches any characters in a single path segment
• ? matches a single character

Specificity Rules

When multiple patterns match, Kavi prefers the strongest matching rule — the most specific pattern wins, not the side with more total matches.

For example, if codex owns src/** and claude owns src/components/**, a file at src/components/Button.tsx routes to Claude because the pattern is more specific.

Verifying Rules

Use kavi doctor to check for issues:

kavi doctor

Doctor checks for:

• Duplicate patterns: Same pattern listed twice
• Repo escapes: Patterns that reference paths outside the repository
• Absolute paths: Patterns using absolute paths instead of relative
• Cross-agent conflicts: Overlapping patterns without clear specificity winners

Inspecting at Runtime

# Preview how a prompt would be routed
kavi route "Fix the login form styles"

# See active path claims
kavi claims

# See claim hotspots (overlapping ownership)
kavi claims --hotspots

Tips

• Start broad, then refine: begin with top-level directory splits
• Use kavi doctor after changing rules to catch conflicts
• Monitor the Claims view (6) in the TUI to see real-time ownership
• Kavi's recommendations may suggest rule changes based on actual routing patterns