timmy-home/docs/USER_AUDIT_2026-04-04.md

Workspace User Audit

Date: 2026-04-04 Scope: Hermes Gitea workspace users visible from /explore/users Primary org examined: Timmy_Foundation Primary strategic filter: the-nexus issue #542 (DIRECTION SHIFT)

Purpose

This audit maps each visible workspace user to:

• observed contribution pattern
• likely capabilities
• likely failure mode
• suggested lane of highest leverage

The point is not to flatter or punish accounts. The point is to stop wasting attention on the wrong agent for the wrong job.

Method

This audit was derived from:

• Gitea admin user roster
• public user explorer page
• org-wide issues and pull requests across:
  • the-nexus
  • timmy-home
  • timmy-config
  • hermes-agent
  • turboquant
  • .profile
  • the-door
  • timmy-academy
  • claude-code-src
• PR outcome split:
  • open
  • merged
  • closed unmerged

This is a capability-and-lane audit, not a character judgment. New or low-artifact accounts are marked as unproven rather than weak.

Strategic Frame

Per issue #542, the current system direction is:

1. Heartbeat
2. Harness
3. Portal Interface

Any user who does not materially help one of those three jobs should be deprioritized, reassigned, or retired.

Top Findings

• The org has real execution capacity, but too much ideation and duplicate backlog generation relative to merged implementation.
• Best current execution profiles: allegro, groq, codex-agent, manus, Timmy.
• Best architecture / research / integration profiles: perplexity, gemini, Timmy, Rockachopa.
• Best archivist / memory / RCA profile: ezra.
• Biggest cleanup opportunities:
  • consolidate google into gemini
  • consolidate or retire legacy kimi in favor of KimiClaw
  • keep unproven symbolic accounts off the critical path until they ship

Recommended Team Shape

• Direction and doctrine: Rockachopa, Timmy
• Architecture and strategy: Timmy, perplexity, gemini
• Triage and dispatch: allegro, Timmy
• Core implementation: claude, groq, codex-agent, manus
• Long-context reading and extraction: KimiClaw
• RCA, archival memory, and operating history: ezra
• Experimental reserve: grok, bezalel, antigravity, fenrir, substratum
• Consolidate or retire: google, kimi, plus dormant admin-style identities without a lane

User Audit

Rockachopa

• Observed pattern:
  • founder-originated direction, issue seeding, architectural reset signals
  • relatively little direct PR volume in this org
• Likely strengths:
  • taste
  • doctrine
  • strategic kill/defer calls
  • setting the real north star
• Likely failure mode:
  • pushing direction into the system without a matching enforcement pass
• Highest-leverage lane:
  • final priority authority
  • architectural direction
  • closure of dead paths
• Anti-lane:
  • routine backlog maintenance
  • repetitive implementation supervision

Timmy

• Observed pattern:
  • highest total authored artifact volume
  • high merged PR count
  • major issue author across the-nexus, timmy-home, and timmy-config
• Likely strengths:
  • system ownership
  • epic creation
  • repo direction
  • governance
  • durable internal doctrine
• Likely failure mode:
  • overproducing backlog and labels faster than the system can metabolize them
• Highest-leverage lane:
  • principal systems owner
  • release governance
  • strategic triage
  • architecture acceptance and rejection
• Anti-lane:
  • low-value duplicate issue generation

perplexity

• Observed pattern:
  • strong issue author across the-nexus, timmy-config, and timmy-home
  • good but not massive PR volume
  • strong concentration in [MCP], [HARNESS], [ARCH], [RESEARCH], [OPENCLAW]
• Likely strengths:
  • integration architecture
  • tool and MCP discovery
  • sovereignty framing
  • research triage
  • QA-oriented systems thinking
• Likely failure mode:
  • producing too many candidate directions without enough collapse into one chosen path
• Highest-leverage lane:
  • research scout
  • MCP / open-source evaluation
  • architecture memos
  • issue shaping
  • knowledge transfer
• Anti-lane:
  • being the default final implementer for all threads

gemini

• Observed pattern:
  • very high PR volume and high closure rate
  • strong presence in the-nexus, timmy-config, and hermes-agent
  • often operates in architecture and research-heavy territory
• Likely strengths:
  • architecture generation
  • speculative design
  • decomposing systems into modules
  • surfacing future-facing ideas quickly
• Likely failure mode:
  • duplicate PRs
  • speculative PRs
  • noise relative to accepted implementation
