Q: Kelly's Authority Matrix — What's Documented vs What's Missing?

Short answer: Kelly's factory has named agents with routing rules and RALPH escalation, but there's no documented authority matrix — no per-tier decision rights, no progressive authority transfer log, no explicit boundary between what each agent can decide autonomously vs what requires escalation. This is the exact gap that SuperAda's Autonomy Policy v3 fixed for the Enterprise Crew.

Context

Kelly's factory has a clear role hierarchy (Router → research-lead → project-lead → build-agents → test-lead) and an escalation protocol (RALPH: retry → escalate on second failure). But role assignment and failure escalation are different from ongoing authority — the question of what decisions each agent can make without asking.

SuperAda's Enterprise Crew evolved through three iterations of autonomy policy. The final version (v3) codified that delegation without context is not leverage, and established four authority tiers:
- Level A: Full Auto (act and report concisely)
- Level B: Auto With Notify (act, then notify)
- Level C: Approval Gated (get approval first)
- Level D: Never Autonomous

Kelly has neither this tiered structure nor a policy that governs it. The question is whether this gap causes real operational ambiguity.

What the KB Has on Kelly's Authority

From kelly-factory-overview and kelly-handbook-ch7-multi-agent:

Named Lead Agents

Agent Role
Router Routes, validates gates, escalates — never does the work
research-lead (Carson) Runs CIS loop
project-lead (Mary) Owns planning artifacts
test-lead Runs TEA audit, adversarial review
design-lead (Sally) UI/UX specifications
build-lead (Amelia) Sprint execution
deploy-lead (Phil) DevOps, scaffolding

RALPH Protocol

From kelly-handbook-ch7-multi-agent and ralph-protocol:
- Sub-agent failure → retry once
- Same failure twice → escalate immediately
- Three failures → mandatory escalation with structured diagnostic
- Unrecoverable → immediate escalation with operator decision requested

Gate-Driven Decision Points

  • Research → Planning: CIS READY gate
  • Planning → Implementation: PASS/FAIL gate
  • Testing → Release: TEA audit (PASS/PASS-WITH-FOLLOWUPS/REMEDIATE) + Operator SHIP/NO-SHIP

What Kelly Explicitly Forbids

From kelly-factory-overview:
- Router never edits project files while sub-agent is working
- Use sessions_send or subagents(steer) to redirect
- trash > rm for safety

What's Missing

1. Per-Agent Decision Rights Tiers

Which agent can make what class of decisions autonomously?
- Can Amelia (build-lead) decide to skip a story because it's too complex, or must that escalate?
- Can the research-lead decide a source is not credible and exclude it without consultation?
- Can the test-lead fail a build on style grounds, or only on functional grounds?
- Can the Router override a PASS gate, or only fail it?

No documented answer. SuperAda's Autonomy Policy v3 solves this by assigning specific Level A/B/C/D authority to specific agents for specific work types.

2. Authority Progression Log

When does an agent earn more authority?
- Kelly's factory presumably has an implicit learning loop — if Amelia consistently delivers good builds, she might be trusted with more autonomy
- Is this tracked anywhere? A log of "agent X was elevated from Level C to Level B for task type Y on date Z"?
- Yuki AI CEO maintains this explicitly — Kelly doesn't have a documented equivalent

3. Reversible vs Irreversible Decision Boundary

SuperAda v3 defines autonomous scope as "internal, reversible, verifiable" — only those can be decided without escalation. Kelly's factory has no equivalent definition:
- Can Amelia refactor a module without asking? (presumably yes if it's within the sprint scope)
- Can she change a dependency? (probably not without approval)
- Can she skip a test? (no — QA is not optional per kelly-factory-overview)
- Where is the line documented?

4. Context-Complete Handoff Requirement

SuperAda v3 Rule 1: delegation must be context-complete — the assignee must have everything needed to act without follow-up questions. Kelly's sub-agent spawning pattern relies on context handoff but has no documented standard:
- What's the minimum context a sub-agent must receive before being considered properly delegated?
- If Amelia receives a vague task and asks for clarification — is that a sub-agent failure (she should have refused the task) or normal (clarification is allowed)?
- No documented answer.

5. Dead Delegate Protocol

SuperAda v3 Rule 3: dead delegate = switch executor immediately. Kelly's RALPH handles agent failure (retry, escalate), but what about a sub-agent that goes silent (not failing, just unresponsive)?
- Is there a timeout before the Router kills and re-assigns?
- Does the heartbeat mechanism cover this, or is there a gap?

Proposed Research Path

  1. Review Kelly handbook tweets for agent autonomy decisions — kelly-tweets-agents.md and kelly-tweets-factory.md may have examples of what agents were allowed to decide
  2. Check AGENTS.md in the operator's workspace — if the operator has an actual AGENTS.md, it may contain authority rules not yet ingested
  3. Cross-reference SuperAda Autonomy Policy v3 — the three rules (context-complete, non-blocking, dead delegate) could be a Kelly adoption candidate
  4. Interview operator — Kelly's actual practice may be documented only in operational memory, not the KB