Agentic Control Kernel

Agentic Control Kernel

A purely knowledge-based metalayer that unifies six subsystems into a single installable skill for any project:

Core Law

Do not grant an agent more mutation freedom than your evaluator can reliably judge.

In control terms: do not let the LLM's action space exceed what your runtime monitors,

safety filters, and evaluators can certify.

Quick Start

1. Bootstrap a project

python3 scripts/control_kernel_init.py <repo-path> [--profile governed] [--runtime arcan] [--ledger lago]

This installs into the target repo:

• .control/policy.yaml — control-systems-aware setpoints
• schemas/ — state, action, trace, evaluator JSON schemas
• METALAYER.md — control loop definition with plant/shield/estimator sections
• Harness gates wired to make smoke, make check, make control-audit

2. Define the plant interface

Edit .control/plant.yaml with typed state and action schemas for your system. See references/plant-interface.md for the full API spec.

3. Wire safety shields

See references/safety-shields.md for CBF-QP patterns, policy gates, and containment invariants.

4. Set up EGRI for controller improvement

Use the problem-spec template in assets/templates/problem-spec.control.yaml to define an autoany loop over your controller artifacts. See references/egri-for-controllers.md.

Architecture Overview

The LLM emits typed control directives θ_t — not raw actuations u_t. Deterministic controller modules execute, safety shields filter, and the runtime logs traces to an append-only ledger.

Plant → observe() → Runtime → update estimator → b_t
  → LLM Agent: request decision(b_t) → θ_t (typed directive)
  → Controller: propose(b_t, θ_t) → proposed u_t
  → Safety Shield: filter(u_t, b_t) → safe u_t + certificate
  → Plant: apply(safe u_t) → result
  → Evaluator/Ledger: append trace + score

See references/architecture.md for the full 5-layer diagram.

Multi-Rate Hierarchy

See references/multi-rate-hierarchy.md.

LLM Roles in the Control Stack

See references/architecture.md for the full role table.

Reference Guide

• [architecture.md](references/architecture.md) — 5-layer stack, realized crate graph, control-flow diagram, component mapping
• [integration-map.md](references/integration-map.md) — Adapter crate boundary map, configuration, direction rule
• [plant-interface.md](references/plant-interface.md) — Plant/Estimator/Controller/Shield/Evaluator API specs
• [safety-shields.md](references/safety-shields.md) — CBF-QP, policy gates, containment, failure modes
• [multi-rate-hierarchy.md](references/multi-rate-hierarchy.md) — Loop rates, LLM placement, heuristics
• [world-models.md](references/world-models.md) — Koopman, DeePC, digital twins, learned dynamics
• [egri-for-controllers.md](references/egri-for-controllers.md) — Autoany applied to controller optimization
• [orchestration-patterns.md](references/orchestration-patterns.md) — Symphony daemon patterns for multi-agent dispatch
• [consciousness-stack.md](references/consciousness-stack.md) — Memory/knowledge/episodic integration
• [failure-modes.md](references/failure-modes.md) — Mitigations catalog for LLM-in-the-loop control
• [deep-research-report.md](references/deep-research-report.md) — Original research report and project plan: formal control theory, literature survey, prototype roadmap

Schemas

JSON Schemas in schemas/ enforce typed interfaces:

• state.schema.json — Plant/belief state
• action.schema.json — Control directives (θ_t)
• trace.schema.json — Ledger entries (autoany-compatible)
• evaluator.schema.json — Score vectors, promotion decisions
• egri-event.schema.json — EGRI trial events for Lago persistence via EventKind::Custom

Existing Skill Dependencies

This skill synthesizes and references (does not duplicate) these existing skills:

• control-metalayer-loop — Use for .control/ bootstrapping and governance primitives
• autoany — EGRI loop execution via autoany-aios (Arcan sessions) and autoany-lago (Lago ledger)
• symphony — Orchestration dispatch via symphony-arcan (Arcan HTTP runtime)
• life — arcan (agent sessions), lago (event journal), autonomic (homeostasis), spaces (networking)
• aios-protocol — Canonical types shared across all adapter crates
• agent-consciousness — Use for consciousness stack setup
• knowledge-graph-memory — Use for conversation bridge to Obsidian
• gstack — Use for QA actuation via headless browser

Agentic Control Kernel

A unifying control-systems metalayer for LLM-as-controller agent development.

Core law: Do not grant an agent more mutation freedom than your evaluator can reliably judge.

What Is This?

A purely knowledge-based skill that bootstraps any repository with the full control-systems worldview for autonomous agent development. When installed, it provides:

• Typed JSON schemas for plant state, control directives, trace ledger, and evaluator outputs
• Safety shield conventions (CBF-QP, policy gates, containment invariants)
• Multi-rate loop hierarchy defining where LLMs should and shouldn't operate
• Plant interface API specs for physical, cyber-physical, and cyber systems
• EGRI problem-spec templates for evaluator-governed controller improvement
• Consciousness stack integration for persistent cross-session agent memory

Architecture

The LLM emits typed control directives (θ_t) — not raw actuations (u_t). Deterministic controller modules execute, safety shields filter, and the runtime logs traces to an append-only ledger.

Plant → observe() → Runtime → estimator → belief state
  → LLM: decision → θ_t (typed directive)
  → Controller: propose → proposed u_t
  → Safety Shield: filter → safe u_t + certificate
  → Plant: apply → result
  → Ledger: trace + score

Synthesized Subsystems

Quick Start

Bootstrap a project

python3 scripts/control_kernel_init.py <repo-path> [--profile governed]

Installs into target repo:

• .control/policy.yaml — setpoints, gates, profiles
• .control/plant.yaml — typed state/action definitions
• schemas/ — JSON schemas for state, action, trace, evaluator
• METALAYER.md — control loop definition
• problem-spec.control.yaml — EGRI template for controller optimization

Install as a skill

# The packaged .skill file can be installed into any Claude Code environment
# See SKILL.md for full trigger conditions and usage

Documentation

Schemas

Design Decisions

• Skill = knowledge (stateless templates that shape reasoning), Runtime = execution (symphony daemon, gstack browser, MPC solvers)
• LLMs output controller parameters and plans, not raw actuations — except in slow cyber plants
• Safety is two-layered: policy gates (semantic) + CBF-QP shields (dynamic) — neither alone suffices
• All improvement is evaluator-governed (EGRI): freeze harness, mutate surface, evaluate, promote/rollback

License

Apache 2.0

Architecture

The agentic control kernel organizes agent-controlled systems into five layers, each with clear responsibilities, typed interfaces, and explicit safety boundaries.

Realized Crate Dependency Graph

aios-protocol (canonical types — shared vocabulary)
      |
      +-- Life Runtime (Arcan :3000, Lago :3001, Autonomic :3002, Praxis, Spaces)
      |         |
      |   +-----+------------------------------+
      |   |                                     |
      |   v                                     v
      |  autoany-aios (adapter)           symphony-arcan (adapter)
      |   |                                     |
      |   v                                     v
      |  autoany_core                      symphony-orchestrator
      |  (EGRI microkernel)               (dispatch + lifecycle)
      |
      +-- Agentic Control Kernel (skill: schemas + docs reflecting the realized stack)

See integration-map.md for the full adapter crate table.

The Five-Layer Stack

Cross-cutting: Consciousness stack (auto-memory + conversation bridge + knowledge graph) provides episodic and declarative memory across sessions.

autoany_core Modules

Formal Control Law

Let the plant be a partially observed stochastic dynamical system:

x_{t+1} = f(x_t, u_t, w_t)     # state transition
y_t = h(x_t) + v_t              # observation

The agentic controller operates on a typed belief state:

b_t = Filter(b_{t-1}, y_t, a_{t-1}, r_{t-1})

The LLM emits a structured control directive θ_t:

θ_t = π_LLM(b_t; φ)

Examples of θ_t:

• MPC weights, horizon, constraints, reference trajectories
• CBF barrier parameters, class-K function tuning
• Model update requests (Koopman lift changes, retraining triggers)
• Controller module selection (switching logic)

A deterministic controller module K produces candidate controls:

ũ_{t:t+H-1} = K(b_t, θ_t)

A safety shield S projects into the safe set:

u_t = S(ũ_t, b_t) = argmin_u ||u - ũ_t||² s.t. SafetyConstraints(b_t, u)

The runtime logs trace entry ℓ_t to ledger L and repeats.

Control-Flow Sequence (Single Tick)

Plant ──observe()──▶ Runtime ──update estimator──▶ b_t
                        │
                        ▼
              LLM Agent: decision(b_t)              [via Arcan session]
                        │
                        ▼ θ_t (typed directive)
              Controller: propose(b_t, θ_t)
                        │
                        ▼ proposed u_t
              Safety Shield: filter(u_t, b_t)       [Autonomic advisory gate]
                        │
                        ▼ safe u_t + certificate
              Plant: apply(safe u_t)
                        │
                        ▼ result + y_{t+1}
              Evaluator/Ledger: append trace         [Lago EventKind::Custom]

Runtime options:

