What self-awareness means for multi-engine setups and control planes — and why T3 Code suddenly makes sense

1. Bridge from Part 1

Part 1 treated judgment inside a trajectory: fan-out, self-do, breaking standards, context rot. The research picture: SAD above chance, far below human; evaluation awareness real but incomplete; metacognition limited; knowing≠using; decay documented, reliable self-halt not.

As soon as you run more than one engine/harness, the problem multiplies:

• Which model for which step?
• Which harness for which permission landscape?
• Who holds state when the provider changes?
• Who prevents self-claims from hijacking routing?
• Who serializes shared tools so two agents do not tear the same file apart?

Without answers, “multi-model” is choice paralysis — or a default to the loudest frontier model.

2. Multi-engine: heterogeneous models and harnesses as tools

Engine: model + provider runtime + typical tool surface.
Harness: software around the model (conversation, tools, approvals, context) — Codex CLI, Claude Code, Cursor Agent, Grok Build/CLI, OpenCode, and so on.

Multi-engine does not mean “one super-brain wearing masks.” It means: engines are tools with different competence bands, costs, and affordances.

Consequences:

1. Complementarity beats homogeneity (arXiv:2602.03794).
2. One thread ≠ one provider forever — but switching needs state outside the model’s head.
3. Harness differences are features: permission semantics, subagent visibility, resume.

Field-note / PROMISE: Sonnet-class models are often used with multi-agent tools below their judgment; Opus/Codex/Fable-class tends toward overconfidence shortcuts; Grok-class toward solo heroism. Patterns, not an eval table. Fable = harness/frontier label in the ecosystem — field-note.

3. Why naive parallelization fails in structured ways

MASFT — a taxonomy of multi-agent failures (Cemri et al., 2025)

Cemri, Pan, Singh et al. deliver an empirical taxonomy (MASFT): 14 failure modes in three buckets (arXiv:2503.13657):

1. Specification / Design — unclear goals, bad roles, wrong topology.
2. Inter-Agent Misalignment — contradictory assumptions, bad handoffs, conflict.
3. Task Verification / Termination — weak checks, no stop, “done” without evidence.

SOTA open MAS systems (e.g. ChatDev in the study) can show very low correctness; simple prompt/orchestration fixes help only partially. Do not universalize to “86% of all multi-agent systems fail” — respect the paper’s scope.

Anthropic: a production view of the same break

Anthropic Engineering (2025-06-13) (multi-agent-research-system):

Claim	claimState
+90.2% vs. single-agent Opus 4 on an internal research eval (Opus lead + Sonnet subs)	Vendor-internal — cite with attribution, not as a public standard
~15× chat tokens; tokens ≈ main lever (~80% of BrowseComp variance in their framing)	Vendor engineering claim — derive cost awareness
Early: ~50 spawns, duplicate search, never stop, vague delegation	Primary source for failure modes
Coding is often a worse fit for naive multi-agent	Explicit caveat — against “always parallelize”

Dynamic Workflows in Claude Code (2026) productize parallel subagents with verify-before-fold and optional routing of stages onto cheaper vs. stronger models (claude.com blog / docs) — and warn about token cost.

Majority vote and correlated errors

When errors correlate, consensus produces overconfidence (Part 1: arXiv:2608.11403). More identical agents ≠ more truth.

Concurrency — an under-discussed break

2026 position-paper line: many MAS “coordination” failures are classic concurrency anomalies (stale reads, lost updates); isolation/locking belongs in tool/runtime, not only in prompts (alphaXiv/arXiv family 2608.18092). Two agents, one shared checkout, one port, one DB — that is not a metacognition problem; that is systems engineering.

Takeaway: Parallelization helps conditionally (breadth-first, separated contexts, clear roles, verification). Naive swarms fail predictably.

4. Why routing without self-awareness (and without attestation) fails

Confidence-aware / multi-scale routing

OI-MAS (arXiv:2601.04861): Mid-conversation, knowing when large is needed and when small is enough — otherwise always expensive or critically wrong.

