---
title: A runtime for agents is an authority system
kind: concept
status: draft
order: 70
summary: A serious agent runtime decides which proposed transitions are admissible through policy, scoped capabilities, isolation, evidence, and recovery.
audience: Platform engineers and technical leaders shaping agent infrastructure
outcome: Design a runtime boundary that does more than route model function calls
prerequisites:
  - Familiarity with authorization, workflows, and bounded execution
domains:
  - agent-systems
  - runtime-infra
  - trust-boundary
updated: 2026-09-06
author: tim
---

A model choosing a function and a runtime executing it is enough to demonstrate
agency. It is not enough to explain how increasingly autonomous systems should
interact with consequential infrastructure. As task horizons grow, the runtime
must decide which proposed actions are currently admissible.

## A plan is not permission

Suppose an agent proposes:

1. inspect Redis;
2. increase memory;
3. restart the cluster;
4. deploy a configuration change;
5. monitor recovery.

A weak runtime treats this as a sequence. A stronger runtime treats every step
as a proposed transition. Inspection may be immediately permitted; a memory
change may only be permitted in staging; a production restart may require
evidence; and deployment may require approval. The plan describes what the
reasoning system wants to do. It does not grant authority.

## Effective authority is an intersection

```text
effective authority =
    user authority
  ∩ organization policy
  ∩ agent role
  ∩ delegated scope
  ∩ current task scope
  ∩ operational state
  ∩ temporary capability leases
```

A production administrator does not thereby give every agent acting for that
person production administration. A delegated task might require only checkout
telemetry read, repository write, and staging deploy.

## Permissions should become temporary

Long-running agents are poorly served by permanent credentials. A capability
lease can be tied to task state:

```yaml
action: production.deploy
resource: checkout-service
version: abc123
invocations: 1
expires: 10 minutes
```

The agent receives no ambient production access. The capability disappears
after use, making autonomy easier to reason about.

## Tools are part of the authority surface

A tool defines a possible action. Compare `bash(command)` with
`restart_staging_service(service)`. Both can eventually restart a service; the
second is easier to authorize, constrain, audit, simulate, rate-limit, and
verify. Tool design is simultaneously model UX, security architecture, policy
surface, and observability design.

Expose only tools relevant to the current phase: metrics, logs, and traces for
diagnosis; repository and test runner access for implementation; staging
deployment and load tests for staging; telemetry again for production
observation. Tool discovery itself can be policy-derived.

## Infrastructure can be task-shaped

Instead of broad shared-account access, provision an ephemeral repository
workspace, temporary database, service clone, synthetic traffic generator, or
constrained network. Give the task credentials to that environment. When it
ends, destroy the environment, revoke credentials, and retain evidence.

This makes mistakes inexpensive and contained rather than requiring every
agent decision to be perfectly reliable.

## The runtime should return more than allow or deny

```text
ALLOW
ALLOW WITH CONSTRAINTS
REQUIRE EVIDENCE
REQUIRE APPROVAL
REDUCE SCOPE
DENY
SUSPEND
ESCALATE
```

For a production restart, the runtime can expose safe alternatives: inspect
production state, simulate impact, restart staging, or collect missing
evidence. That is more useful than an opaque permission error while preserving
the reasoning role.

## Risk and uncertainty are different

A system can be certain about a dangerous action or uncertain about a harmless
experiment. A practical matrix is:

| Consequence | Uncertainty | Response |
| --- | --- | --- |
| Low | Low | Execute |
| Low | High | Experiment |
| High | Low | Verify and possibly approve |
| High | High | Gather information or escalate |

Derive risk from observable properties where possible: production versus
staging, affected resource tier, instance count, reversibility, data mutation,
financial exposure, incident state, and rollback. Semantic judgment can
supplement those facts; it should not replace them.

## The runtime should reason about trajectories

Long-horizon failure is often a pattern: restarting the same service three
times, changing hypotheses seven times, consuming 80% of the budget, and
producing no measurable improvement. The next restart may be individually
permitted, but the trajectory is unhealthy.

Signals such as repeated failure, thrashing, declining information gain, rising
cost, unresolved contradictions, stale evidence, and circular delegation can
trigger replanning, independent review, reduced permissions, human escalation,
or termination.

## Two systems share the task

The agent answers:

> What should I try next?

The runtime answers:

> Which of those transitions are currently admissible?

The reasoning system provides adaptability; the authority system provides
containment. A more capable model may propose a better production action than a
person, but it should not grant itself permission to execute it.

The next generation of agent infrastructure is therefore likely to combine a
workflow engine, authorization server, policy engine, sandbox manager,
credential broker, evidence store, assurance system, and state machine around
a probabilistic reasoning system.

## Draft boundary

This is a publishable architectural draft. It does not describe a released
ReactorJet runtime, SDK, authorization server, or sandbox manager. The examples
are architecture sketches, not installable APIs.

## Related

- [Controlled delegation](/guides/concept/controlled-delegation)
- [Verification is not the last step](/guides/concept/verification-is-state)
- [Authority Compiler](/work/authority-compiler)
- [Long-Horizon Verification](/work/long-horizon-verification)