• runtime.kind: subprocess — spawn agent as local subprocess (default, legacy)
• runtime.kind: arcan — dispatch via Arcan HTTP sessions (realized stack)

LLM Roles in the Control Stack

Key rule: In most physical/fast systems, the LLM outputs controller parameters and plans, not raw u_t. Only in slow cyber plants (cloud ops, workflows) can the LLM act closer to the control law — and still requires harness + verifiers + rollback.

Method → Component Mapping

Consciousness Stack

Persistent cross-session context for autonomous agents. Synthesizes three substrates into a self-evolving memory architecture.

The Problem

Each agent session starts blank. Yet the codebase carries sedimented decisions from hundreds of prior sessions. Without cross-session memory:

• Agents repeat solved problems
• Agents contradict prior decisions
• Agents lose momentum on multi-session work
• Agents violate invisible constraints

Solution: Structured Forgetting with Selective Recall

Everything is captured and indexed, but recall is on-demand — not overwhelming the context window.

The Three Substrates

1. Control Metalayer (Behavioral Governance)

Source skill: control-metalayer-loop

What it provides:

• Setpoints with explicit metrics and thresholds
• Policy gates (hard/soft) that block or warn
• Profiles (baseline → governed → autonomous)
• .control/ directory: machine-readable policy, commands, topology, state

Control primitive → Memory function:

• Setpoints = "what good looks like" (persistent goals)
• Gates = "what must never happen" (crystallized lessons)
• State.json = "where we are now" (live snapshot)

2. Knowledge Graph (Declarative Memory)

Source skill: knowledge-graph-memory (Obsidian bridge)

What it provides:

• Per-session conversation docs with full reasoning chains
• Map of Content (MOC) for navigation
• YAML frontmatter taxonomy (tags, related, type, status)
• Wikilinks for cross-referencing across sessions

Knowledge graph → Memory function:

• Session docs = episodic memory (what happened when)
• MOC = semantic index (find relevant sessions)
• Wikilinks = associative memory (connect related decisions)
• Tags = categorical memory (group by topic/branch)

3. Conversation Logs (Episodic Memory)

Source skill: knowledge-graph-memory (conversation_history.py)

What it provides:

• Dual-source parsing (Entire event logs + Claude Code transcripts)
• Noise filtering (system messages, tool IDs, internal paths)
• Obsidian callout formatting (user quotes, assistant info, tool examples)
• Incremental generation (skip existing, merge into MOC)

The Consciousness Stack (Ephemeral → Permanent)

How Lessons Graduate

Agent encounters failure mode → fix applied
  (working memory)
    │
    ▼
User corrects agent behavior → feedback memory saved
  (auto-memory)
    │
    ▼
Session captured with full reasoning chain
  (conversation log)
    │
    ▼
Pattern recurs across multiple sessions → documented in architecture
  (knowledge graph)
    │
    ▼
Pattern is enforceable → added as gate
  (.control/policy.yaml)
    │
    ▼
Pattern is foundational → added to invariants
  (CLAUDE.md)

Agent Session Protocol

On Session Start

1. Read CLAUDE.md (invariants), AGENTS.md (tools), METALAYER.md (control loop) 2. Check PLANS.md (active plan to continue?) 3. Check .control/state.json (current metrics) 4. Scan docs/conversations/Conversations.md for prior sessions on current branch 5. git status + git log for recent changes

Before Making Changes

• Search conversation history: grep -rl "keyword" docs/conversations/
• Traverse knowledge graph via MOC and wikilinks
• Check if prior sessions already addressed the problem

On Task Completion

1. Run make smoke (validate gates pass) 2. Update docs per doc-update policy 3. Pre-push hook auto-regenerates conversation history

Integration with Control Kernel

The consciousness stack is the memory substrate for the control kernel:

• Belief state (b_t) includes not just plant observations but prior session context
• Control directives (θ_t) are informed by historical traces and graduated lessons
• Evaluator can reference historical performance from the ledger
• Policy gates are the crystallized form of cross-session learning

Consciousness Stack ──context──▶ LLM Agent ──θ_t──▶ Control Kernel ──u_t──▶ Plant
       ▲                                                    │
       └────────────────trace + lessons────────────────────┘

Unifying an Agentic Control Metalayer for LLM-as-Controller Systems

Executive summary

A practical way to let an LLM-based agent “function as a control law” is to treat the LLM as a slow, supervisory, tool-using controller that emits typed, auditable control decisions (setpoints, constraints, model updates, solver configs, plans), while fast inner loops (PID/state feedback/MPC/CBF-QP) execute deterministically. This matches the operational realities in modern agent runtimes: agents succeed when the environment is made legible and verifiable through harnesses, contracts, and feedback loops, not when raw autonomy is maximized. citeturn11view0turn16view0turn18view0turn23view0

The four BroomVA projects already form a coherent “control stack” for agentic systems:

• control-metalayer provides the governance layer (setpoints, gates, sensors, actuators, profiles like “baseline/governed/autonomous,” and an audit loop) meant to stabilize behavior across agent sessions. citeturn10view2turn18view0turn10view0
• harness-engineering provides the execution harness layer (deterministic smoke/test/lint/typecheck commands, compact docs, observability templates, entropy management) operationalizing the Harness Engineering doctrine. citeturn11view0turn16view0turn37search1
• autoany provides the closed-loop improvement kernel (Evaluator-Governed Recursive Improvement, EGRI): freeze a harness, mutate a surface, evaluate, promote/rollback, log a ledger—explicitly a bounded closed-loop optimizer over artifacts. citeturn12view1turn20view0turn12view0
• symphony provides the orchestration daemon pattern (poll → dispatch → per-issue workspace worker → reconcile), with explicit safety invariants (workspace root containment, cwd checks) and an operational status surface; BroomVA’s Rust implementation also formalizes a machine-readable .control/ directory with policies, commands, topology, and live state. citeturn14view8turn23view0turn24view0turn14view0turn8view0

The unifying metalayer repository you asked for should therefore focus on one new missing piece: a control-systems “plant interface + safety shield + model-learning + MPC/DeePC/Koopman adapters” module that can be installed like a skill and that plugs into the existing BroomVA governance/harness/orchestration primitives.

Key design rule (from Autoany) to carry into control: Do not grant an agent more mutation freedom than your evaluator can reliably judge. In control terms: do not let the LLM’s action space exceed what your runtime monitors, safety filters, and evaluators can certify. citeturn12view0turn20view0turn12view1

Assumptions (explicit): no fixed platform or cloud; the “plant” can be physical (robot), cyber-physical (process), or purely cyber (cloud ops/workflows). Latency, compute, and safety criticality vary by plant, so recommended loop rates and autonomy levels are presented as engineering heuristics to be validated in your harness.

How the BroomVA repos resonate with control-system architecture

control-metalayer as “controller governance” and safety envelope

control-metalayer frames agent work as a control system: setpoints, sensors, gates, feedback loops, and escalation budgets, with a self-evolution process where recurring failures crystallize into enforceable gates in .control/policy.yaml. citeturn10view2turn18view0turn10view0

This is directly analogous to safety-critical control practice:

• “Setpoints” ≈ mission objectives / constraints to maintain.
• “Sensors” ≈ telemetry/metrics/CI checks that measure constraint satisfaction.
• “Gates” ≈ certified preconditions (hard constraints) before applying actions.
• “Profiles” ≈ controller modes (manual review vs governed vs autonomous), comparable to switching control policies under supervision. citeturn18view0turn14view2

harness-engineering as the “measurement and repeatability substrate”

The Harness Engineering playbook emphasizes that agent performance depends on deterministic command surfaces, compact actionable constraints, strict boundaries, early observability, and entropy management, installed via a wizard and templates (AGENTS.md, PLANS.md, harness scripts, CI workflows). citeturn11view0turn16view0

In control language, harness engineering builds:

• a reliable measurement function (repeatable tests/metrics),
• an experiment protocol (reproducible runs),
• and a plant sandbox for safe trials—critical for data-driven control and safe learning. citeturn11view0turn31view2

autoany (EGRI) as “outer-loop adaptive control / controller synthesis”

Autoany explicitly defines EGRI as a bounded closed-loop optimizer over executable artifacts and gives a formal tuple Π = (X, M, H, E, J, C, B, P, L). citeturn12view0turn12view1 Its skill definition operationalizes evaluator-first design, immutable harness construction, mutation-surface minimization, budget enforcement, rollback, and an append-only ledger. citeturn20view0

This maps cleanly to modern control development workflows:

• Artifact: controller parameters, cost weights, model structure, safety thresholds, policy code.
• Harness: simulator/digital twin + scenario library + regression suite.
• Evaluator: cost + constraint violations + robustness + latency.
• Promotion: deploy controller version if it improves metrics and passes constraints.

This is precisely how you “approximate to world models and arbitrary system control”: treat world-model learning and controller tuning as EGRI loops governed by trustworthy evaluators, rather than a single monolithic end-to-end learned policy.

symphony as “multi-agent orchestration and workspace safety invariants”