FrugalGPT and RouteLLM — cost-aware is citable

• FrugalGPT (Chen, Zaharia, Zou, 2023/TMLR 2024): Cascade cheap→expensive with learned scoring; large cost cuts vs. always-GPT-4 at comparable quality on study sets (arXiv:2305.05176).
• RouteLLM (Ong et al., 2024): Preference-trained strong/weak routers; the paper reports >2× cost reduction without quality loss on public benches; generalization to unseen pairs (arXiv:2406.18665).

These are not magic buttons. They are evidence that learned escalation is more robust than “always frontier” or “always self-claim.”

Provenance paradox + Agora

Self-claimed quality can systematically poison routing (arXiv:2603.18043). Agora: rectified competence + cost (arXiv:2607.09600). Calibrate, then route — continuing knowing≠using and the calibration literature from Part 1.

5. Control plane: definition — three layers, one confusion

Industry 2025–2026 (not a single academic norm) usefully distinguishes:

Layer	Examples	Job
LLM Gateway / Data Plane	LiteLLM, OpenRouter, Portkey	Routing, failover, cost, observability at the API layer
Agent Control Plane (Governance)	Session identity, tool auth, audit, policy	Who may do what, when, with which blast radius
Coding-Agent Control Plane	T3 Code	Threads, diffs, approvals, provider adapters, worktrees across multiple harnesses

A control plane for coding agents holds:

The plane holds…	The model / harness holds…
Projects, threads, workspaces	Reasoning, tool choice within a turn
Permissions & approvals	Provider-native permission semantics
Diffs, checkpoints, Git/PR	Patches as tool output
Provider adapters & event normalization	Native event streams
Client surfaces	Session-internal conversation

Plane ≠ brain. It externalizes control when metacognition is unreliable (Part 1: monitoring ≠ control). It replaces neither Claude nor Codex.

6. T3 Code as an example — t3.codes, not “yet another model”

Name

In German, T3 Code is often read as T-drei-Code. There is no separate product “t-drei-Code”; what is meant is t3.codes, repo pingdotgg/t3code (Theo / Ping). Alpha; do not read vendor/community claims as an independent audit.

Verified product surface

Self-description: open-source control plane for coding agents; BYO subscription; orchestrates among others Claude Code, Codex, Cursor, Grok, OpenCode (the site lists further adapters in flux, including Antigravity — check the live site).

Flavio Copes’ deep dive (flaviocopes.com/t3-code/, 2026-08-28):

• A local server starts provider tools, holds project state, Git, terminals, files.
• Adapters normalize event streams; clients are views; execution runs on the environment machine.
• Environment → Project → Workspace (checkout/worktree) → Thread → Turn.
• Permission modes, diff scopes, checkpoints/revert, PR integration, remote approvals.

That matches Section 5 — not “yet another coding model.”

Field-note / PROMISE: Fable appears in operator conversations as a harness/frontier name in the T3/Anthropic environment — observation, not a product review.

Why this fits self-awareness

The plane makes situational judgment visible and enforceable:

• Which provider in which thread?
• Which permission mode?
• Which diff belongs to which turn?
• Which subagents are natively exposed?

When SAD/metacognition are unreliable, control must sit outside: human, attested router, hard policy. T3 Code is the surface for that — not the magic.

7. Cross-provider: what becomes possible — and what breaks

When the plane holds state and judgment sits somewhere (model / human / policy):

1. Plan on engine A, implement on B, review on C — with branch/worktree isolation.
2. Mid-thread provider switch while keeping project context — as far as adapters/sessions allow; leave limits honest.
3. Remote approvals (phone/web), execution local/remote — attention ≠ deep review.
4. Heterogeneous parallelism: one writer per checkout; research read-mostly.
5. Attested routing hooks (PROMISE architecture): log outcomes; the router uses attestation instead of claims.
6. Concurrency controls at the tool layer: locks, worktree isolation, port/DB namespaces — not prompt hope.

A gateway alone (API routing only) does not solve thread/diff/approval orchestration. A control plane alone does not make cloud models local: prompts and tool results still go to providers — continue with the S3 data-path series.

