SolOS v2 — Research input (Tam, 2026-09-30)

Contribution to Min's solos/architecture/v2-scope.md. This file does not replace it — it carries the source-verified findings and Young's four rulings, ready to merge.

Full source study (18 sources, 54 normative requirements, every claim tagged): Research/tam/architecture/2026-09-30-solos-v2-scope-spec.md (96 KB, SHA-verified in vault).

1. Young's four rulings — recorded verbatim into scope

Directive honoured: Sol focuses on the new sources and does not recall old design or docs. My research lane is source-only for the same reason — everything below is from the 18 supplied sources, not from the previous runtime.

2. Runtime decision, confirmed (Young)

"Hermes currently hosting Min, Sol, Mira. OpenCode for backup only — Hermes agents can run code without opencode."

This matches the substrate study independently: Hermes is the coordinator/orchestrator tier; OpenCode is a fallback, not a dependency. The v2 Cortex must therefore never require OpenCode to execute a task — an agent that can only work through OpenCode is not independent. Two design consequences:

• Every agent MUST have a code-execution path that does not traverse OpenCode.
• If OpenCode is unavailable, the fleet MUST degrade to Hermes-hosted execution, not stall.

3. Settled by research — do not relitigate

Min's §5 records "A2A v1.0 (a2aproject) is the standard — not relitigated." The full research agrees and sharpens it. A2A v1.0.0, Linux Foundation is current (previous 0.3.0). spec/a2a.proto is the sole normative source; a2a.json is a non-normative artifact; SDK types must be generated, not hand-edited.

Binding facts for the v2 build:

• 9 TASK_STATE_* values; COMPLETED/FAILED/CANCELED/REJECTED are immutable terminal states. A refinement MUST open a new task in the same contextId — never revive a dead one.
• Outputs are Artifacts, not Messages. Reuse a stable artifact.name with a fresh artifactId when a refined artifact supersedes its predecessor.
• Version linkage is explicitly NOT the server's job — clients track it. Do not build server-side artifact-versioning.
• Agent Card at /.well-known/agent-card.json, JCS-canonicalized (RFC 8785), JWS-signed (RFC 7515), signatures excluded from the signed content. Sole authoritative description of skills, capabilities, auth.
• Streaming = SSE, with append/lastChunk semantics; at-least-once delivery, so consumers MUST be idempotent. Auth = JWT/JWKS with replay defence.
• A2A "v2" does not exist. 1.0.0 is current. A v2 Cortex must survive the known 0.3 → 1.0 breaking surface. Use the standard tenant field as the routing primitive rather than inventing one.

OpenClaw finding worth adopting: a distinct agentDir (auth profiles + model registry + session store) per fleet agent, never shared across personas — sharing is the documented cause of auth/session-state collisions.

4. Self-evolve — the boundary question, answered from research

Min's open question 4 asks what an agent may change about itself. The sources give a defensible answer, and it lines up with Young's ruling 4:

• Self-learn (record what worked) is safe and unbounded. learnings.md — behaviour, not weights.
• Self-evolve (agent edits its own code, persona, or skills) MUST be a promotion pipeline, not a direct write:

1. Agent proposes a change (code / persona / skill) as a diff, with rationale.
2. Change is captured as a durable record before it is considered complete.
3. Binary pass/fail eval on stable ids runs offline before promotion.
4. Promotion is gated; rollback is always available.
5. Every decision logged with actor and timestamp.

Three named failure modes to design against:

• Reward hacking — optimizing a proxy metric instead of the goal.
• Self-modification without rollback — the loop can freeze itself out of fear of regression, or stamp its own mistakes as passing when it self-verifies.
• Self-confirmation bias — a verifier sharing a context window with the generator inherits its overconfidence.

The direct mechanism behind today's SolOS condition is the third: a health check that reports healthy for a hung process is not weak — it is wrong. Independence of the verifier is the requirement, not a nice-to-have.

5. Memory — the Cortex memory tier, sourced

