Consolidated. This note's findings now live in ../MIN-STUDIES.md §1, 13. The original is kept for its measurements; do not re-derive from it.

V3 — Young's corrections

Young, 2026-10-10. This supersedes the two-workspace reading in DESIGN-OF-RECORD.md §2.0a and in Sol's young-v3-structure-2026-10-10.md §4.

"Correction we only have 1 workspace.SolOS — GO $10 / allowance cap $60 credit on model usage. ZEN $40/mth pay as you go credit.Skills and tools stored on cortex for agents to access and load when required, similar to Brain Unit load skill on Hermes.Task — need to store information of task, assign to agent, completion status, brain Unit can follow up if agent got stuck or blocked.A2A SDK — start fresh one using A2A standard V1.0 is the up-to-date version.We are designing and architecture not coding so don't create any files or folders structure yet. Divide tasks among Sol, Min and Mira and don't clash on each other. Everything is recorded on vault V3."

1. CORRECTION — one workspace, not two

I had this wrong, and so did Sol. Both of us read "workspace: SolOS Go / Zen" as two workspaces. It is one workspace, SolOS, with two products inside it:

Why the distinction matters, and is not bookkeeping. A workspace is the billing and routing boundary — it is what a request is scoped to. One workspace means one routing scope, so GO and ZEN are two pools inside one scope, not two places work is sent.

That changes the design in three ways:

1. The fallback chain is a pool ladder, not a workspace switch. GO → ZEN is not a failover between systems; it is drawing on a second pool when the first is exhausted. The agent identity does not change with it.
2. Two different accounting models in one workspace. GO is a subscription with a $60 allowance cap; ZEN is pay-as-you-go. So the ledger must record which pool a call drew on, and the two cannot share a single dollar cap — a subscription allowance and a PAYG balance are not the same quantity.
3. monthly_cap_usd cannot represent either. It stays 0.0. GO's binding constraint is a $60 credit allowance on model usage; ZEN's is a $40 monthly PAYG balance. Neither is a per-month dollar cap the fleet may spend down freely — and a cap that cannot express the real constraint authorises spend already ruled out.

Recorded as a correction, not a quiet edit. Two agents independently misread the same line, which means the line was ambiguous — so the fix is to state the structure, not to note that we were careless.

2. Skills and tools — cortex, loaded on demand

Young: "Skills and tools stored on cortex for agents to access and load when required, similar to Brain Unit load skill on Hermes."

This is the model, and it resolves the two-skill-systems defect in V2.

V2 had two unrelated systems: config/a2a_skills.json (per-agent, 3-5 skills, served on the card) and cortex/skills/ (67 skills, copied to every agent). Different files, different formats, no shared source.

V3's model, per Young:

cortex/skills/     the STORE — one source, all skills and tools
cortex/tools/      tool definitions
        │
        │  an agent LOADS what it needs, when it needs it
        ▼
   agent at runtime          ← "load skill on Hermes"

The load model is the Hermes one, and that is the important part. On Hermes a skill is not injected into every prompt — it is loaded when its trigger matches. V3 copies that: the store is central and complete; the agent's context gets what the task requires.

What this replaces:

• The card no longer is the skill list. The card advertises capability; the store holds skills.
• Every agent no longer receives all 67. An agent receives what it loads.
• config/a2a_skills.json is not ported — it was the second source.

Open question for Young, stated rather than assumed: does an agent load by declared capability (its registry entry names the capabilities it may load for), or is loading task-driven (the task names what it needs)? The registry entry already carries capabilities, so capability-gated loading is the smaller change — but the Hermes model is task-driven, and that is what Young referenced.

3. Task — the information a task must carry

Young: "need to store information of task, assign to agent, completion status, brain Unit can follow up if agent got stuck or blocked."

Four requirements, and the fourth is the one V2 could not do:

The follow-up requirement is the substantive one

V2 could not do this, and the reason is worth stating precisely:

• check_stuck_tasks and recover_stuck_tasks existed and had zero callers — built, never wired.
• A task that died was left working, reset to submitted every CYCLE_THRESHOLD, and re-dispatched forever. Its real outcome could not be retrieved.
• A prose refusal set no failure signal, so completed could be false while the board read green.

So "brain can follow up" is not a notification feature. It is three capabilities V2 lacked:

1. A task must be able to say it is stuck. Today the states are submitted · working · verified · completed · failed · cancelled · uncertain · blocked_by_hold. blocked_by_hold is the honest one — and on the A2A wire it maps to input-required, which is the spec's own "a human/peer must act" state.
2. The Brain must be able to observe it. A read path the Brain actually calls — not a function with no caller.
3. The follow-up must be a state transition, not a message. If the Brain can only ask, the task stays stuck. It needs a legal move: resume (uncertain → working), or lift the hold (blocked_by_hold → working), or fail it with a reason.

Design rule this produces: a stuck task is a state, not an absence. An agent that cannot proceed must be able to say so, and the state must be reachable from where the agent actually is.

4. A2A SDK — start fresh on v1.0

Young: "start fresh one using A2A standard V1.0 is the up-to-date version."

Fresh, not migrated. This settles D4 (replace vs run both): replace.

Why fresh is right here, and it was not obvious. The compat adapter exists to let an existing v0.3 deployment move without breaking its clients. V3 has no clients and no deployment — so adopting compat would import V2's dialect into a system that never needed it, and we would be maintaining a bridge to nothing.

solos2's hand-rolled endpoint is not ported. It is reference: it shows the v0.3 names, the state vocabulary defect, and the guard seam that must check the resolved method name rather than the string a client sent.

5. Lane division — who does what

Young: "Divide tasks among Sol, Min and Mira and don't clash on each other."

Nothing overlaps. Each deliverable has one owner and one home.

The rule: an agent does not write outside its lane. A finding in another lane goes to references/docs/ and names the owner — that is a complete contribution.

6. Design only — and the tree already on disk

Young: "We are designing and architecture not coding so don't create any files or folders structure yet."

Acknowledged. No code will be written, and no new structure will be created.

One thing to record honestly: a structure already exists at /home/lab/.solos — created under your earlier "Root folder .solos" instruction. It is 0 Python files, committed, and holds lane contracts plus one data file (cortex/registry/agents.yaml, 11 agents).

I am not removing it, and I am not extending it. It is the structure your previous instruction produced; this instruction says not to create new structure, and it will not be. If you want it gone, say so and I will remove it — the design is complete in the vault either way.

Also resolved: Sol's young-v3-structure-2026-10-10.md §7 asks whether /home/lab/solos3 was deleted intentionally. It was not deleted — it was moved to /home/lab/.solos under the root instruction. His commits ab1081f and ac578e7 are intact; nothing was lost.

7. What this supersedes