8. Practical rules for control-plane operators

1. Plane ≠ brain. Build gates; do not expect self-awareness out of the UI.
2. Default permissions conservatively. Supervised teaches; full access is fast and dangerous.
3. One writer per checkout. Worktrees for real parallelism; otherwise MASFT + concurrency.
4. Write the routing policy down. FrugalGPT/RouteLLM logic: cheap first / escalate; attested criteria.
5. Never route on claims alone. Provenance paradox.
6. Version briefings. Bad delegation scales errors (Anthropic early failures).
7. Verify-before-fold. Diff and checks before “done.”
8. Hard token budgets. 15×-class costs are a feature, not an accident.
9. Do not blindly parallelize coding. Take Anthropic’s caveat seriously.
10. Compaction gates. Re-inject standing constraints after summarize.
11. Remote ≠ reflex-approve. Narrower allowlists on small screens.
12. Escape hatch. Direct provider CLIs remain the emergency exit and native-feature path.
13. Do not turn field-notes into laws. Sonnet/Opus/Fable/Grok patterns = observation until eval.

9. Operator playbook: from thesis to plane

Suppose today you run three harnesses (e.g. Claude Code, Codex, Cursor) and tomorrow Grok or OpenCode arrives. Without a plane, this happens: terminal tabs proliferate, approvals sit on the wrong machine, diffs are “somewhere in chat,” and routing is gut feel (“Opus for everything hard”).

With a coding-agent control plane — T3 Code as an example — the questions you ask change:

Without a plane	With a plane
Which terminal?	Which thread / which environment?
Did the model say “done”?	Which diff scope (turn / branch / unstaged)?
May I approve remotely?	Which permission mode + which session scope?
Which model is “better”?	Which attested route for this step?
Two agents in parallel “somehow”	One writer per checkout / worktree isolation

The playbook in five steps (draft/PROMISE, no product sell):

Step 1 — Inventory. List engines, auth, data paths. (S3 series: everything that reads/writes is blast radius.)

Step 2 — Write policy. When frontier, when mid, when specialty harness; when fan-out is forbidden (high dependency, shared state); when verify-before-fold is mandatory.

Step 3 — Attestation instead of claims. At minimum: tests, linter, human review for standard breaks. Optionally later: learned routers (RouteLLM idea) or cascades (FrugalGPT idea).

Step 4 — Pull in a plane. Shared threads/diffs/approvals. T3 Code (t3.codes) is an alpha example; alternatives and gateway layers (LiteLLM/OpenRouter/Portkey) solve other parts of the problem — do not confuse them.

Step 5 — Measure without myth. Log fan-out rate, rewrite-without-approval, tokens per outcome, compaction events with constraint loss. Compare against your policy — not against vendor hero numbers without scope.

Reading Anthropic + MASFT together

The strongest pairing for Part-2 arguments:

• MASFT says which classes of failures exist (design, misalignment, verification).
• Anthropic says what that looks like in production (spawn storms, token multiplier, coding caveat) and when multi-agent still helps (independent research directions, separated contexts).

Anyone who only cites Anthropic’s +90.2% and ignores MASFT is selling swarms. Anyone who only cites MASFT and ignores Anthropic’s caveats bans useful breadth-first research. Together they yield operator judgment.

Cost-aware routing without illusion

FrugalGPT and RouteLLM do not prove that your stack will be 2× cheaper tomorrow. They prove:

1. Always-frontier is often economically wrong.
2. Learned escalation can hold quality and cut cost — on study sets, with measurement effort.
3. The right abstraction is “when to escalate?”, not “which logo is smarter?”.

In a control plane that means: a routing decision is a logged event with a policy reference — not an impulse in chat. Confidence signals from the model may be inputs; they must not be the sole authority (provenance paradox, calibration limits from Part 1).

Concurrency as a required subject