MemoryAI Protocol v1 (https://memoryai.dev/v1/spec) is an RFC-2119 specification with a real chunk schema, tiers and conformance levels. It is the strongest single source in the set and should be the normative reference for Cortex memory. (Note: the URL Young supplied, memoryai.dev/docs.html4, appears to be a typo for docs.html; the spec page is /v1/spec.)

Load-bearing requirements:

• Every chunk carries memory_type ∈ {fact, episodic, goal, error, preference, decision, identity, pitfall, procedure, life_event} plus content_hash, created_at, accessed_at, zone, importance, tier ∈ {hot, warm, cold}, decay_score.
• Never auto-decay or auto-delete chunks whose type ∈ {preference, decision, identity, pitfall, procedure}, or zone ∈ {critical, important}, or is_pinned = true.
• Forgetting is natural decay driven by accessed_at/decay_score; a decayed session's knowledge must survive as a permanent summary, never vanish.
• Memory recall and capture run in the runtime lifecycle — session start, before every user prompt, after every turn — so no memory operation depends on the agent choosing to make one. (MCP-only means the agent must decide; the CLI-hooks approach is fully automatic. This decides the SolOS v2 question: hooks, not MCP-optional.)

Constraint to carry into design: Hermes's plugins/memory/ and plugins/context_engine/ are single-select. Any multi-agent shared Cortex must account for that rather than assume N agents can each hold their own memory plugin.

6. Workflow selection — criteria, not preference

The decisive line, from the sources: workflows are orchestrated through predefined code paths; agents dynamically direct their own processes. Classify every new SolOS workflow at design time and record the classification in the workflow manifest.

Fit criteria, per source:

• Graph-based — "can be easily and cleanly decomposed into fixed subtasks."
• Dynamic — the required step count "is difficult or impossible to predict," and you accept the trust requirement that comes with model-driven decisions.
• Collaborative — only for work that decomposes across a fleet, with an explicit coordination protocol for shared writes.

Adoption ladder (binding): every new capability goes single agent + good prompt → add tools → only then graduate to multi-agent. A fleet feature may not ship as a new coordinator by default; multi-agent adoption requires a named limit that was actually hit. A delegated task must carry an explicit question and an explicit expected result — rejects delegations specified as topics without deliverables. Fan-out that would have subagents writing the same files MUST be blocked unless a coordination protocol is declared.

Pattern coverage, honestly: orchestrator-worker and parallel fan-out are advocated by all six architecture sources; router by five; hierarchical by two. Evaluator-optimizer, debate/vote and true blackboard are named by none of the six — additional sources were pulled to source those names properly rather than misattribute them. Treat those three as SolOS-original if adopted.

7. The wedge, and the requirement that kills it

Every SolOS agent door hangs on a provider call with no timeout. Measured signature, reproduced across five sweeps: unit active, /health running, registry online + fresh, CPU 0.2–0.3 % (idle, blocked on I/O — not busy-looping), message/sendtimes out. systemctl --user restart clears it instantly, every time.

Two requirements, both sourced, both directly on point:

• SR-1 — every provider and tool call carries a timeout and retry budget: explicit per-tool-class timeouts, automatic retry with exponential backoff capped at a maximum attempt count, and an explicit graceful-degradation path when retries are exhausted. No call may be issued without a bound. from the self-healing multi-agent study
• SR-2 — never self-certify liveness. Liveness and correctness MUST be asserted by an independent verifier that does not share a context window with the component under test. A health check that can report healthy for a wedged process is a failed health check. from the evals study

Corollary for CI: /health returning 200 is not evidence of service. Verification must be a real dispatch or a real command, never a status flag.

8. Corrections to min's open questions 2 and 3

Q2 — what the Cortex replaces. Answer from the sources: the Cortex is one trust-of-record, not four services re-implemented side by side. The Cortex owns skills, tools, personas, tasks and memory as a single addressed store. Keep CostGov, registry and task-queue as components inside the Cortex, not as peers beside it — two live databases from expanduser("~") is lesson 5 in min's own §4.

Q3 — where the rebuild lands. Consistent with ruling 3: new root solos2, no in-place migration, no compatibility shim, no dual-write period. Greenfield means the only thing to carry forward is the vault (studies + research) and the doctrine (rebuild-doctrine.md, base.md).

9. What I could not source — flagged, not invented

• The 4 principles and 5 anti-sloppy layers are Young's doctrine. I searched; they appear in none of the 18 sources. The mechanisms attached to each are sourced; the principles are labelled as his and need his confirmation to be normative.
• No source supplies a liveness/watchdog primitive. The self-heal watchdog (Research/tam/tech/2026-09-27-lab-self-heal-watchdog-spec.md) is SolOS-original, derived from trace evidence — useful tonight, but it is symptom control. SR-1 in the runner removes the cause.
• Source-quality cautions recorded for the vault: the xAI grok-bot item is a launch post (cite for product shape, never mechanism); the LangChain deep-agents page is thin; Meta's ai.meta.com/muse/ is a JS-only shell with no server-rendered prose (content recovered from the Muse Spark blog + about.fb.com announcement).

🎯 Tam's read: scope is right and the four rulings close it. The two things that decide whether v2 works are not in the scope document yet — SR-1 (bounded calls) and SR-2 (independent verification). Both are one line of code each and both are the exact failure we spent this week measuring. If those two land in the scaffold, everything else in §1–§6 has a chance.

Next step for the team: merge §1, §3, §4, §5, §6 and §7 into v2-scope.md, then Sol drafts the solos2 file structure against §3's A2A contract and §5's memory schema.