Runtime Safety

Safe Delegation to Heavy Runtimes

A lightweight agent should not always become a full runtime. Good systems escalate deliberately, with clear limits on cost, permissions, and task scope.

Modern agent systems increasingly combine a lightweight tool-using agent with a heavier runtime that can browse, run shell commands, inspect files, or operate more autonomously over many steps. The design question is when delegation is justified, how it is bounded, and how it can be reviewed afterwards.

Key Facts

Permission tiers: Read-only, bounded action, high-risk, human-approved
Escalation concern: When to delegate to heavier runtimes
Operational controls: Budgets, turn caps, approvals, rollback
Common failure: Silent overreach through tools or subprocesses
Observability: Triggers, tools, outputs, failures, alerts

How should teams design base agent configuration and tool access tiers?

Start by separating stable identity from task-specific instructions, then attach the tool tier. A pattern such as `SOUL.md` plus `TASK.md`, followed by explicit tools, turn caps, spend limits, and conversation history, keeps the runtime clear about who it is acting for, what rules apply, and what authority the current run actually has. After that, tier tools from read-only inspection to bounded action to explicitly high-risk capabilities such as payments, messaging, browser control, shell execution, or system mutations.

How does this relate to MCP and heavier runtimes?

MCP is relevant because tools such as web search, database access, or delegated tasks can be exposed as MCP tools, resources, and prompts. But the configuration itself is broader runtime architecture: identity, task instructions, max turns, spend limits, history loading, escalation rules, and approval boundaries sit above MCP. Escalate to a heavier runtime only when the task genuinely needs multi-file work, terminal access, browser control, or deeper iterative reasoning, and carry the budget, turn, and approval limits into that hand-off.

Trust

Return to the trust principles

Runtime safety should stay anchored to inspectability, blockers, approvals, and explicit hand-offs.

Open principles

Sequencing

Map runtime safety to plan sequencing

The public and protected plan paths matter because the riskiest capabilities should not ship before the proof and governance layer exists.

Open pricing

Design failure containment into the runtime

A production agent runtime earns trust by making tool authority, escalation paths, failures, and budget exhaustion visible before the user has to guess what happened.

Agent configuration contract

Keep stable identity separate from task-specific instructions, then attach tools, limits, and session state explicitly.

Identity or soul files describe who the agent is acting for

Task files describe the current rules, goal, and boundaries

Attach tools, max turns, spend caps, and message history as first-class runtime controls

Permission tiers

Separate read-only inspection from bounded action, then separate high-risk tools from human-approved tools.

Files, search, and status can usually stay read-only

Browser actions, shell, payments, and messaging should be tiered more tightly

Credential scope should match the tool tier, not the whole runtime

Heavy-runtime delegation

Escalate to coding or browser-heavy runtimes only when the task class justifies the cost and risk.

Attach spend and turn caps

Keep the escalation reason inspectable

Provide a rollback or stop path

Observability and recovery

Persist what triggered the run, what context loaded, what tools fired, what output was produced, and what failed.

Make retries visible

Preserve audit trails across queues and workers

Expose kill switches before failure becomes silent drift

Continue through the runtime branch

This branch is meant to work as one library. Use the other guides to complete the operating model beyond the current topic.

Execution Layers

Triggers vs Schedules vs Interactive Agents

One of the most common mistakes in agent systems is forcing every task through a conversational interface. A more reliable approach is to separate three execution layers: triggers for event-driven work, schedules for recurring background work, and interactive agents for dynamic tasks that need clarification, judgement, or iteration.

Context Hubs

Tiered Context Loading for Agent Systems

One of the fastest ways to make an agent slower, more expensive, and less reliable is to give it too much context too early. Tiered context loading turns context discovery into a staged process so the runtime has a navigation system, not just a pile of files.

Should heavy runtimes always be available?

No. They should be available only where the task, permissions, and review model justify them.

Is this only about coding agents?

No. The same pattern applies to browser automation, file processing, workflow agents, and multi-tool operational assistants.

What matters more: the model or the runtime guardrails?

For safe delegation, guardrails often matter more. A strong model with weak runtime controls is still risky.

Continue through the runtime branch

This branch is meant to work as one library. Use the runtime landing page to recover the full operating picture, then move into principles when you need to reconnect runtime decisions to doctrine.

Back to landing page Open principles