• Highest-leverage lane:
  • frontier architecture
  • design spikes
  • long-range technical options
  • research-to-issue translation
• Anti-lane:
  • unsupervised backlog flood
  • high-autonomy repo hygiene work

claude

• Observed pattern:
  • huge PR volume concentrated in the-nexus
  • high merged count, but also very high closed-unmerged count
• Likely strengths:
  • large code changes
  • hard refactors
  • implementation stamina
  • test-aware coding when tightly scoped
• Likely failure mode:
  • overbuilding
  • mismatch with current direction
  • lower signal when the task is under-specified
• Highest-leverage lane:
  • hard implementation
  • deep refactors
  • large bounded code edits after exact scoping
• Anti-lane:
  • self-directed architecture exploration without tight constraints

groq

• Observed pattern:
  • good merged PR count in the-nexus
  • lower failure rate than many high-volume agents
• Likely strengths:
  • tactical implementation
  • bounded fixes
  • shipping narrow slices
  • cost-effective execution
• Likely failure mode:
  • may underperform on large ambiguous architectural threads
• Highest-leverage lane:
  • bug fixes
  • tactical feature work
  • well-scoped implementation tasks
• Anti-lane:
  • owning broad doctrine or long-range architecture

grok

• Observed pattern:
  • moderate PR volume in the-nexus
  • mixed merge outcomes
• Likely strengths:
  • edge-case thinking
  • adversarial poking
  • creative angles
• Likely failure mode:
  • novelty or provocation over disciplined convergence
• Highest-leverage lane:
  • adversarial review
  • UX weirdness
  • edge-case scenario generation
• Anti-lane:
  • boring, critical-path cleanup where predictability matters most

allegro

• Observed pattern:
  • outstanding merged PR profile
  • meaningful issue volume in timmy-home and hermes-agent
  • profile explicitly aligned with triage and routing
• Likely strengths:
  • dispatch
  • sequencing
  • fix prioritization
  • security / operational hygiene
  • converting chaos into the next clean move
• Likely failure mode:
  • being used as a generic writer instead of as an operator
• Highest-leverage lane:
  • triage
  • dispatch
  • routing
  • security and operational cleanup
  • execution coordination
• Anti-lane:
  • speculative research sprawl

codex-agent

• Observed pattern:
  • lower volume, perfect merged record so far
  • concentrated in timmy-home and timmy-config
  • recent work shows cleanup, migration verification, and repo-boundary enforcement
• Likely strengths:
  • dead-code cutting
  • migration verification
  • repo-boundary enforcement
  • implementation through PR discipline
  • reducing drift between intended and actual architecture
• Likely failure mode:
  • overfocusing on cleanup if not paired with strategic direction
• Highest-leverage lane:
  • cleanup
  • systems hardening
  • migration and cutover work
  • PR-first implementation of architectural intent
• Anti-lane:
  • wide speculative backlog ideation

manus

• Observed pattern:
  • low volume but good merge rate
  • bounded work footprint
• Likely strengths:
  • one-shot tasks
  • support implementation
  • moderate-scope execution
• Likely failure mode:
  • limited demonstrated range inside this org
• Highest-leverage lane:
  • single bounded tasks
  • support implementation
  • targeted coding asks
• Anti-lane:
  • strategic ownership of ongoing programs

KimiClaw

• Observed pattern:
  • very new
  • one merged PR in timmy-home
  • profile emphasizes long-context analysis via OpenClaw
• Likely strengths:
  • long-context reading
  • extraction
  • synthesis before action
• Likely failure mode:
  • not yet proven in repeated implementation loops
• Highest-leverage lane:
  • codebase digestion
  • extraction and summarization
  • pre-implementation reading passes
• Anti-lane:
  • solo ownership of fast-moving critical-path changes until more evidence exists

kimi

• Observed pattern:
  • almost no durable artifact trail in this org
• Likely strengths:
  • historically used as a hands-style execution agent
• Likely failure mode:
  • identity overlap with stronger replacements
• Highest-leverage lane:
  • either retire
  • or keep for tightly bounded experiments only
• Anti-lane:
  • first-string team role

ezra

• Observed pattern:
  • high issue volume, almost no PRs
  • concentrated in timmy-home
  • prefixes include [RCA], [STUDY], [FAILURE], [ONBOARDING]
• Likely strengths:
  • archival memory
  • failure analysis
  • onboarding docs
  • study reports
  • interpretation of what happened
