Ctrl Alt Del

Inspiration

Ctrl Alt Del represents taking back control of autonomous agents. Like the shortcut used to regain control of a misbehaving computer, our middleware reflects three ideas:

Ctrl — control agent behaviour

Alt — provide alternative routing, memory and policy decisions

Delete — stop unsafe, wasteful or failed actions before they become bigger problems

Autonomous AI agents are moving from isolated prototypes into production-grade automation, but many execution frameworks still behave like black boxes. Without inspectable context, cost visibility, structured tracing, safety controls and durable memory, developers have limited insight into what agents are doing and why.

Ctrl Alt Del addresses this by placing a cohesive middleware layer between user intent and autonomous execution in Agent Launchpad. It preserves relevant context, enforces prompt-level safety policy, estimates cost before a Run, records evidence of agent actions, and extends the platform with a persisted Multi-Agent Team Run mode where two to four agents can collaborate on a single task.

Problem Statement and Rationale

Feature	Problem	Technical Rationale
Prompt Security	The platform's shared bearer token protects the deployed demo, but nothing screens what actually goes into a prompt, so credential-shaped text or configured secrets could leak into the model.	A pre-execution Security Guard blocks empty or oversized prompts and credential-shaped or configured-secret text before it ever reaches Ark, with an early preflight check plus a second check at the actual execution boundary.
Cost Visibility	There was no way to know what a Run would cost, or how far off an estimate was, before or after execution.	A deterministic, local Cost Explorer predicts input and output tokens, task complexity, and likely tool calls before execution, and reconciles that prediction against Ark's actual reported usage afterward.
Evidence & Tracing	Execution events such as commands, tool calls, file changes, and errors were otherwise invisible once a Run started.	Glass Box normalizes Runtime activity into lifecycle events, command spans with durations and exit codes, tool calls, and safe reasoning summaries, with sensitive values redacted before persistence.
Memory Governance	Long or reconnected Codex sessions lose early constraints and context.	Bounded hybrid context, made of structured facts, a rolling summary, and the latest eight messages, is injected read-only before each Run, and a hidden structured memory update is validated and stripped from the visible response afterward.
Multi-Agent Collaboration	A single agent can't divide a task across specialized roles or hand off partial work.	A persisted coordinator reserves two to four agents for a Team Run, routes sequential assignments through a durable mailbox, and aggregates token usage into one consolidated result.

Summary of our Architecture Middleware

Five things plug into the starter kit's existing pipeline, sitting between AgentService and AgentRunner where they can actually change behavior before, during, and after execution.

Security Guard, screens the prompt before it reaches Ark, rejecting empty or oversized prompts, credential-shaped text such as api_key=... and any of the application's configured secrets, running both as an early preflight check and again at the execution boundary.
Cost Explorer, is a zero-download, local estimator that predicts input tokens, output tokens, task complexity, and likely tool calls before a Run, then produces a receipt comparing that prediction against Ark's actual reported usage afterward.
Observe Glass Box Tracing, captures Runtime activity as normalized events, lifecycle, commands with exit codes, file changes, tool calls, explicitly emitted reasoning summaries, errors, and token usage, stored inside each Run's existing JSON metadata rather than a separate trace store, and never exposes private chain-of-thought, only what the Runtime explicitly emits.
Hybrid Memory, injects a bounded, read-only context of structured facts and preferences, goals, constraints, decisions and tasks, a rolling summary, and the latest eight messages before each Run, then validates and strips a hidden structured memory update before the response reaches the user; invalid updates are non-fatal and the last valid memory is kept.
Multi-Agent Coordinator, reserves two to four agents for a Team Run, executes them sequentially through a persisted mailbox, passes bounded handoffs between isolated per-agent workspaces, aggregates actual token usage, and supports safe cancellation. An optional Kill Switch can additionally wrap the Runner to watch for recognized Git or network actions in observe or enforce mode; this is an add-on, not core to the assurance pipeline.

How our middleware map onto the starter kit

Security Guard sits before AgentRunner is invoked, at the request and execution boundary, as a pass or fail gate rather than an identity or authorization system.

Cost Explorer runs inside AgentService after memory injection, so it estimates the size of the complete prompt, and before the call to AgentRunner.