The OpenAI Symphony spec defines a long-running service that polls an issue tracker, creates isolated workspaces, runs coding agents, and exposes observability—all without requiring a persistent database, emphasizing deterministic workspaces and explicit safety invariants. citeturn23view0turn24view1turn24view0

Most relevant to control/agentic “plant safety”:

• Safety invariants require the agent to run only inside the per-issue workspace, verify cwd == workspace_path, ensure workspace path stays within the workspace root, and sanitize workspace keys. citeturn24view0turn24view1
• The spec is explicit that approval/sandbox posture is implementation-defined but must not stall indefinitely; it must be resolved or fail closed. citeturn24view6turn26view3
• The runtime contract uses JSON-RPC-like protocol messages over stdio (and optionally WebSockets), and WebSocket mode uses bounded queues with overload errors requiring retry with exponential delay. citeturn26view4turn26view0

BroomVA’s Rust symphony adds a machine-readable control metalayer: .control/policy.yaml, commands.yaml, topology.yaml, state.json, plus validation scripts and explicit “per-session” and “per-change” inner loops. citeturn14view0turn14view2turn8view0turn6view0 That is effectively a ready-made blueprint for how your unifying repository should expose control primitives and audits.

Formalizing “agent as control law” and defining LLM roles

A formal agentic control law with tool-mediated actions

Let the plant (arbitrary system) be a partially observed stochastic dynamical system:

• State: \(x_t \in \mathbb{R}^n\)
• Control input: \(u_t \in \mathbb{R}^m\)
• Disturbance: \(w_t\)
• Observation: \(y_t\)

\[ x_{t+1}=f(x_t,u_t,w_t), \quad y_t=h(x_t)+v_t \]

Define an agentic controller as a tool-using policy operating on a typed belief state \(b_t\) derived from observations and logs:

\[ b_t = \mathrm{Filter}(b_{t-1}, y_t, a_{t-1}, r_{t-1}) \]

where \(a_{t}\) is a high-level action (a tool call / plan / parameter update), and \(r_t\) are runtime feedback signals (success/failure, metrics).

The LLM-generated decision is not the raw \(u_t\) (except in slow plants). Instead, the LLM emits a structured control directive \(\theta_t\) that parameterizes deterministic control modules:

\[ \theta_t = \pi_{\text{LLM}}(b_t; \phi) \]

Examples of \(\theta_t\):

• MPC weights, horizon, constraints, reference trajectories
• CBF barrier parameters, class-\(\mathcal{K}\) function tuning
• model update requests (Koopman lift changes, learned dynamics retraining triggers)
• selection among controllers (switching logic)

A deterministic controller module \(K\) produces a candidate control sequence:

\[ \tilde{u}_{t:t+H-1} = K(b_t,\theta_t) \]

A safety filter / shield \(S\) then projects candidate inputs into the safe set (e.g., via CBF-QP):

\[ u_t = S(\tilde{u}_t, b_t) = \arg\min_{u} \|u-\tilde{u}_t\|^2 \;\text{s.t.}\; \text{SafetyConstraints}(b_t,u) \]

CBF-QP as a canonical shield is standard: encode safety as barrier constraints and solve a QP each step. citeturn29search11turn29search7turn30search9

Finally, the runtime logs a trace entry \( \ell_t \) into a ledger \(L\) (Autoany-style) and repeats. citeturn20view0turn12view1

This architecture intentionally enforces the Autoany “core law” at runtime: the LLM’s degrees of freedom are limited to \(\theta_t\) and tool calls that can be reliably evaluated and constrained. citeturn12view0turn20view0

LLM roles in feedback control systems

The LLM can play multiple roles; the critical choice is where in the hierarchy it sits.

Two important takeaways:

1. In most physical/fast systems, the LLM should not output raw \(u_t\) at servo rates; it should output controller parameters and plans that deterministic modules execute. This is consistent with the need for strict safety invariants and non-stalling approval policies in real agent runtimes. citeturn24view0turn24view6turn26view4 2. In slower cyber “plants” (cloud ops, workflow routing), an LLM can act closer to the control law, because actuation is inherently discrete, typed, and slower—but still requires harnesses, verifiers, and rollback. citeturn12view0turn11view0

Harness primitives and APIs needed to make “LLM control laws” real

The unifying metalayer should standardize runtime primitives that correspond to control concepts and to the tool-driven agent ecosystems (skills, function calling, structured outputs).

Typed state, action schemas, and transition feedback

Minimum set of primitives:

• State schema (typed “plant state” or belief state):
• must separate: measured signals, estimated signals, and semantic/context fields.
• Action schema (typed “actuation”):
• discrete actions (API calls), continuous control vectors, or parameter updates.
• Transition feedback:
• tool call results, plant observations, constraint checks, solver status, timeouts.

These should be enforced using structured outputs (JSON Schema) and strict tool schemas so agent outputs are machine-checkable. citeturn31view0turn32view0turn32view4

Verifiers, safety filters, and audit gates

You need two distinct “safety” layers:

• Pre-action safety: “is this action allowed?” (policy gate, approval policy, sandbox rules). Symphony explicitly requires implementations to define approval and sandbox posture and to avoid indefinite stalls. citeturn24view6turn26view3turn23view0
• Control-theoretic safety: ensure \(x_t\) remains in a safe set \( \mathcal{S}\), e.g., via CBF-QP shields that minimally modify a nominal controller. citeturn29search11turn29search7turn30search9

BroomVA symphony’s .control/policy.yaml structure makes this explicit in a software setting: setpoints have IDs, measurements, and severities (blocking vs informational), and the system uses gates like smoke and control_audit. citeturn6view0turn8view0

Ledger/trace schema and evaluator interface

To integrate with Autoany (EGRI), your metalayer repository should ship a canonical trace format:

• trace_id, timestamp, plant_id, controller_version
• state snapshot (or hash + artifact pointer)
• action proposed vs action applied (after safety filter)
• constraints checked + results
• evaluator metrics (cost, violations, latency, robustness indicators)
• rollback/promotion decisions

Autoany’s skill explicitly requires an append-only ledger, rollback, budgets, and a separation between evaluator and mutable artifact. citeturn20view0 BroomVA symphony’s .control/state.json is an example of “live metric snapshot” and gate status, updated by scripts. citeturn14view0turn8view0

Why “skills” packaging matters for the repo design

Your goal (“installable metalayer as a SKILL”) aligns with the broader agent-skills ecosystem:

• The skills CLI (npx skills add …) installs SKILL.md-defined bundles to multiple agents and supports project vs global installs. citeturn35view0turn35view2
• OpenAI’s “skills” docs also describe uploading and mounting skills into hosted shell environments, reinforcing that skills are a first-class distribution artifact. citeturn35view3

So the unifying repository should be “skills-first”: the control metalayer should be installable into arbitrary repos via the skills tool, and it should generate the typed schemas, harness scripts, and control adapters as templates—exactly how BroomVA’s control-metalayer-loop and harness-engineering-playbook are already structured. citeturn18view0turn16view0turn35view0

Mapping modern control methods to agent architecture components

This section “plugs in” the control techniques you listed into the BroomVA-style agent harness stack.

Data-driven MPC and DeePC

DeePC uses input/output trajectory data (Hankel matrices; behavioral “fundamental lemma” lineage) for prediction and optimization without an explicit parametric model. citeturn27search0turn36search3 Regularized / distributionally robust DeePC formulations interpret regularization as a distributionally robust optimization (DRO) principle and provide probabilistic robustness guarantees. citeturn27search8turn27search4

Agent mapping:

• Harness primitive: dataset store + experiment runner (collect trajectories).
• Control module: DeePC optimizer (QP/convex program) treated as a tool.
• LLM role: choose excitation experiments, select horizons/regularization, interpret results, update constraints.
• Safety: wrap DeePC output with CBF-QP shield or robust constraint tightening.

Control Barrier Functions as runtime safety shields

CBFs are a control-theoretic method to enforce safety constraints by solving a QP that minimally modifies a nominal action while ensuring forward invariance of a safe set. citeturn29search11turn29search7turn30search9 They are widely integrated with MPC and learning for safety-critical systems (including safe exploration frameworks). citeturn30search9turn30search1turn36search5

Agent mapping:

• CBF module lives in the runtime as a hard safety filter.
• LLM is not trusted to “be safe”; it can tune margins, select constraints, or propose candidate actions—then the CBF shield enforces invariants.
• Verification: CBF-QP feasibility becomes a gate; if infeasible, fall back to safe controller and raise an incident in the ledger.

Koopman methods as learned linear predictors for MPC

Koopman-based control lifts nonlinear dynamics into higher-dimensional observable space where linear predictors enable efficient MPC, but approximation errors require explicit error bounds and stability analysis. citeturn33view1turn29search2turn27search10 Recent survey work explicitly frames Koopman control around error bounds and closed-loop guarantees. citeturn33view1turn29search4

Agent mapping:

• World-model module: Koopman lift learning (EDMD variants) as an updatable artifact.
• Control module: Koopman-MPC using the lifted linear system.
• LLM role: decide when to relearn lifts, curate datasets, interpret model mismatch indicators, pick robust strategies (tightening/terminal sets).

MPC–RL hybrids and safe learning

