Global Rules, Project Deltas: How the Agent Fleet Is Configured
One Baseline, Then a Small Delta
I used to think of agent configuration as something each repository had to explain from scratch. That does not scale. The arrangement I use now has two layers: a global policy that defines the reusable fleet, and a project policy that records only what is different in that codebase.
The Claude orchestrator policy lives at ~/.claude/CLAUDE.md, while the Codex policy lives at ~/.codex/AGENTS.md. A more detailed reference sits at ~/.config/hybrid-agent-router/ROUTING.md. Those files are user-scoped, so the same routing rules apply to every project without being copied into every repository.
This journal page is only a description of that engineering practice. CipherClawWeb remains a static publishing boundary; it does not run any of these agents when someone opens the site.
The Global Pool
On the Claude side, I keep five specialists. claude-exploreruses Haiku for read-only repository search. claude-planneruses Sonnet for read-only, repository-aware planning, and claude-content-editor uses Sonnet for documentation, prose, and UX copy. claude-reviewer is the independent Sonnet reviewer for Codex-authored work. claude-deep-reviewer uses Opus for subtle correctness and architecture review, and I use it sparingly.
Codex has a parallel set of five roles. codex-mechanical handles exact edits and deterministic work. codex-implementer handles normal implementation, while codex-debugger takes difficult failures. codex-reviewer independently reviews meaningful Claude-authored work, and codex-release-reviewer is the high-risk release gate.
What a Project Adds
- Its own definition of high-risk work.
- The validation commands that prove a change is ready.
- Domain invariants that every worker must preserve.
- Only when necessary, a project-local override of a generic agent.
Each repository records that delta in its own AGENTS.md, with a CLAUDE.md symlink so Claude Code loads the same project memory. The local file is told explicitly not to duplicate the global routing table or effort ladder. It is there to say what is special, not to fork the whole operating model.
There is still a clean override mechanism. A project file at .claude/agents/<name>.md or .codex/agents/<role>.toml shadows the global agent with the same name. That makes a local exception possible without making local exceptions the default.
Where a Real Override Earned Its Place
The clearest example is study-aif-c01, a certification study site. It ships its own .claude/agents/claude-content-editor.md, intentionally shadowing the generic content editor. Learner-facing certification material has to preserve blueprint mappings, source provenance, and question-bank structure, and it must never invent unverified certification facts. A general prose editor has no structural reason to know those constraints.
That same project sends whole-lane or blueprint-level content correctness changes to independent opposite-provider review by default. Factual freshness is part of the product there, so the stronger gate follows the actual risk instead of the number of files changed.
Three Projects, Three Smaller Deltas
The binance-trading-bot does not add a new agent. It adds a strict release gate. Changes to strategy, order placement, reconciliation, protective rails, systemd, environment loading, or state loading require opposite-provider review plus codex-release-reviewer. Financial-logic changes also need focused tests before release.
It also draws a boundary no review verdict can cross: production restarts, runtime state changes, secrets, and systemd changes remain operator-only and never agent-authorized. Review can find a safe patch; it cannot grant operational authority.
veck-shooter, a multiplayer game, takes a middle path. It adds no agents, but it names hard invariants around server-authoritative gameplay, specific physics clamps, and matchmaking identity. It also defines its own high-risk gate for gameplay, physics, hub integration, and Railway configuration.
game-eatToGrow is simpler still. The small Node/Express/Socket.IO game explicitly records ānoneā for both routing overrides and project-local agents. The global pool is sufficient, and saying that plainly saves a future reviewer from wondering whether the section was forgotten.
Escalation Has to Be Earned
Routing starts with the cheapest capable worker. I escalate only when there is evidence: a failed attempt, an unresolved root cause, credible reviewer disagreement, real ambiguity, several viable designs, or unusual correctness impact. A task being large or important is not evidence by itself.
The Effort Ladder
- Low: exact lookups, formatting, and deterministic transforms.
- Medium: ordinary implementation and focused edits with clear criteria.
- High: planning, review, architecture comparison, and unclear failures that require judgment.
- Xhigh: only after a high-effort attempt leaves documented ambiguity.
- Max or ultracode: only on explicit user instruction, never as a default.
The model ladder follows the same logic. Luna moves to Terra when mechanical work turns out to need judgment. Terra moves to Sol when a high-effort attempt remains unresolved. On the Claude side, Sonnet moves to Opus for genuinely difficult architecture or subtle correctness questions. The first worker hands over preserved evidence instead of making the stronger model rediscover the same facts.
Most engineering work is routine. Putting an expensive, maximum-effort model on routine work does not automatically make it more correct; it usually makes it slower and more costly. Saving the frontier tier for demonstrated need keeps everyday work quick and keeps premium review meaningful instead of turning it into noise layered onto noise.
Review Cost Should Follow Change Risk
Review independence is part of the same design. A worker never reviews its own work. Meaningful Claude-authored changes go to an independent Codex reviewer, and meaningful Codex-authored changes go to an independent Claude reviewer.
Trivial documentation, formatting, and routine edits skip that cross-provider step. Review has a cost, just as a larger model does, so I want that cost to scale with the risk of the change. The result is a global system that stays consistent without pretending every repository or every patch needs the same ceremony.
The Practical Rule
Most projects do not need a new agent. A short, precise deltaārisk list, validation commands, and hard invariantsāis usually enough. That is what the trading bot and the games demonstrate.
A project-local override is for the rarer case represented by the certification site: the domain has a constraint the generic role cannot reasonably know. Keeping that bar high lets the shared fleet remain genuinely shared while still leaving room for the exceptions that matter.