Glass Box listens to Runtime activity during execution and writes into the existing JSON metadata store under each Run's events, rather than a standalone append-only trace store.

Hybrid Memory wraps the AgentRunner boundary, injecting context before a Run and extracting a structured update after, with AgentService persisting it per agent.

The Multi-Agent Coordinator sits alongside AgentService, reserving participants and sequencing handoffs through a persisted mailbox, while each agent still runs in its own isolated per-agent workspace; there is no shared multi-agent filesystem. No new identity or credential store was needed. The only new persisted structures are the Run's events array for Glass Box and the collaboration and mailbox records for Team Runs.

Middleware Implementation Details and Scenarios

Security: Prompt-level guard

The starter kit's bearer token protects the whole deployed demo. It is not per-user or per-agent identity, and our middleware doesn't add one.

What it adds is a content-level gate, such as prompts that are empty, excessively long, contain credential-shaped text, or contain the application's own configured secrets are rejected before they reach Ark.

This runs twice, once as an early preflight check so an invalid Run is never created, and again at the actual execution boundary. As evidence, sending api_key=demo-secret-123 as a prompt is rejected with a blocked-request error before any call to the model, while a normal prompt with no credential-shaped content passes through unaffected.

Cost: Estimation vs Actial Receipts

Because memory injection happens first, Cost Explorer estimates the size of the complete Runtime prompt, not just the raw user message.

Before execution it predicts input tokens, output tokens, task complexity, likely tool calls, and an estimated price across the configured model-rate catalogue, entirely locally, with no Ollama, model download, or extra API call.

After execution, Ark's reported usage becomes the source of truth, and the middleware produces a receipt comparing predicted versus actual tokens and cost. It does not dynamically route models or enforce budgets; it is an estimator and reconciler, not a controller.

Logging: Trace and Audit

Runtime activity, command starts and completions, file changes, tool calls, explicitly emitted reasoning summaries, errors, and cancellation, is normalized into events and persisted inside the Run's existing JSON metadata. Correlated command activity forms spans with durations and status. Sensitive values are redacted and event details are bounded before anything is written. This is not a separate append-only store; it lives with the Run it describes.

Observability: Glass Box Trace View

The Glass Box UI reads directly from that persisted Run data to show trace IDs, run and span durations, token usage, ordered events, and failing-step attribution, without maintaining a second source of truth. The frontend polls the backend for Run state and activity; there is no real-time push layer such as SSE or WebSockets yet.

Memory: Hybrid Context Persistence

Before every Run, the memory middleware builds a bounded context, structured facts and preferences, goals, constraints, decisions and tasks, a rolling summary, and the latest eight messages, and inserts it as read-only memory in the Runtime prompt.

After a successful Run, the model emits a hidden structured memory update, which the middleware validates and strips before the user ever sees it. Malformed updates do not fail the Run; the last valid memory stays available. Reconnecting a memory-enabled agent to a fresh Codex thread reconstructs its brief from persisted memory, while a memory-disabled agent cannot.

Multi-Agent: Team Runs

A Team Run reserves two to four agents, then runs them sequentially, not in parallel and not with recursive subagents.

Work is routed through a durable mailbox, so each agent's turn passes a bounded handoff, not the full raw transcript, to the next. Every agent keeps its own isolated workspace; there is no shared multi-agent filesystem. Token usage across all participants is aggregated into one consolidated result, and a Team Run can be safely cancelled mid-sequence.

Limitations

Prompt-level security only: The Security Guard blocks unsafe content, but does not implement per-user identity, scoped or revocable agent credentials, or cross-tenant authorization. There is a single shared demo bearer token, as in the starter kit. Future Iteration: Introduce per-agent scoped tokens and a real authorization boundary at the Runner.
Static model selection: Every Run uses the configured ARK_MODEL, with no dynamic routing between light and heavy tiers and no automatic retry or escalation on failure. Future Iteration: Add heuristic or embedding-based complexity classification to route trivial turns to a lighter tier, with graceful fallback on failure.
Polling-based UI: The Glass Box view relies on periodic HTTP GET polling rather than a push architecture. Future Iteration: Move to Server-Sent Events or WebSockets for lower-latency monitoring, especially useful once multiple Team Run agents are executing.
Sequential, not parallel, collaboration: Team Runs coordinate agents one at a time through a mailbox; they don't run in parallel or spawn recursive subagents, and each agent's workspace stays isolated. Future Iteration: Explore controlled parallel branches with a merge step, once mailbox ordering guarantees are proven out.