Hybrid MPC–RL systems often use RL to tune MPC parameters online or to augment MPC with learned components, while preserving constraint-handling benefits of MPC. citeturn30search0turn30search1 Safe model-based RL frameworks explicitly combine MPC with CBF constraints and learn parameters (e.g., class-\(\mathcal{K}\) functions) while enforcing safety. citeturn30search1turn36search5 Safe RL surveys emphasize constraint formulations and methods for safety-critical learning. citeturn28search13turn28search17turn28search9

Agent mapping:

• RL policy is treated as a proposal generator or parameter tuner (slow loop), not the final actuator.
• MPC remains the execution policy with constraints; CBF remains the hard shield.
• Autoany/EGRI runs offline/async to improve policies with strong evaluators.

Differentiable control and differentiable MPC

Differentiable MPC provides a pathway to embed MPC in end-to-end learning pipelines (RL/imitation) by differentiating through the MPC solution. citeturn27search3turn27search19

Agent mapping:

• Differentiable control is primarily a learning pipeline primitive (for model/parameter learning), not a runtime LLM primitive.
• LLM role: generate model structures, loss definitions, training harness scripts; interpret gradients and training failures; gate deployments via harness tests.

Distributionally robust control and distributionally robust MPC

DRO-inspired control methods (including distributionally robust MPC) treat uncertainty as ambiguity sets around empirical distributions (e.g., Wasserstein balls) and optimize worst-case expectations. citeturn28search0turn27search8

Agent mapping:

• Runtime: robust MPC module that consumes uncertainty sets and scenario batches.
• Harness: scenario generator and stress testing (“red team” for dynamics).
• LLM: curates scenario sets, chooses robustness radii and tradeoffs, but promotion requires evaluator-based validation.

Learned dynamics and digital twins as “world models”

Model-based RL is explicitly about learning environment models to plan/control with fewer real-world trials. citeturn28search11turn28search15 Digital twin reviews emphasize real-time virtual replicas supporting monitoring, simulation, prediction, and optimization, often by integrating multi-source data flows. citeturn28search2turn28search10turn28search18

Agent mapping:

• Digital twin provides the harness for safe experimentation and scenario evaluation.
• Learned dynamics (neural ODEs, Koopman, GP, etc.) are artifacts improved via EGRI loops.
• The LLM is most valuable for semantic integration: mapping business/mission goals to evaluators and constraints; selecting what to simulate.

A concise “method → component” mapping

Multi-rate hierarchy, safety guarantees, and failure modes

Multi-rate design: which loops LLMs should and shouldn’t control

Symphony’s spec and the Codex app-server protocol reflect a reality: agent runtimes are message-driven, tool-mediated, and subject to timeouts, load, and approval workflows—excellent for supervisory control, not for hard real-time servo loops. citeturn24view0turn26view4turn26view1turn24view6

A practical multi-loop architecture:

• Inner loop (hard real-time): deterministic controllers (PID/state feedback/MPC at fixed dt), CBF-QP shield; no LLM in the loop.
• Mid loop (soft real-time): MPC planning updates, state estimator resets, model updates triggered by drift monitors.
• Outer loop (supervisory): LLM sets goals/constraints, selects control modules, approves escalations, writes new control artifacts.
• Meta loop (EGRI): Autoany-style recursive improvement of models/controllers in a harnessed environment.

Heuristic loop-rate suitability (illustrative, validate per plant):

Safety and verification mechanisms with runtime guarantees

A robust agentic control system should combine:

• Workspace / actuation containment: enforced execution boundaries akin to Symphony’s workspace invariants (cwd checks, root containment, sanitization). citeturn24view0turn6view0
• Formal safety shields: CBF-QP constraints (and combinations with MPC) to guarantee invariance of safe sets during runtime. citeturn29search11turn30search1
• Distributional robustness: DRO-based MPC/DeePC formulations and scenario stress tests to reduce sensitivity to model/data shifts. citeturn27search8turn28search0
• Mechanical audits and gates: setpoint catalogs with explicit measurements and severity; CI gates as “sensors.” BroomVA symphony’s control documents list sensors and actuator maps for audits. citeturn14view5turn14view0turn8view0
• Operational safety practices: red-teaming, human oversight in high-stakes domains, and constrained inputs/outputs. citeturn31view2turn11view0

Failure modes and mitigations

Common failure modes when LLMs participate in control:

• Spec/constraint hallucination: LLM invents constraints, misreads units, or forgets invariants.

Mitigation: JSON-schema structured outputs + strict tool schemas + policy gates + “allowed_tools” restriction. citeturn31view0turn32view2turn32view0

• Unsafe exploration / probing: LLM runs aggressive identification experiments.

Mitigation: EGRI budgets + hard constraints + CBF shield; enforce “evaluator-first” and sandbox modes. citeturn20view0turn12view3turn30search9

• Latency spikes / overload: tool runtimes reject/queue requests (bounded queues; server overloaded).

Mitigation: multi-rate design; fallback controllers; exponential backoff; don’t place LLM in fast loops. citeturn26view4turn24view5turn26view0

• Evaluator gaming / overfitting (outer-loop learning): the agent learns to exploit metric loopholes.

Mitigation: holdout scenario sets, adversarial tests, immutable evaluator artifacts, and “never mutate evaluator and artifact in the same trial.” citeturn20view0turn31view2

• Tool-call side effects without approvals: executing destructive actions.

Mitigation: explicit approval policies (Codex app-server) and fail-closed policies (Symphony). citeturn26view3turn24view6turn24view0

Blueprint for a unifying metalayer repository and a prototype roadmap

Blueprint architecture

The architecture should treat BroomVA’s skills and Symphony-style orchestration as the “operating system,” and add a control-and-world-model kernel that can be installed anywhere.

flowchart TB
  subgraph Governance["Governance layer (control-metalayer)"]
    SP["Setpoints & policies (.control/policy.yaml)"]
    CMD["Command catalog (.control/commands.yaml)"]
    AUD["Audit gates (smoke/control-audit)"]
    LEDGER["Run ledger / trace store"]
  end

  subgraph Harness["Harness layer (harness-engineering)"]
    H1["Deterministic harness scripts (smoke/test/lint/typecheck)"]
    OBS["Observability contracts + metrics"]
    ENT["Entropy checks / nightly audits"]
  end

  subgraph Orchestration["Orchestration layer (symphony pattern)"]
    ORCH["Daemon orchestrator (poll/dispatch/reconcile)"]
    WS["Isolated workspace manager + invariants"]
    API["Status surface (/api/v1/state, refresh)"]
  end

  subgraph ControlKernel["Control + world-model kernel (new)"]
    PI["Plant interface (typed state/action)"]
    EST["Observer / state estimator"]
    WM["World models: Koopman / learned dynamics / twin"]
    MPC["MPC / DeePC planners"]
    SHIELD["Safety shield: CBF-QP / constraint filters"]
    DRO["Robust / DRO scenario engine"]
  end

  subgraph AutoImprove["Auto-improvement layer (autoany/EGRI)"]
    SPEC["problem-spec compiler"]
    EVAL["Evaluator + constraints"]
    PROMOTE["Promotion/rollback policy"]
  end

  PI --> EST --> MPC --> SHIELD --> PI
  WM --> MPC
  DRO --> MPC
  SP --> MPC
  SP --> SHIELD
  H1 --> AUD
  OBS --> LEDGER
  ORCH --> PI
  WS --> PI
  API --> ORCH
  SPEC --> EVAL --> PROMOTE --> SP
  LEDGER --> SPEC

This diagram is grounded in: (a) control-metalayer’s policy/gate approach citeturn18view0turn10view2, (b) harness-engineering’s deterministic harness doctrine citeturn11view0turn16view0, (c) Symphony’s orchestrator/workspace safety invariants and status API citeturn23view0turn24view0turn24view4, and (d) Autoany’s evaluator-governed loop model citeturn12view1turn20view0.

Concrete repo layout

A “unifying metalayer” repo should be both:

1) a skills repo (installable via npx skills add …), and 2) a library repo (re-usable Python/Rust modules for runtime control).

Proposed layout:

• .skills/
• control-metalayer-loop/ (vendor or submodule; keep upstream-compatible) citeturn18view0
• harness-engineering-playbook/ (vendor or submodule) citeturn16view0
• autoany/ skill (vendor or submodule) citeturn20view0
• symphony-adapter/ (new skill)
• templates for WORKFLOW.md and an orchestration daemon config consistent with Symphony spec concepts citeturn23view0turn24view1
• control-kernel-bootstrap/ (new flagship skill)
• installs typed plant/action schemas, safety shields, and evaluation harness templates

• schemas/
• state.schema.json
• action.schema.json
• trace.schema.json
• evaluator.schema.json

(use strict JSON schema design consistent with structured outputs + tool calling patterns) citeturn31view0turn32view4

