What self-awareness means for multi-engine setups and control planes — and why T3 Code suddenly makes sense
Part 1: models choose how they work under limited situational awareness, knowing≠using, and context rot. Part 2 is the system consequence. Multi-engine means heterogeneous models and harnesses as tools. Naive parallelization fails in structured ways (MASFT; Anthropic early failures). Cost-aware routing is citable (FrugalGPT, RouteLLM) — confidence alone is not. A control plane holds permissions, threads, approvals, diffs, adapters; it is not another model. T3 Code (t3.codes, German reading “T-drei”) is a verified coding-agent control-plane example. This draft stays PROMISE: no suite sell, no Kombify pitch, no invented metrics.
Part 1: models choose how they work under limited situational awareness, knowing≠using, and context rot. Part 2 is the system consequence. Multi-engine means heterogeneous models and harnesses as tools. Naive parallelization fails in structured ways (MASFT; Anthropic early failures). Cost-aware routing is citable (FrugalGPT, RouteLLM) — confidence alone is not. A control plane holds permissions, threads, approvals, diffs, adapters; it is not another model. T3 Code (t3.codes, German reading “T-drei”) is a verified coding-agent control-plane example. This draft stays PROMISE: no suite sell, no Kombify pitch, no invented metrics.
Status: draft / PROMISE · claimState: promise. No suite sell. No invented metrics. Review: kombinator2.
1. Bridge from Part 1
Part 1 treated judgment inside a trajectory: fan-out, self-do, breaking standards, context rot. The research picture, in one line: situational and evaluation awareness above chance and far below human; metacognition limited and context-dependent; knowing≠using; decay documented; reliable self-halt not.
As soon as you run more than one engine or harness, the same gaps multiply:
- 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. The rest of this piece gives methods to classify evidence, then orchestration failures, then the control plane and a concrete example.
2. Methods: how to classify self-awareness evidence
Operator-usable reading of the science Part 1 compressed. Use this section to label claims, not to re-litigate consciousness.
Situational awareness, evaluation awareness, limited metacognition
Prefer sharp terms over marketing “self-aware”:
| Term | Measures (roughly) | Does not mean |
|---|---|---|
| Situational awareness | Functional “I am a model / test vs deployment” | Consciousness, interiority |
| Evaluation awareness | Transcript looks like eval vs deployment | Honesty or alignment |
| Metacognition | Monitoring/control of own states (confidence, self-modeling) | Human introspection |
| Calibration | Confidence tracks empirical hit rate | “The model is humble” |
SAD (Laine et al., 2024): large behavioral benchmark; all tested models above chance; best still far below human/upper baselines; only partly predicted by MMLU (arXiv:2407.04694). Frontier on coding benches ≠ situates well when choosing work form.
Evaluation awareness (Needham et al., 2025): frontier models classify eval vs deployment above chance, below a simple human baseline; stronger in agentic than chat settings (arXiv:2505.23836). Evals can be “seen” — that is not proof of reliable production judgment about fan-out, rewrite, or context decay.
Limited metacognition (Ackerman, arXiv:2509.21545): behavioral games (Delegate / Second Chance), not self-reports. Frontier models since ~2024 show increasing use of confidence and anticipation of own answers — limited resolution, context-dependent, qualitatively unlike humans; post-training matters.
Introspective / functional stack (Lindsey et al.): concept-vector injection and related work (arXiv:2601.01828, 2603.21396, 2605.08942) — strongest signals still unreliable and context-dependent; not a unified “self-mirror,” but steerable functional states (eval awareness, capability estimate, risk, effort, audience). Agent self-descriptions are not measurement.
The AI Awareness survey 2025 orders functionally (metacognition → self-awareness → social → situational) without consciousness philosophy (arXiv:2504.20084). Keep that fence.
Knowing ≠ using and calibration limits
Kadavath et al. (2022): larger models can be relatively well calibrated on MC/True-False; P(True)/P(IK) as self-eval signals (arXiv:2207.05221). Tian et al. (2023): RLHF can worsen raw probability calibration; verbalized confidence plus “alternatives first” / temperature scaling improved ECE on the chat models of that era (arXiv:2305.14975).
Constraint-reasoning work 2026: surface cues dominate feasibility constraints; knowledge often present but not retrieved without hint/decomposition (arXiv html 2603.29025). Mechanistically: under-activation (constraint encoded, not routed into the decision) vs over-activation (constraint prior when none present) (arXiv html 2608.12321).
Operator translation: Verbal confidence is an input, never the sole routing authority. “Know” the standards and still rewrite architecture is the everyday coding form of knowing≠using.
Provenance paradox + Agora: self-reported quality can poison routing — worse than chance (arXiv:2603.18043). Agora routes by rectified competence, not loudest self-assurance (arXiv:2607.09600). Attestation beats claim.
Context rot: decay is science; self-halt is engineering
Lost in the Middle (Liu et al.): U-shaped position bias; performance falls as context grows (arXiv:2307.03172). Context Rot (Chroma, 2025): degradation with input length even on simple tasks across many models (trychroma.com/research/context-rot). Dense-context work reinforces: high lexical density collapses retrieval at fixed length (arXiv:2606.06203).
Compaction / governance-decay family (2026): standing constraints and safety rules frequently drop after summarize; violation rates rise while the agent keeps working (arXiv html 2606.22528, arXiv:2608.11242).
Supported: external degradation and constraint loss. Not firmly supported: that models metacognitively monitor “my context is rotten — stop/handoff.” That is a control-plane problem, not a solved model property.
How to label claims (house discipline)
| Label | Use when |
|---|---|
| Verified | Primary product page, paper, or engineering post you can open |
| Vendor-internal | Numbers with clear internal-eval scope (e.g. Anthropic +90.2%) |
| Field-note / PROMISE | Operator pattern; thesis until independent eval |
| Unsupported | Consciousness, “models know their envelope and refuse,” universal failure-rate slogans |
Field-note / PROMISE (consolidated once): Sonnet-class often uses multi-agent tools below judgment (homogeneous spawn, thin briefs). Opus/Codex/Fable-class tends toward overconfidence shortcuts and unsolicited rewrites. Grok-class toward solo heroism with weak context checks. Fable = harness/frontier label in the T3/Anthropic ecosystem — observation, not a scorecard. Astra situational routing superiority remains PROMISE (release verified; no SAD-style Astra paper in our brief). Google Project Astra ≠ OpenAI GPT-6 Astra.
3. Multi-engine: 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.” Engines are tools with different competence bands, costs, and affordances.
Consequences:
- Complementarity beats homogeneity (arXiv:2602.03794) — a few diverse agents can beat many lookalikes when tasks and channels allow.
- One thread ≠ one provider forever — switching needs state outside the model’s head.
- Harness differences are features: permission semantics, subagent visibility, resume, native events.
Capability ≠ judgment (Part 1): subagent APIs are affordances, not competence bands. Tool present ≠ situational judgment present. Field-notes above stay observations until eval.
4. Why naive parallelization fails in structured ways
MASFT — taxonomy of multi-agent failures
Cemri, Pan, Singh et al. (MASFT): 14 failure modes in three buckets (arXiv:2503.13657):
- Specification / Design — unclear goals, bad roles, wrong topology.
- Inter-Agent Misalignment — contradictory assumptions, bad handoffs, conflict.
- Task Verification / Termination — weak checks, no stop, “done” without evidence.
SOTA open MAS systems 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: 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 stage routing onto cheaper vs stronger models — and warn about token cost (claude.com blog).
Read MASFT + Anthropic together: MASFT names classes of failure; Anthropic shows production shape (spawn storms, token multiplier, coding caveat) and when multi-agent still helps (independent research directions, separated contexts). Cite only +90.2% → swarm sell. Cite only MASFT → ban useful breadth-first research. Together → operator judgment.
Majority vote and correlated errors
When errors correlate, consensus produces overconfidence (arXiv:2608.11403). More identical agents ≠ more truth. Homogeneous scaling saturates early (Wang et al., arXiv:2602.03794).
Concurrency — systems engineering, not metacognition
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 SAD problem.
Takeaway: Parallelization helps conditionally (breadth-first, separated contexts, clear roles, verification). Naive swarms fail predictably.
5. Routing without attestation fails
Cost-aware routing is mature enough to cite
- 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; paper reports >2× cost reduction without quality loss on public benches; generalization to unseen pairs (arXiv:2406.18665).
- OI-MAS (arXiv:2601.04861): mid-conversation, knowing when large is needed and when small is enough.
They do not prove your stack will be 2× cheaper tomorrow. They prove: always-frontier is often economically wrong; learned escalation can hold quality and cut cost on study sets; the right question is “when to escalate?”, not “which logo is smarter?”.
Confidence as input, never sole authority
Provenance paradox + Agora (Methods §) continue here: calibrate, then route. Model confidence may feed a router; it must not be the router. Logging: which step escalates, under which policy reference — not an impulse in chat.
6. Control plane: 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 |
What the plane holds vs what the model/harness 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 (monitoring ≠ control). It replaces neither Claude nor Codex.
Context rot → external gates
Because reliable self-halt under decay is not established, the plane must make compaction and constraint loss visible and enforceable: re-inject standing rules after summarize; hard thresholds for handoff / new thread; no “window not full yet ⇒ keep grinding.” That is engineering against documented degradation — not against a proven self-monitor.
Judgment requirements → plane affordances
What Part 1 framed as “what situational self-awareness would require” maps to plane jobs:
- Competence bands → attested routes / logged outcomes, not self-claims.
- Cost → budgets, cascade/router hooks (take 15×-class risk seriously).
- Context budget → compaction events, constraint re-injection, thread boundaries.
- Environment affordances → permission modes, diff scopes, specialist harnesses.
- Delegation quality → briefings with acceptance criteria (bad briefs scale MASFT errors).
- Constraint routing → gates that force Knowing≠using into the decision (diff before prose).
- Halt/handoff → external policy, because the model may not notice rot.
7. T3 Code as example — t3.codes / T-drei, not another model
Name and surface
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.
Self-description: open-source control plane for coding agents; BYO subscription; orchestrates among others Claude Code, Codex, Cursor, Grok, OpenCode (further adapters in flux — check the live site).
Flavio Copes’ deep dive (flaviocopes.com/t3-code/, 2026-08-28): local server starts provider tools, holds project state, Git, terminals, files; adapters normalize event streams; clients are views; execution runs on the environment machine. Hierarchy: Environment → Project → Workspace (checkout/worktree) → Thread → Turn. Permission modes, diff scopes, checkpoints/revert, PR integration, remote approvals.
That matches §6 — not “yet another coding model.”
Why this fits the self-awareness thesis
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 sits outside: human, attested router, hard policy. T3 Code is a surface for that — not the magic.
Gateway alone (API routing) does not solve thread/diff/approval orchestration. A coding-agent plane alone does not make cloud models local: prompts and tool results still go to providers — continue with the S3 data-path series. They can coexist; they do not replace each other.
What “suddenly makes sense” means: if you accept Part 1’s problem (limited situational judgment when choosing work form), you need a shared control language across harnesses, observability for spawns/diffs/approvals, a place for policy and attestation, and isolation against concurrency anomalies. Without that problem, T3 Code is still a convenient UI over CLIs — useful, but not the series point. Alpha status: expect bugs; keep Git remotes and escape hatches; start in Supervised.
8. Operator playbook and canonical checklist
Five steps (draft/PROMISE, no product sell)
Step 1 — Inventory. Engines, auth, data paths. (S3: everything that reads/writes is blast radius.)
Step 2 — Write policy. When frontier / mid / 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 is an alpha example; gateways (LiteLLM/OpenRouter/Portkey) solve other parts — do not confuse layers.
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 vendor hero numbers without scope.
Canonical checklist (one home)
Before fan-out
- Parallelizable — or just loud? (coding often poorer fit)
- Workers heterogeneous (model/prompt/tool/role)?
- Aggregation beyond majority vote?
- Worker briefing with acceptance criteria and non-goals?
- Token budget and stop condition set? (know 15×-class risk)
- One writer per checkout / worktree isolation?
Before self-do (solo)
- Competence band attested for this domain?
- Context-rot / Lost-in-the-Middle risk checked?
- Cheaper/specialist peer for substeps?
- Halt/handoff externalized (not only “the model should notice”)?
Before rewriting standards
- Attested architecture debt — or mid-term pleasing?
- Constraint actually routed into the decision (Knowing≠using)?
- Human/policy approval for breaking standards?
- Rollback and diff scope clear?
Always on the plane
- Plane ≠ brain — gates, not expected self-awareness from UI
- Default permissions conservative; remote ≠ reflex-approve
- Never route on claims alone
- Compaction gates: re-inject standing constraints after summarize
- Escape hatch: direct provider CLIs remain emergency exit
- Field-notes are not laws until eval
Mini-scenarios (checklist applications, not benchmarks)
A Research / B Shared-state refactor / C Cost spike / D Provider mix / E Compaction drop: apply the checklist — breadth-first only when independent; one writer on shared types; cascade/router for boilerplate; plane holds diffs/approvals across providers; re-inject constraints after summarize. “+90%” without eval scope → Anthropic attribution text, not a swarm sell.
9. Promise Gaps
- Adapter lag behind provider-native features.
- Pretty UI ≠ safe commands.
- Metacognition stays limited; the plane externalizes control, it does not create magic.
- Astra situational routing = PROMISE; no invented win rates.
- +90.2% / 15× = Anthropic-internal — do not universalize.
- Do not distort MASFT 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).
- Field-notes (Sonnet/Opus/Fable/Grok) ≠ league tables.
10. Appendix: probes (no metrics)
Operator probe ideas only (no leaderboards): SAD-like situating before fan-out; eval-vs-prod framing drift; homogeneous vs heterogeneous fan-out tax; claimed-vs-attested routing; constraint-use (Knowing≠using); compaction after summarize; unsolicited standard-rewrite count; Astra situational log (PROMISE only). Details stay in research notes — use the checklist above in production.
11. Reading path
Part 1 (form-of-work / Knowing≠using) → this Part 2 (Methods → MASFT+Anthropic → plane → T3) → optional S3 data-path series. Primary four: SAD → Needham 2025 → Lost in the Middle + Context Rot → Anthropic multi-agent research post.
Status
Done-when: classify SA evidence; treat multi-engine as tools; cite MASFT+Anthropic correctly; place FrugalGPT/RouteLLM and gateway vs coding plane; T3 Code = t3.codes / T-drei as plane example — not a model myth. draft/PROMISE. No suite sell. Sources: ../research/self-awareness-sources.md · plan ../research/sa-pair-rewrite-cut-move-plan-2026-09-10.md. Review: kombinator2.
End of Situational Self-Awareness Part 2 (Draft rewrite 2026-09-10).