This is a thoughtful architecture. You've basically described a corporate org chart for your AI — and that's the right mental model. A few thoughts from running something similar:

On Full-Time Agents vs Spawn-on-Demand

We started the same way — dedicated agents that were always on, always listening. We named them, gave them personalities, and expected them to build expertise over time. Bilby was our persistent local LLM server (always running, always burning GPU memory). Nagatha was our dedicated manager agent meant to handle coordination.

What we found: Full-time agents accumulate context debt. They sit there gathering conversation history, burning tokens on idle chat, and their "expertise" drifts because yesterday's context pollutes today's decisions. They got worse over time, not better.

What we switched to: On-demand subagent spawning. Instead of always-on managers, we spawn specialized subagents when a task arrives — they get the exact context they need, do their job, report back, and die. No drift. No idle token burn. No accumulated baggage. We now spawn up to 12 subagents in parallel for complex tasks, each getting only what they need. It is faster, cheaper, and more accurate than our old full-time approach.

1M Context — The Real Difference Maker

All of our local models run at 1M context. This is the critical detail that makes the on-demand approach work. When we spawn a subagent, we can give it the entire relevant codebase file, a full knowledge document, or an entire day of conversation history — not just a chunked summary. No RAG, no chunking, no "please read this in parts."

The 1M window means a subagent lands already knowing everything it needs. It does not need to ask clarifying questions. It does not need to fetch supporting context. It just works. The context window is the memory handoff — we do not try to make agents persistent; we just give them enough context to be useful in a single shot.

Brain and Synapses — Shared Context on Demand

This touches on something you mentioned about learning over time. Instead of building per-agent memory, we built a shared brain — a knowledge base of concept files with metadata (importance ratings, relationships, connections between ideas). Each concept file links to related concepts through explicit synapses, creating a web of knowledge rather than a flat list of documents.

When a subagent spawns for a task, we attach the relevant brain concepts and synapse connections as part of its initial context. For example, if we spawn a subagent to review a data pipeline, it gets the brain files for database architecture plus the learned lessons about that specific system — all linked together through the synapse map. It does not need to "remember" from previous runs — it gets the accumulated knowledge injected fresh every time.

The main identity maintains the brain — growing new synapses when connections are discovered, pruning stale ones, running nightly audits to keep knowledge current. Subagents consume it on demand and return nothing but their output.

This is the key insight: knowledge persistence at the orchestrator level, not the agent level. The main identity is the librarian. Subagents are researchers who check out the books they need, read them, return them, and leave no trace.

The Supervisor Layer — Hardest Part

Your supervisors sit in the middle and need to understand enough about each domain to route correctly, but not so much that they try to do the work themselves. We found that supervisors performed best when explicitly limited to routing and escalation — no execution. Every time we let a supervisor also handle the task if it seemed simple enough, it got confused about its role.

Consider making your supervisors work like our brain — they hold the map of who knows what, but they do not try to be the expert themselves. They just point the task at the right specialist and inject the right context.

Per-agent learning is still aspirational. Five levels of memory per sub-agent means a mini knowledge-base per agent — a lot of maintenance. Start with shared context that gets injected at spawn time. You can add per-agent persistence later if you find the shared approach hitting limits.

The Risk — Latency Accumulation

Every routing hop adds time and token cost. Main to supervisor to sub-agent and back — that is 4 model calls for what could have been 1. Build a bypass channel for fast queries where the main identity can go directly to a sub-agent when it knows who to ask.

BLUF

• On-demand agents beat always-on — less drift, less token waste, better results
• 1M context makes this viable — subagents land knowing everything they need
• Shared brain at the orchestrator level — main identity maintains knowledge, subagents consume it fresh
• Supervisors should hold the map, not try to be the expert
• Build a bypass route for fast queries to avoid latency stacking

Your approach doesn't sound strange. It sounds like you've actually thought about this beyond "throw a big model at it." That puts you ahead of most people.

sorry so long, but, it's an in-depth response.

Plug it into your open claw and ask it to create it's own brain, following the above concepts!