A runtime for agents is an authority system

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

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:

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

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
• Verification is not the last step
• Authority Compiler
• Long-Horizon Verification