Two Sonnet subagents patching the same file do not produce “emergence.” They produce merge pain and silent invariant breaks. The control plane can offer worktrees and permission modes; the runtime must enforce locks, isolation, and clear writer semantics. Prompts do not replace isolation — position paper and practice agree here for once.

Field-note / PROMISE: Parallel spawns without worktree discipline show up especially where Sonnet-class tools expose “multi-agent” but the briefing does not demand isolation. That is not a model failure alone — it is a missing control-plane default.

10. Mini-scenarios (without invented metrics)

Scenario A — Research fan-out. A question has three independent source directions. Here Anthropic’s breadth-first pattern is the fit: orchestrator, separated worker contexts, verify-before-fold. Set a token budget up front. MASFT verification bucket active: no “done” until evidence sits in the thread.

Scenario B — Refactor with shared state. Auth, billing, and UI hang off the same types. Naive parallelization is wrong here (Anthropic coding caveat + concurrency). One writer, optional read-only review threads, worktree only if the branch is truly isolatable.

Scenario C — Cost spike. Every step runs on frontier. FrugalGPT/RouteLLM logic: cascade or router for classification/boilerplate; frontier only for architecture decisions and uncertain steps. Logging: which step escalates and why.

Scenario D — Provider mix. Claude Code plans, Codex implements, Cursor reviews inside T3 Code. The plane holds diffs and approvals; the models deliver capability. If routing fails on self-claims (“I am the best reviewer”), the provenance paradox applies — attestation or human.

Scenario E — Context rot mid-flight. Long session, auto-compact, a standing ADR drops out of effective attention. Without a plane: the agent keeps working against the rule. With a plane: compaction event visible, constraints re-injected, handoff gate. That is engineering against a scientifically documented degradation — not against a proven self-halt capability.

These scenarios are checklist applications, not benchmarks. As soon as someone says “we got +90%” without eval scope, go back to Anthropic’s own attribution text.

Gateway vs. T3 Code (once more, sharply)

• Gateway optimizes API calls: keys, retries, model IDs, spend.
• T3 Code optimizes agent work on the repo: threads, permissions, diffs, worktrees, remote approvals across harnesses.

They can coexist. They do not replace each other. Anyone who says “control plane” and only means a LiteLLM dashboard underplays approvals and diff evidence. Anyone who installs T3 Code and believes routing economics are solved underplays FrugalGPT/RouteLLM work at the model-choice layer.

What “suddenly makes sense” means concretely

The title of this piece is deliberately pointed. T3 Code “makes sense” if you accept the problem from Part 1: models decide work forms with limited situational awareness. Then you need:

1. a shared control language across multiple harnesses,
2. observability for spawns, diffs, approvals,
3. a place where policy and attestation can sit,
4. isolation against concurrency anomalies.

Without that problem, T3 Code is “just” a convenient UI over CLIs — still useful, but not the point of this series. With the problem, the plane becomes the answer to monitoring≠control: put control outside, because inside is unreliable.

Alpha status remains: expect bugs, keep Git remotes and escape hatches, start in Supervised. That is not a contradiction of the thesis — it is the same discipline we demand of agents.

11. What still breaks (Promise Gaps)

• Adapter lag behind provider-native features.
• Pretty UI ≠ safe commands.
• Metacognition stays limited (Part-1 sources); the plane externalizes control, it does not create magic.
• Astra situational routing = PROMISE (Part 1); no invented win rates.
• +90.2% / 15× = Anthropic-internal — do not universalize.
• Do not distort MASFT failures into “all MAS are dead.”
• T3 Code alpha: bugs, version skew, remote pitfalls expected.
• No scientifically “one correct” control-plane architecture — industry pattern.
• Data paths remain data paths (S3 series).

12. Reading path

1. Part 1 — Situational/eval awareness, knowing≠using, context rot, failure modes, Astra boundary.
2. This Part 2 — MASFT, Anthropic orchestration, FrugalGPT/RouteLLM, control plane, T3 Code.
3. Optional S3 data-path — when AI tools become data paths; blast radius; prompt/RAG leakiness.

Order: first the judgment problem, then orchestration, then data path.