How we built it

We built it by targeting specific integration points provided in the starter kit.

Fastify API Edge: -> Boundary validates request structure and length and protects the deployed demo with the existing shared bearer token before anything reaches AgentService; this is demo authentication, not per-user identity.
AgentService: -> Owns the Run lifecycle, moving between ready, busy, and back to ready, or into error, ensures an agent can't have two simultaneous Runs, persists messages, and invokes the middleware pipeline before calling the Runtime. A server restart during an active Run marks it cancelled instead of leaving it stuck. The beforeRun middleware pipeline runs Security Guard, Glass Box trace initialization, memory context injection, and cost prediction in sequence before AgentRunner is invoked.
AgentRunner: -> launches Codex in the agent's isolated, per-agent workspace, a disposable container locally, a child process on ECS, or directly on the host in development, which then talks to the Volcengine Ark Responses API; an optional Kill Switch can wrap this step. The afterRun middleware pipeline validates and extracts the memory update, compares predicted versus actual tokens, generates the cost receipt, and records completion, all persisted atomically by AgentService.
Multi-Agent Coordinator: -> Was added alongside this pipeline to reserve participants, sequence turns through a persisted mailbox, and aggregate usage across a Team Run.

Challenges we ran into

Keeping the estimate honest: As memory injection changes prompt size before Cost Explorer runs, the pipeline had to be ordered so the estimate reflects the complete Runtime prompt, not just the raw user message, and the UI needed to be explicit that this is a local preflight estimate, not an exact bill.
Bounding memory without losing signal: Having to decide what counts as a durable structured fact versus something safe to drop from the rolling summary required care, with the newest user message taking precedence, structured values overriding older transcript details, and malformed updates never failing the underlying Run.
Sequencing multi-agent handoffs safely: Passing bounded context between isolated agent workspaces through a mailbox, rather than sharing state directly, meant designing reservations and cancellation carefully so a Team Run can be stopped mid-sequence without leaving agents in an inconsistent state.

Accomplishments that we're proud of

Sanitized Glass Box Tracing correlates command spans, stable trace IDs, durations, token usage, and failing-step attribution, without ever persisting configured credentials.
Hybrid Context Recovery lets structured facts, rolling summaries, and recent messages allow an agent to reconstruct its brief across disconnected Codex threads, while a memory-disabled agent demonstrably cannot.
Estimated-versus-Actual Cost Receipts pair a zero-download local preflight estimate with reconciliation against Ark's final reported token usage, so prediction error is visible rather than hidden.

Persisted Multi-Agent Handoffs let two to four isolated agents collaborate through an ordered, durable mailbox with reservations, safe cancellation, and aggregated usage.

What we learned

A pass or fail content gate is not an identity system, and shouldn't be described as one. Blocking unsafe prompt content at a trusted boundary is valuable on its own without being dressed up as per-user authorization.

Estimation is most useful when it's honest about being an estimate, and reconciling predicted versus actual cost taught us that the interesting signal is the gap, not a claim of precision.

Sequential coordination is easier to prove than parallel coordination, and a mailbox-based, one-agent-at-a-time Team Run is straightforward to demo and verify, which is why we deliberately didn't claim parallel or recursive multi-agent execution we couldn't yet prove was safe.

What's next for Ctrl Alt Del

A real authorization boundary that moves from a single shared demo token toward scoped, per-agent credentials enforced at the Runner, with real cross-tenant denial behavior.
Dynamic model routing that adds a lightweight complexity classifier so trivial turns can route to a cheaper model tier, with graceful escalation on failure.
Real-time push tracing that replaces HTTP polling in the Glass Box view with Server-Sent Events or WebSockets, particularly valuable once several Team Run agents are executing concurrently.
Parallel Team Runs that explore controlled parallel branches with a merge step, building on the current sequential mailbox model.