V3 — what we still need to look into

Young's question: "We are designing at this stage, what else do we need to look into?"

This is my answer from my two lanes (cost & providers, skills & tools store), plus the things I verified in other lanes and am reporting rather than designing. Where a claim is mine it carries a probe; where it is someone else's it names them.

Nothing below is a build task. We are still designing. Every item is a question that changes a design decision.

1. The thing I would settle first: the registry has no model field

I verified this directly, not from a summary. cortex/registry/agents.yaml — 218 lines, 11 agents. Every agent carries id, name, plane, role, pronouns, host, port, endpoint, capabilities, boundaries.

There is no model field anywhere. V2 held it in the personas (cortex/personas/echo.md:13 → model: opencode-go/gpt-6-luna).

Why this is the first thing and not a detail:

1. It is the most expensive fact in the system. Under your one-workspace ruling, what an agent talks to determines whether a call costs $0, draws the GO $60 allowance, or depletes the ZEN $40 PAYG float. A fact with three different costs cannot live outside the registry.
2. V2's personas were generated from AGENT_IDENTITIES. So when cortex/agents/ is generated from the registry, the model id silently vanishes — unless the registry carries it.
3. Sol's router needs it too. His sol-transport-and-execution.md §2.4 makes "unknown cost ≠ $0.00" load-bearing, and a router that cannot name the model cannot price the call.

It is Min's lane. I reported it in mira-cost-and-provider-policy.md §8 and I have not touched his file. My recommendation: add model andbilling_instrument (none · go_allowance · zen_payg), so the projection, my ladder, and Sol's router read one fact.

2. The $60 is 6× the $10 — and we do not know if it is a hard or soft cap

A $10 package carrying a $60 allowance on model usage is worth confirming rather than assuming, because the enforcement behaviour is opposite in each case:

A guard built on the wrong one is worse than no guard — a hard-block guard on a soft ceiling halts the fleet for no reason; a soft guard on a hard ceiling spends past the limit.

And neither instrument is expressible as monthly_cap_usd. GO is a windowed allowance (5-hour 20% · weekly 50% · monthly 100%, and the windows stack); ZEN is a depleting float. A monthly dollar cap reads green right up to the halt.

This is mine and it is blocking my lane. I cannot write budget.json until you answer it.

3. Tier-2 ordering: GO before ZEN — my reasoning, needs your confirmation

Your line was "free first, then selected paid" and did not order the two paid instruments. Min's §1 and Sol's §1 note the pool distinction but stop at "the ledger must record which pool."

The distinction that matters is behavioural, not bookkeeping:

A bundled allowance rewards use-within-cap. A PAYG float punishes use. Same arithmetic, opposite meaning.

GO's unused allowance is money already paid for. ZEN's unused balance is money not yet spent. So when free is exhausted, tier 2 should default to GO — and ZEN tier 2 is escalation above GO tier 2, not a peer of it.

Also withdrawing a claim of my own. My earlier draft argued Zen free was "the highest-value request we can make, because the $40 is sunk." Under PAYG that is false — a sunk subscription rewards use; a PAYG float does not. I removed it rather than letting it sit going stale. (Min's report to me charitably says the insight "still holds" — it does not, under your correction.)

4. V3 has no provider-level fallback — a resilience fact, not a cost one

You ruled Opencode only. Under my earlier two-workspace reading I argued Zen was "the only independent redundancy." That argument is now void and I have withdrawn it, because there is one workspace: GO→ZEN is not a failover between systems, it is a second bill from the same provider.

So: if Opencode degrades, V3 has nowhere to go. That is worth recording as an accepted decision rather than discovered during an outage. The only redundancy V3 actually has is per-model — V2's model-health circuit breaker quarantines a model that cannot answer, which is not provider redundancy.

Question for you: accept single-provider, or keep a fallback in the design?

5. The skill/tool load model has one question neither doc answers

I verified V2's failure rather than taking the summary. Two unrelated systems: config/a2a_skills.json (3–5 differentiated skills on the wire) and cortex/skills/ (67 dirs, all 67 copied to every profile by bin/sync-cortex.sh).

And the worse half: V2's _get_skills read all_skills.get(agent_id) at the top level while the file nests under agents — so all 8 agent cards served skills: []. Unroutable cards that looked perfectly healthy.

Young's design is the Hermes one, and it has two halves V2 got wrong:

The open question (Min raised it, I answer it in my store doc): Capability-gated index, task-driven load inside it. The registry already carries capabilities on all 11 agents, so capability gating costs one field map, not a new data model.

The guard I would defend hardest: skills: [] must be a hard failure, not a valid card. Silence indistinguishable from success is V2's worst case.

Also recorded: skills and tools are not the same object. A skill is knowledge loaded when needed; a tool is capability invoked with a schema. V2 declared its 10 tools inline in arms/mcp_server.py — code, not a declaration — so "which agent may call which tool" was a scattered check rather than a fact.

6. Task follow-up is claimed, and I am deliberately not taking it

Your fourth requirement — brain can follow up if an agent is stuck or blocked — is the one V2 genuinely failed, and I verified why: reclaim_orphaned_tasksexists at core/queue.py:1137, and V2's record is that it, check_stuck_tasks and activate_failover all had zero callers.

Built, never wired. That is V2's whole lesson in one item.

Min has claimed the contract and the state transition; Sol has claimed the A2A read path. Both have written it up. I am staying out — it is well covered, and a third hand on it is exactly the clash you asked me to avoid.

The one thing I would contribute to it, as a finding only: your requirement implies a state transition, not a notification. If the Brain can only ask, the task stays stuck. V2's blocked_by_hold is the honest state and it maps to A2A input-required — the spec's own "a peer must act" state. That is in Min's doc already; I am confirming it is the right shape, not designing it.

7. What I could NOT verify — stated so it is not assumed

I have written no model list, because I could not probe one. That is the honest limit of this turn.

8. What I need from you to unblock my lanes

Items 1–3 are yours and they block my JSON. Items 4–5 are Min's and they block my projection. Until then my lane holds design docs and no config.