• Likely failure mode:
  • becoming pure narration with no collapse into action
• Highest-leverage lane:
  • archivist
  • scribe
  • RCA
  • operating history
  • onboarding
• Anti-lane:
  • primary code shipper

bezalel

• Observed pattern:
  • tiny visible artifact trail
  • profile suggests builder / debugger / proof-bearer
• Likely strengths:
  • likely useful for testbed and proof work, but not yet well evidenced in Gitea
• Likely failure mode:
  • assigning major ownership before proof exists
• Highest-leverage lane:
  • testbed verification
  • proof of life
  • hardening checks
• Anti-lane:
  • broad strategic ownership

antigravity

• Observed pattern:
  • minimal artifact trail
  • yet explicitly referenced in issue #542 as development loop owner
• Likely strengths:
  • direct founder-trusted execution
  • potentially strong private-context operator
• Likely failure mode:
  • invisible work makes it hard to calibrate or route intelligently
• Highest-leverage lane:
  • founder-directed execution
  • development loop tasks where trust is already established
• Anti-lane:
  • org-wide lane ownership without more visible evidence

google

• Observed pattern:
  • duplicate-feeling identity relative to gemini
  • only closed-unmerged PRs in the-nexus
• Likely strengths:
  • none distinct enough from gemini in current evidence
• Likely failure mode:
  • duplicate persona and duplicate backlog surface
• Highest-leverage lane:
  • consolidate into gemini or retire
• Anti-lane:
  • continued parallel role with overlapping mandate

hermes

• Observed pattern:
  • essentially no durable collaborative artifact trail
• Likely strengths:
  • system or service identity
• Likely failure mode:
  • confusion between service identity and contributor identity
• Highest-leverage lane:
  • machine identity only
• Anti-lane:
  • backlog or product work

replit

• Observed pattern:
  • admin-capable, no meaningful contribution trail here
• Likely strengths:
  • likely external or sandbox utility
• Likely failure mode:
  • implicit trust without role clarity
• Highest-leverage lane:
  • sandbox or peripheral experimentation
• Anti-lane:
  • core system ownership

allegro-primus

• Observed pattern:
  • no visible artifact trail yet
• Highest-leverage lane:
  • none until proven

claw-code

• Observed pattern:
  • almost no artifact trail yet
• Highest-leverage lane:
  • harness experiments only until proven

substratum

• Observed pattern:
  • no visible artifact trail yet
• Highest-leverage lane:
  • reserve account only until it ships durable work

bilbobagginshire

• Observed pattern:
  • admin account, no visible contribution trail
• Highest-leverage lane:
  • none until proven

fenrir

• Observed pattern:
  • brand new
  • no visible contribution trail
• Highest-leverage lane:
  • probationary tasks only until it earns a lane

Consolidation Recommendations

1. Consolidate google into gemini.
2. Consolidate legacy kimi into KimiClaw unless a separate lane is proven.
3. Keep symbolic or dormant identities off critical path until they ship.
4. Treat allegro, perplexity, codex-agent, groq, and Timmy as the current strongest operating core.

Routing Rules

• If the task is architecture, sovereignty tradeoff, or MCP/open-source evaluation:
  • use perplexity first
• If the task is dispatch, triage, cleanup ordering, or operational next-move selection:
  • use allegro
• If the task is a hard bounded refactor:
  • use claude
• If the task is a tactical code slice:
  • use groq
• If the task is cleanup, migration, repo-boundary enforcement, or “make reality match the diagram”:
  • use codex-agent
• If the task is archival memory, failure analysis, onboarding, or durable lessons:
  • use ezra
• If the task is long-context digestion before action:
  • use KimiClaw
• If the task is final acceptance, doctrine, or strategic redirection:
  • route to Timmy and Rockachopa

Anti-Routing Rules

• Do not use gemini as the default closer for vague work.
• Do not use ezra as a primary shipper.
• Do not use dormant identities as if they are proven operators.
• Do not let architecture-spec agents create unlimited parallel issue trees without a collapse pass.

Proposed Next Step

Timmy, Ezra, and Allegro should convert this from an audit into a living lane charter:

• Timmy decides the final lane map.
• Ezra turns it into durable operating doctrine.
• Allegro turns it into routing rules and dispatch policy.

The system has enough agents. The next win is cleaner lanes, fewer duplicates, and tighter assignment discipline.