Harness Maturity Model

01 Knowledge

What the agent knows about your team

1. Your repos have agent-readable context files (CLAUDE.md / rules) capturing conventions and the why — not just code
2. That knowledge is committed and shared, not living on one engineer’s laptop
3. Someone owns keeping it current

What good looks like. A shared context file the agent reads every session — conventions, standards, and the why behind them — with a named owner.

02 Capabilities

What the agent can do, on repeat

1. Your team has packaged, reusable workflows — skills, plugins, or slash commands — beyond ad-hoc prompting
2. Those workflows are shared across the team, not stuck in one person’s setup
3. Someone owns the library: versioning, updates, retiring dead ones

What good looks like. A shared, versioned library of skills the whole team runs — treated as org infrastructure, not personal productivity.

03 Connectivity

What the agent can touch

1. Your agents connect to real systems — cloud, databases, browser, repos — not just chat
2. They connect through dedicated scoped service accounts, never engineers’ personal accounts
3. Those accounts are least-privilege: read-only by default, destructive actions gated

What good looks like. Agents wired to your systems through scoped, read-only-by-default service accounts, so the blast radius of a mistake stays small.

04 Governance

What the agent can’t do without permission

1. An allowlist lets safe, routine commands run without a human approving each one
2. Destructive operations are blocked or gated by hooks before they execute
3. You have a defined response for when an agent does something it shouldn’t

What good looks like. An allowlist for safe commands plus hooks blocking destructive ones — what makes auto-mode fast and safe instead of reckless.

Score bands