• runtime/
• daemon/ (Symphony-like scheduler; can be Rust or Python; must expose state surface consistent with /api/v1/* spec ideas) citeturn24view4turn14view8
• policy/ (load .control/policy.yaml, enforce profiles) citeturn14view2turn18view0
• tooling/ (function-call tool wrappers; allowed-tools sets) citeturn32view2turn31view1

• control/
• mpc/ (wrappers over NMPC tooling; deterministic solvers) citeturn38search1turn38search0
• deepc/ (DeePC and robust DeePC) citeturn27search0turn27search8
• koopman/ (Koopman learning + Koopman-MPC) citeturn33view1turn29search2
• shield/ (CBF-QP safety filter) citeturn29search11turn29search7
• robust/ (DRO/scenario MPC helpers) citeturn28search0turn27search8

• world_models/
• digital_twin/ (interfaces + adapters for simulators; calibration hooks) citeturn28search2turn28search10
• learned_dynamics/ (model learning harnesses; versioned artifacts) citeturn28search11turn28search15

• evals/
• scenario libraries, regression baselines, stress tests, and acceptance thresholds (Autoany-compatible evaluators) citeturn20view0turn12view0

• .control/ (generated into target repos by skills)
• policy.yaml, commands.yaml, topology.yaml, state.json (mirroring BroomVA symphony’s metalayer pattern) citeturn14view0turn8view0

API spec highlights for the control kernel

At minimum, standardize these interfaces (language-agnostic; implementable in Python/Rust):

• Plant:
• observe() -> Observation
• apply(action: Action) -> ActuationResult
• reset(seed?)
• constraints() -> ConstraintSet

• Estimator:
• update(obs) -> belief_state
• optional predict(belief_state, action_seq)

• Controller:
• propose(belief_state, setpoint, constraints, world_model) -> ProposedActionSeq + metadata

• SafetyShield (CBF-QP / rule-based):
• filter(proposed_action, belief_state) -> safe_action + certificate

• Evaluator (Autoany-compatible):
• score(trace_batch) -> ScoreVector
• promotion_decision(score, constraints_ok) -> promote/rollback/branch citeturn20view0turn12view1

• TraceSink:
• append(trace_event)
• query(filters)

Critically, the LLM never directly calls Plant; it calls only Controller or MetaController tools with strict schemas, and the runtime is responsible for all plant interactions and safety enforcement. This operationalizes the “agent gets only as much freedom as we can judge” principle. citeturn12view0turn32view2turn24view6

Control-flow loop for a single tick

sequenceDiagram
  participant P as Plant
  participant R as Runtime
  participant L as LLM Agent
  participant C as Controller Module
  participant S as Safety Shield
  participant E as Evaluator/Ledger

  R->>P: observe()
  P-->>R: y_t
  R->>R: update estimator -> b_t
  R->>L: request decision (typed state summary)
  L-->>R: control_directive θ_t + tool choice
  R->>C: propose(b_t, θ_t)
  C-->>R: proposed u_t (or u_{t:t+H-1})
  R->>S: filter(proposed u_t, b_t)
  S-->>R: safe u_t + certificate
  R->>P: apply(safe u_t)
  P-->>R: result + y_{t+1}
  R->>E: append trace + score micro-metrics

The safety/shield and trace logging align with CBF-QP practice citeturn29search11turn30search9 and with Autoany’s harness/ledger doctrine citeturn20view0turn12view1.

Toolchains to prioritize for a prototype

Given your “no platform constraint” requirement, prioritize tooling that supports:

• fast MPC/NMPC and estimation: acados (fast embedded NMPC/MHE) citeturn38search1
• nonlinear optimal control + autodiff: CasADi citeturn38search0turn38search20
• convex QPs for CBF shields and MPC subproblems: OSQP citeturn38search2turn38search14
• convex modeling for rapid prototyping: CVXPY citeturn38search3turn38search7

For agent-side typing and robustness:

• OpenAI structured outputs (response_format: json_schema, strict mode) citeturn32view0
• OpenAI function calling with strict JSON schema tools and allowed-tools restriction citeturn32view2turn32view4
• Codex app-server protocol when controlling a coding agent or tool-executing agent via JSON-RPC. citeturn26view4turn26view1turn24view3

Case studies that naturally fit this metalayer

Robotics / embodied systems Use the “Code as Policies” pattern: LLM generates policy code that calls control primitives (waypoints, impedance, etc.) rather than streaming raw torques. citeturn30search3turn30search7 Then insert CBF-QP shields and MPC planning under the hood. citeturn29search11turn30search1

Cloud ops (autoscaling, incident response) Treat the cloud platform as the plant; actions are typed (scale up/down, restart service, change routing), and safety constraints are SLO/SLA budgets. Symphony-style orchestration plus harness engineering (observability legibility, deterministic scripts) is directly aligned with this domain. citeturn23view0turn11view0turn14view8

Business workflows (routing, approvals, compliance) Autoany’s EGRI explicitly lists “Workflow/Ops” as a domain mapping: mutate routing policies or decision graphs, evaluate on replay, promote with rollback. citeturn12view2turn20view0

Actionable prototyping roadmap with evaluation metrics

Milestone goals are phrased as “what to build + what to measure,” consistent with harness-first and evaluator-first doctrine. citeturn11view0turn20view0

Phase foundation: metalayer bootstrap

• Deliver a control-kernel-bootstrap skill that installs:
• .control/ scaffolding (policy/commands/topology/state)
• typed schemas (state, action, trace)
• harness scripts and CI gates
• Metrics:
• audit pass rate (smoke, control-audit)
• schema validation pass rate
• trace completeness rate (no missing fields)

Grounding: BroomVA control-metalayer wizard + symphony metalayer files. citeturn18view0turn14view0turn8view0

Phase safety: implement shields and containment

• Implement shield/cbf_qp module and a policy gate layer (approval/sandbox posture).
• Enforce invariants analogous to Symphony workspace invariants for any “plant adapter” (path containment, restricted execution context). citeturn24view0turn6view0
• Metrics:
• constraint violation rate (target 0 for hard constraints)
• shield feasibility rate and fallback frequency
• mean time to detect unsafe proposals

Phase modeling: world models and learned dynamics

• Add a minimal digital twin interface and at least one learned model path (Koopman or neural dynamics).
• Integrate drift detection and retraining triggers.
• Metrics:
• multi-step prediction error under scenario library
• closed-loop cost improvement vs baseline
• robustness under distribution shift scenarios

Grounding: Koopman control surveys + model-based RL surveys. citeturn33view1turn28search11turn28search2

Phase planning: MPC/DeePC integration

• Implement:
• MPC planner interface (CasADi/acados adapter)
• DeePC adapter (data store + optimizer)
• LLM role restricted to: setpoints, constraints, tuning knobs, module selection.
• Metrics:
• solve time distributions
• feasibility and recursive feasibility in test scenarios
• comparative performance vs model-free baseline

Grounding: DeePC papers and ML-based MPC review. citeturn27search0turn27search8turn33view0

Phase auto-improvement: EGRI over controllers

• Integrate Autoany-style problem-spec and ledger so controller tuning is an explicit recursive improvement loop.
• Metrics:
• promotion success rate (improvements that generalize to holdout scenarios)
• regression rate (promoted versions later rolled back)
• evaluator reliability (agreement between offline replay and online outcomes)

Grounding: Autoany formal model and safety rules. citeturn20view0turn12view1

Prioritized references

Primary/official sources most directly supporting the design:

• Harness engineering doctrine and agent-first workflow design (entity["company","OpenAI","ai lab"]). citeturn11view0
• Symphony service spec (workspace safety invariants, orchestration layers, /api/v1/*, approval policy requirements). citeturn23view0turn24view0turn24view4turn24view6
• Codex app-server protocol (JSON-RPC, thread/start, turn/start, approvals, bounded queues). citeturn26view4turn26view1turn26view0turn26view3
• BroomVA symphony metalayer (.control/ directory definition, profiles, gates, sensors/actuators, state snapshots). citeturn14view0turn14view2turn14view5turn8view0
• Autoany EGRI formalism and skill safety rules. citeturn12view1turn20view0turn12view0
• DeePC + robust DeePC. citeturn27search0turn27search8turn36search3
• CBF-QP foundations and CBF+learning integrations. citeturn29search11turn29search7turn30search9turn30search1
• Koopman control survey with closed-loop guarantees. citeturn33view1
• Digital twin reviews for world-model framing. citeturn28search2turn28search10turn28search18
• Differentiable MPC. citeturn27search3turn27search19
• Skills packaging ecosystem (skills CLI by entity["company","Vercel","cloud platform"]; skills docs). citeturn35view0turn35view3

Suggested next steps (prototype order):

1) Build the control-kernel-bootstrap skill that installs schemas + .control/ + audits into any repo. (You already have the scaffolding patterns in control-metalayer-loop and harness-engineering-playbook.) citeturn18view0turn16view0 2) Implement the SafetyShield first (CBF-QP + policy gates), then only allow the LLM to output \(\theta_t\) and tool selections. citeturn29search11turn12view0turn24view6 3) Add one world model path (Koopman or a small learned dynamics model) plus a scenario library; wire it into MPC. citeturn33view1turn33view0 4) Integrate Autoany’s EGRI loop so model/controller updates are evaluator-governed and rollback-capable. citeturn20view0turn12view1

EGRI for Controllers

Apply Autoany's Evaluator-Governed Recursive Improvement to controller tuning, world-model learning, and safety parameter optimization.

Core Mapping

Problem-Spec Template for Controller Optimization

Use assets/templates/problem-spec.control.yaml as starting point:

name: "controller-optimization"
objective:
  metric: "closed_loop_cost"
  direction: minimize
  baseline: null  # Filled after first eval

constraints:
  - "constraint_violation_count == 0"
  - "shield_intervention_rate <= 0.05"
  - "solve_time_ms <= 100"

artifacts:
  mutable:
    - path: "control/mpc/weights.yaml"
      type: config
      description: "MPC cost weights and horizon"
    - path: "control/shield/cbf_params.yaml"
      type: config
      description: "CBF barrier parameters and margins"
  immutable:
    - path: "evals/scenario_library/"
      reason: "Evaluator scenarios — must not change during trials"
    - path: "evals/run_eval.sh"
      reason: "Evaluator script"

evaluator:
  script: "evals/run_eval.sh"
  inputs: ["control/mpc/weights.yaml", "evals/scenario_library/"]
  outputs:
    closed_loop_cost: float
    constraint_violations: int
    shield_intervention_rate: float
    solve_time_p99_ms: float
  trusted: true
  baseline_score: null

execution:
  backend: simulator
  command: "python3 twin/run_scenarios.py --config {{artifact}}"
  timeout_s: 300
  sandbox: true

budget:
  max_trials: 30
  time_per_trial_s: 300

promotion:
  policy: keep_if_improves
  require_constraint_check: true

autonomy:
  mode: sandbox
  escalation_triggers:
    - "constraint_violation_detected"
    - "shield_intervention_rate > 0.10"
    - "budget_75_percent_exhausted"

Mutation Surfaces by Control Method

MPC Weight Tuning

• What mutates: Q, R matrices, prediction horizon N, constraint tightening
• Mutation operators: scale, perturb, restructure (diagonal → full)
• Evaluator: closed-loop cost + constraint satisfaction over scenario library

CBF Parameter Tuning

• What mutates: barrier function parameters, class-K function gains, margins
• Mutation operators: scale margins, adjust gains, swap barrier formulations
• Evaluator: safety margin utilization + nominal performance degradation

Koopman Lift Learning

• What mutates: observable functions, dictionary size, regularization
• Mutation operators: add/remove observables, adjust regularization, retrain
• Evaluator: multi-step prediction error + closed-loop stability indicators

DeePC Configuration

• What mutates: data window, regularization weights, horizon, constraint sets
• Mutation operators: adjust parameters, refresh data, modify constraints
• Evaluator: tracking error + robustness under distribution shift scenarios

Safety Rules for Controller EGRI

1. Never bypass the safety shield during trials — shield is part of the immutable harness 2. Scenario library must include adversarial cases — not just nominal operation 3. Constraint violations are hard failures — no "soft" constraint violations in promotion 4. Holdout scenarios for anti-gaming — evaluator uses scenarios not visible to the mutator 5. Shield intervention rate is a first-class metric — rising rate signals degrading controller 6. Rollback to last known-good — if promoted controller fails in deployment, immediate revert

Concrete Wiring: ArcanExecutor + LagoLedger

The realized stack executes EGRI loops via two adapter crates:

• `autoany-aios` (autoany/autoany-aios/) — ArcanExecutor implements the

autoany Executor trait by creating Arcan sessions. Each trial runs inside a capability-scoped session with policy constraints from the problem-spec.

• `autoany-lago` (autoany/autoany-lago/) — LagoLedger implements the

autoany Ledger trait by writing EventKind::Custom entries with "egri." prefix. Schema: schemas/egri-event.schema.json.

Wiring an EGRI loop

use autoany_core::EgriLoop;
use autoany_aios::ArcanExecutor;
use autoany_lago::LagoLedger;

let executor = ArcanExecutor::new("http://localhost:3000")
    .with_policy(problem_spec.policy());

let ledger = LagoLedger::new("http://localhost:3001")
    .with_prefix("egri.");

let mut loop_ = EgriLoop::new(problem_spec, executor, ledger);
loop_.run().await?;

New autoany_core modules

Cross-reference with Lago

Every trial event stored via LagoLedger includes an optional session_id field that links back to the Arcan session. This enables post-hoc correlation between EGRI trial outcomes and the fine-grained agent event stream in Lago's journal.

Nesting: EGRI Over EGRI

Level 0: Optimize controller parameters (MPC weights, CBF margins) Level 1: Optimize the mutation strategy (which parameters to tune, search heuristics) Level 2: Optimize the evaluation (which scenarios matter most, budget allocation)

Start with Level 0. Only nest when Level 0 converges and you need more signal.

Failure Modes

Catalog of failure modes when LLMs participate in control systems, with mitigations grounded in the control kernel architecture.

Specification Failures

Spec/Constraint Hallucination

• Symptom: LLM invents constraints, misreads units, or forgets invariants
• Mitigation: JSON-schema structured outputs + strict tool schemas + policy gates
• Detection: Schema validation failures, constraint mismatch with plant.yaml
• Recovery: Reject directive, request re-generation with explicit constraint list

Goal Drift

• Symptom: LLM gradually shifts objectives away from original setpoints
• Mitigation: Setpoints are immutable within a session; changes require explicit approval
• Detection: Compare current directives against original setpoint catalog
• Recovery: Reset to baseline setpoints, log drift event

Exploration Failures

Unsafe Probing

• Symptom: LLM runs aggressive identification experiments that stress the plant
• Mitigation: EGRI budgets + hard constraints + CBF shield + sandbox mode
• Detection: Shield intervention rate spike, constraint violations during exploration
• Recovery: Halt experiment, revert to safe operating point

Evaluator Gaming

• Symptom: Agent exploits metric loopholes, score improves but quality degrades
• Mitigation: Holdout scenario sets, adversarial tests, immutable evaluator
• Detection: Performance on holdout diverges from training scenarios
• Recovery: Halt EGRI loop, expand evaluator, add adversarial scenarios

Runtime Failures

Latency Spikes

• Symptom: Tool runtimes reject/queue requests, bounded queues overflow
• Mitigation: Multi-rate design, fallback controllers, exponential backoff
• Detection: Response time exceeds turn_timeout, queue depth alerts
• Recovery: Activate fallback controller, wait for backoff, resume

Shield Infeasibility

• Symptom: CBF-QP has no feasible solution — no safe action exists
• Mitigation: Emergency fallback action (always feasible by design)
• Detection: Solver returns infeasible status
• Recovery: Execute fallback, halt normal operation, escalate immediately

Model Mismatch

• Symptom: World model predictions diverge from observations
• Mitigation: Drift detection monitors, robust/DRO formulations
• Detection: Prediction error exceeds threshold over sliding window
• Recovery: Widen uncertainty bounds, trigger model retraining, use conservative controller

Orchestration Failures

Worker Stall

• Symptom: Agent subprocess stops producing output
• Mitigation: Stall detection timeout, forced kill + retry
• Detection: No protocol message within stall_timeout_ms
• Recovery: Kill worker, schedule retry with backoff

Workspace Escape

• Symptom: Agent attempts to access files outside workspace root
• Mitigation: Path containment invariant (canonicalize + starts_with check)
• Detection: Path validation failure
• Recovery: Reject operation, log security event, terminate worker

Destructive Side Effects

• Symptom: Agent executes destructive actions without approval
• Mitigation: Approval gates, fail-closed policy, sandbox posture
• Detection: Action classification + policy gate check
• Recovery: Block action, require explicit human approval

Improvement Loop Failures

Budget Exhaustion Without Progress

• Symptom: EGRI loop consumes budget with no improvement
• Mitigation: Early stopping triggers, budget allocation monitoring
• Detection: Budget > 75% consumed with no promotion
• Recovery: Halt loop, analyze ledger, adjust mutation strategy or surface

Regression After Promotion

• Symptom: Promoted controller performs worse in deployment than in evaluation
• Mitigation: Rollback to last known-good, expand scenario library
• Detection: Online metrics degrade after deployment
• Recovery: Immediate rollback, add deployment scenario to evaluator

Evaluator Noise

• Symptom: Promoted states oscillate, no stable improvement
• Mitigation: Increase evaluation samples, use paired comparisons
• Detection: Promotion/rollback frequency exceeds threshold
• Recovery: Strengthen evaluator (more samples, statistical tests)

Severity Classification

Integration Map

Complete boundary map of the unified BroomVA Agent OS stack.

Crate Dependency Graph

aios-protocol (canonical types — shared vocabulary)
      |
      +-- Life Runtime (Arcan :3000, Lago :3001, Autonomic :3002, Praxis, Spaces)
      |         |
      |   +-----+------------------------------+
      |   |                                     |
      |   v                                     v
      |  autoany-aios (adapter)           symphony-arcan (adapter)
      |   |                                     |
      |   v                                     v
      |  autoany_core                      symphony-orchestrator
      |  (EGRI microkernel)               (dispatch + lifecycle)
      |
      +-- Agentic Control Kernel (skill: schemas + docs reflecting the realized stack)

Adapter Crates

Configuration

Symphony WORKFLOW.md

runtime:
  kind: arcan           # "subprocess" (default) | "arcan"
  base_url: "http://localhost:3000"
  policy:
    allow_capabilities: ["fs:read:**", "fs:write:**", "exec:*"]

EGRI Event Convention

• Lago journal entries use EventKind::Custom with "egri." prefix
• Follows Autonomic's pattern: "autonomic." prefix for homeostatic events
• Schema: schemas/egri-event.schema.json

Direction Rule

Adapters depend downward on both the service they wrap AND the consumer they serve. Core crates (autoany_core, symphony-core) never depend on Life internals.

Multi-Rate Hierarchy

Agent runtimes are message-driven, tool-mediated, and subject to timeouts and approval workflows. This makes them excellent for supervisory control, not for hard real-time servo loops.

The Four Loops

Inner Loop (Hard Real-Time)

• Cadence: milliseconds
• What runs: PID, state feedback, MPC at fixed dt, CBF-QP shield
• LLM involvement: None — deterministic controllers only
• Rationale: Tool-call runtimes cannot guarantee fixed-cycle deadlines

Mid Loop (Soft Real-Time)

• Cadence: tens to hundreds of milliseconds
• What runs: MPC planning updates, state estimator resets, drift monitors
• LLM involvement: Parameter updates only (no reasoning in the loop)
• Rationale: Solver-based; LLM sets weights/horizons offline

Outer Loop (Supervisory)

• Cadence: seconds to minutes
• What runs: LLM sets goals/constraints, selects control modules, approves escalations
• LLM involvement: Yes — this is where the agent reasons
• Rationale: Aligns with tool-driven agents, typed actions, approval workflows

Meta Loop (EGRI)

• Cadence: minutes to days
• What runs: Autoany-style recursive improvement of models/controllers
• LLM involvement: Yes — problem-spec compilation, evaluator design, strategy
• Rationale: Requires evaluator-first + rollback + ledger

Loop-Rate Suitability Heuristics

Validate per plant: these are engineering heuristics, not laws. Your specific system's latency, compute, and safety criticality determine placement.

Supervisory Control Design Patterns

Pattern 1: Setpoint Manager

LLM sets reference trajectories and constraints; inner loop tracks them.

LLM → {reference_trajectory, constraint_bounds, horizon} → MPC → CBF → Plant

Pattern 2: Module Selector

LLM selects which controller to activate based on system state.

LLM → {active_controller: "mpc_aggressive" | "pid_conservative" | "safe_hover"} → Runtime

Pattern 3: Experiment Designer (Identification)

LLM designs data collection experiments for model learning.

LLM → {excitation_signal, duration, safety_bounds} → Plant (via shield) → Dataset → Model update

Pattern 4: EGRI Loop Compiler

LLM compiles improvement goals into formal problem-specs.

User goal → LLM → problem-spec.yaml → Autoany harness → Improved controller

When the LLM CAN Be Closer to the Loop

For slow cyber plants (cloud ops, workflow routing, code generation):

• Actuation is inherently discrete, typed, and slow
• "Inner loop" is seconds, not milliseconds
• LLM can act as the primary controller

But still requires: typed schemas, policy gates, rollback, harness verification. The control hierarchy flattens, but safety principles remain identical.

Orchestration Patterns

Multi-agent orchestration based on the Symphony daemon architecture. Use these patterns when your control system requires concurrent agents, workspace isolation, or long-running supervisory loops.

Symphony Architecture Summary

Symphony implements: poll → dispatch → per-issue worker → reconcile

Start daemon
  │
  ▼
[Poll Loop: configurable interval]
  ├─ Reconcile: kill stalled, check states, clean terminals
  ├─ Dispatch: fetch candidates, sort by priority, check eligibility
  ├─ Spawn workers (one per issue, isolated workspace)
  │   └─ Per-worker:
  │       ├─ Create/reuse workspace (path-contained)
  │       ├─ before_run hook (abort on failure)
  │       ├─ Render prompt template (Liquid)
  │       ├─ Spawn agent subprocess (JSON-RPC protocol)
  │       ├─ Turn loop (up to max_turns)
  │       ├─ after_run hook (log-only on failure)
  │       └─ Exit handler: accumulate tokens, schedule retry
  ├─ Publish snapshot to HTTP API
  └─ Sleep (wake on refresh/shutdown signal)

Safety Invariants (Mandatory)

From Symphony's workspace safety:

1. Path containment: workspace path must start_with(workspace_root) after canonicalization 2. CWD validation: verify workspace_path.is_dir() before agent spawn 3. Identifier sanitization: keep only [A-Za-z0-9._-], replace others with _ 4. Hook safety:

• before_run failure → abort worker (fatal)
• after_run failure → log only (non-fatal)
• All hooks have enforced timeouts

5. Approval posture: must resolve or fail-closed, never stall indefinitely 6. Bounded queues: overload → error requiring retry with exponential backoff

When to Use Orchestration

Orchestration + Control Kernel Integration

Pattern: Orchestrated Controller Tuning

Symphony polls issue tracker for "tune-controller" tickets
  │
  ▼
Per-ticket worker:
  1. Create isolated workspace (clone repo + twin config)
  2. Load problem-spec.control.yaml
  3. Run EGRI loop (autoany) within workspace
  4. If improved: create PR with new controller params
  5. If failed: log to ledger, close ticket with findings

Pattern: Multi-Plant Supervisory Control

Symphony polls plant registry for active plants
  │
  ▼
Per-plant worker:
  1. Observe plant state
  2. LLM reasons about directive θ_t
  3. Controller proposes, shield filters
  4. Apply safe action
  5. Log trace
  6. Report status to orchestrator

Pattern: Incident Response

Symphony polls monitoring for alerts
  │
  ▼
Per-alert worker:
  1. Diagnose: observe plant, check recent traces
  2. Plan: LLM proposes corrective directive
  3. Contain: apply safe action (conservative mode)
  4. Verify: check plant state post-action
  5. Escalate if unresolved after N turns

State Surface

Symphony exposes runtime state via HTTP:

Use these for observability dashboards and integration with CI/CD.

Symphony + Arcan Runtime

The realized stack replaces Symphony's default subprocess-based agent spawning with dispatch via Arcan HTTP sessions. This is configured in WORKFLOW.md:

runtime:
  kind: arcan           # "subprocess" (default) | "arcan"
  base_url: "http://localhost:3000"
  policy:
    allow_capabilities: ["fs:read:**", "fs:write:**", "exec:*"]

How it works

The symphony-arcan adapter crate (symphony/crates/symphony-arcan/) implements Symphony's Runtime trait by translating dispatch calls into Arcan HTTP requests:

1. Session creation — each worker maps to an Arcan session with scoped capabilities 2. Turn loop — Symphony drives turns via Arcan's session API instead of JSON-RPC subprocess 3. Lifecycle — session cleanup, timeout enforcement, and token accounting handled by Arcan 4. Observability — Arcan events flow to Lago automatically via arcan-lago, giving Symphony workers a unified audit trail without extra instrumentation

When to use Arcan runtime vs subprocess

Plant Interface

Standardized API contracts for the control kernel. Language-agnostic; implementable in Python, Rust, TypeScript, or any typed language.

Core Interfaces

Plant

The system being controlled — physical, cyber-physical, or purely cyber.

Plant:
  observe() -> Observation
    # Returns current sensor readings / system state
    # Must include timestamp and observation_id

  apply(action: Action) -> ActuationResult
    # Applies a control action to the system
    # Returns success/failure, new observation, side effects

  reset(seed?: int) -> Observation
    # Reset to initial state (for simulation/testing)
    # Optional seed for reproducibility

  constraints() -> ConstraintSet
    # Returns current hard constraints (state bounds, actuation limits)
    # May be time-varying or mode-dependent

Estimator

Maintains belief state from noisy/partial observations.

Estimator:
  update(obs: Observation) -> BeliefState
    # Fuse new observation into belief
    # Returns updated belief with uncertainty estimates

  predict(belief: BeliefState, actions: ActionSequence) -> BeliefTrajectory
    # Optional: predict future belief states given action plan
    # Used by MPC-style planners

Controller

Produces candidate control actions from belief state and directives.

Controller:
  propose(
    belief: BeliefState,
    directive: ControlDirective,  # θ_t from LLM
    world_model?: WorldModel,
    constraints?: ConstraintSet
  ) -> ProposedAction
    # Returns candidate action sequence + metadata
    # Metadata includes: solver status, cost, feasibility flag

  configure(params: ControllerParams) -> void
    # Update controller parameters (gains, weights, horizons)
    # Used by LLM to tune without replacing the controller

SafetyShield

Hard safety filter — projects proposed actions into safe set.

SafetyShield:
  filter(
    proposed: ProposedAction,
    belief: BeliefState
  ) -> SafeAction
    # Returns: safe_action, certificate, modification_magnitude
    # certificate: proof that safety constraint is satisfied
    # modification_magnitude: ||u_safe - u_proposed|| (monitor for shield saturation)

  feasible(belief: BeliefState) -> bool
    # Check if any safe action exists from current state
    # If false: emergency fallback required

  fallback(belief: BeliefState) -> SafeAction
    # Emergency safe action (e.g., stop, hover, safe state)
    # Must always succeed

Evaluator (Autoany-compatible)

Scores traces for the EGRI improvement loop.

Evaluator:
  score(traces: TraceBatch) -> ScoreVector
    # Returns scalar or vector metrics over a batch of traces
    # Must be deterministic for the same input

  promotion_decision(
    score: ScoreVector,
    baseline: ScoreVector,
    constraints_ok: bool
  ) -> Decision
    # Returns: promote | discard | branch | escalate
    # Implements promotion policy from problem-spec

TraceSink

Append-only ledger for audit and improvement.

TraceSink:
  append(event: TraceEvent) -> void
    # Append a trace event (observation, action, shield cert, score)
    # Must be durable and ordered

  query(filters: TraceFilter) -> TraceEvent[]
    # Query historical traces for analysis
    # Used by EGRI loop and evaluator

The LLM Never Calls Plant Directly

The runtime mediates all plant interactions:

LLM ──(θ_t)──▶ Controller/MetaController tools (strict schemas)
                       │
                   Runtime (trusted)
                       │
                  Plant.apply(safe_u_t)

This enforces: "agent gets only as much freedom as we can judge."

Plant Types

Physical plant (robotics, process control)

• State: continuous (positions, velocities, temperatures)
• Actions: continuous (torques, voltages, flow rates)
• Latency: hard real-time inner loop (ms), LLM at supervisory (seconds)
• Safety: CBF-QP shield mandatory

Cyber-physical plant (cloud infra, IoT)

• State: mixed discrete/continuous (pod counts, latencies, error rates)
• Actions: discrete (scale up/down, restart, reroute)
• Latency: soft real-time (seconds-minutes)
• Safety: policy gates + SLO constraints

Cyber plant (workflows, code, business processes)

• State: discrete (pipeline status, approval state, document versions)
• Actions: discrete (API calls, file edits, approvals)
• Latency: human-scale (seconds-hours)
• Safety: harness gates + rollback + EGRI evaluators

Plant Configuration

Define in .control/plant.yaml:

plant:
  name: "my-system"
  type: cyber  # physical | cyber-physical | cyber
  state:
    measured:
      - name: "build_status"
        type: "enum"
        values: ["passing", "failing", "unknown"]
      - name: "test_coverage"
        type: "float"
        bounds: [0.0, 1.0]
    estimated:
      - name: "code_quality_score"
        type: "float"
        bounds: [0.0, 1.0]
    context:
      - name: "active_branch"
        type: "string"
  actions:
    - name: "run_tests"
      type: "discrete"
      parameters: {}
    - name: "apply_fix"
      type: "discrete"
      parameters:
        file: "string"
        diff: "string"
  constraints:
    hard:
      - "test_coverage >= 0.70"
      - "no_security_vulnerabilities"
    soft:
      - "build_time_s <= 120"
  loop_rates:
    inner: null        # No inner loop for cyber plants
    supervisory: 30s   # LLM decision cadence
    improvement: 1h    # EGRI cycle

Safety Shields

Two distinct safety layers protect agent-controlled systems: pre-action safety (policy gates) and control-theoretic safety (runtime shields).

Layer 1: Policy Gates (Pre-Action Safety)

"Is this action allowed?" — checked before any actuation.

Gate Types

Policy Gate Contract

# .control/policy.yaml
gates:
  - id: "no-direct-plant-access"
    type: hard
    rule: "LLM tool calls must target Controller or MetaController, never Plant directly"
    measurement: "tool_call.target not in ['Plant.apply', 'Plant.reset']"

  - id: "action-budget"
    type: budget
    rule: "Max 50 control actions per EGRI trial"
    measurement: "trial_action_count <= 50"

  - id: "destructive-action-approval"
    type: approval
    rule: "Destructive actions require human confirmation"
    measurement: "action.destructive == false OR human_approved == true"

Approval Policy Rules (from Symphony)

1. Approval must resolve or fail closed — never stall indefinitely 2. Timeout on approval → reject action + log 3. Sandbox mode: execute in isolation, promote only with approval 4. Default posture: fail-closed (deny if uncertain)

Layer 2: Control-Theoretic Safety (Runtime Shields)

Ensure state remains in safe set S during runtime execution.

CBF-QP Shield (Canonical Pattern)

Control Barrier Functions encode safety as barrier constraints. A QP minimally modifies the nominal action while ensuring forward invariance:

u_safe = argmin_u ||u - u_proposed||²
         s.t.  ∂h/∂x · f(x,u) + α(h(x)) ≥ 0   (CBF constraint)
               u_min ≤ u ≤ u_max                   (actuation limits)

Where h(x) > 0 defines the safe set, α is a class-K function.

Shield Integration Pattern

proposed_action = Controller.propose(belief, directive)
                        │
                        ▼
              SafetyShield.filter(proposed, belief)
                        │
               ┌────────┴────────┐
               │                 │
          feasible           infeasible
               │                 │
          safe_action      SafetyShield.fallback(belief)
               │                 │
               ▼                 ▼
          Plant.apply()    Plant.apply(emergency)
               │                 │
               ▼                 ▼
          log(nominal)     log(shield_intervention, severity=high)

Shield Saturation Monitoring

Track ||u_safe - u_proposed|| over time:

• Low modification: controller is operating safely, shield is passive
• Rising modification: controller is pushing boundaries, investigate
• Sustained high modification: controller may be poorly tuned, trigger EGRI review
• Infeasibility: emergency fallback, halt, escalate

Containment Invariants (from Symphony)

For any plant adapter, enforce workspace-style containment:

1. Path containment: all plant interactions scoped to declared namespace 2. CWD validation: verify execution context before any actuation 3. Identifier sanitization: plant/action IDs cleaned of injection vectors 4. Hook safety: before_action hooks can abort; after_action hooks are logged-only

Failure Modes and Mitigations

Combining Both Layers

LLM proposes action
  │
  ▼
Policy Gate Check (Layer 1)
  │
  ├─ DENIED → log + escalate
  │
  ▼ ALLOWED
Controller.propose()
  │
  ▼
CBF-QP Shield (Layer 2)
  │
  ├─ INFEASIBLE → fallback + escalate
  │
  ▼ FEASIBLE
Plant.apply(safe_action)
  │
  ▼
Trace logged with: proposed, safe, certificate, gate_results

Both layers are mandatory. Policy gates catch semantic/business constraint violations. CBF-QP shields catch dynamic/physical constraint violations. Neither alone is sufficient.

World Models

Learned dynamics, digital twins, and data-driven prediction methods that serve as the "plant model" for MPC-style controllers.

Koopman Methods

Lift nonlinear dynamics into higher-dimensional observable space where linear predictors enable efficient MPC.

Agent Integration

• Artifact: Koopman lift function (EDMD variants) — updatable via EGRI
• Controller: Koopman-MPC using lifted linear system
• LLM role: Decide when to relearn lifts, curate datasets, interpret

model mismatch indicators, pick robust strategies

• Verification: Error bounds on approximation, closed-loop stability checks

When to Use

• System has underlying structure that linearizes in lifted coordinates
• Computational budget allows offline lift learning
• Need fast online MPC (linear system → fast QP)

Data-Driven MPC / DeePC

Uses input/output trajectory data (Hankel matrices) for prediction and optimization without an explicit parametric model.

Agent Integration

• Harness: Dataset store + experiment runner (collect trajectories)
• Controller: DeePC optimizer (QP/convex program) as a tool
• LLM role: Choose excitation experiments, select horizons/regularization,

interpret results, update constraints

• Safety: Wrap DeePC output with CBF-QP shield or robust constraint tightening

Robust DeePC

Regularized and distributionally robust formulations interpret regularization as DRO and provide probabilistic robustness guarantees. Use when data is noisy or distribution shifts are expected.

Digital Twins

Real-time virtual replicas supporting monitoring, simulation, prediction, optimization.

Agent Integration

• Role: Provides the harness for safe experimentation and scenario evaluation
• EGRI integration: Twin is the execution backend for controller improvement trials
• LLM role: Orchestrate simulation experiments, interpret mismatches between

twin predictions and real plant observations

• Calibration: Twin validity metrics are a first-class evaluator input

Digital Twin as EGRI Backend

# In problem-spec.yaml
execution:
  backend: simulator
  command: "python3 twin/run_scenario.py --config {{scenario}}"
  timeout_s: 60
  sandbox: true  # Twin runs are inherently sandboxed

Learned Dynamics (Neural, GP, etc.)

Model-based approaches that learn environment models from data.

Agent Integration

• Artifact: Model weights/parameters — improved via EGRI loops
• Controller: Model-based MPC using learned predictions
• LLM role: Select model architectures, design training harnesses,

interpret training curves, gate deployment

• Safety: Prediction uncertainty estimates feed into robust MPC constraints

Method Selection Guide