Goal-centric, backend-agnostic AgentOS control plane blueprint

This document specifies a buildable AgentOS: a model- and runtime-agnostic control plane that lets a human delegate goals to autonomous agents, observe evidence, and intervene only at meaningful decision points.

The design preserves the strongest ideas from the original AgentOS reconstruction—least privilege, isolated execution, explicit approvals, budgets, triggers, and human exception handling—while simplifying the product around outcomes rather than task cards or a fixed cast of agents.

North star:Build the smallest control plane that reliably turns a human-approved goal into verified progress, while keeping authority, cost, and risk bounded.

AgentOS accepts a Goal, creates or updates a Plan, performs bounded Work, captures Evidence, runs an Evaluation, and chooses a Next Action. It repeats until the machine-evaluable Definition of Done passes, a human decision is required, or a safety rail stops the run.

The central model is:

Goal → Plan → Work → Evidence → Evaluation → Next Action
          ↑                                      │
          └──────── retry / fork / revise ───────┘

The operator should be able to state an outcome, approve its boundaries, leave, and return to one of four useful states:

• completed, with verifiable evidence;

• progressing within budget;

• safely stopped with a diagnosis and recovery options;

• waiting on a concise exception that genuinely requires human judgment.

• Goal-oriented orchestration and risk-adaptive plans

• Backend-agnostic agent execution

• Strong least-privilege security and policy enforcement

• Resumable isolated workspaces with TTLs and checkpoints

• Machine-evaluable Definitions of Done

• First-class artifacts, evidence, evaluations, and audit trails

• Retry, fork, cancel, handoff, and escalation controls

• Cost, token, time, concurrency, and risk budgets

• Webhook and scheduled goal creation

• Project, organization, and user orchestration memory

• Postmortems that improve future routing and planning

• A compact UI: Goals, Runs, Inbox, Agents, Settings

• A general-purpose agent runtime built from scratch

• A fixed nine-step software workflow

• A large roster of narrowly named agents

• Cloudflare R2 as a mandatory virtual filesystem

• YAML-as-code or a full CLI

• A messaging product disguised as an inbox

• Unbounded autonomous execution

• A multi-tenant billing platform

Goals, not cards, are the unit of intent. Tasks are internal work items generated from a plan.Evidence, not agent confidence, determines completion. Claims without provenance do not satisfy a Definition of Done.Risk determines process. Workflow depth grows with uncertainty, blast radius, irreversibility, and policy sensitivity.Identity is not configuration. An agent identity provides continuity and accountability; an execution profile supplies model, tools, prompts, and limits for a run.Backend and execution environment are orthogonal. The model API is not the machine on which tools execute.Security is enforced outside prompts. Tools, credentials, network, filesystem, and mutations are denied unless policy grants them.Human attention is scarce. Inbox contains exceptions, not activity chatter.Work is resumable but not ambient. Isolated workspaces expire; checkpoints preserve only declared state.Every run is economically legible. Expected and actual cost, time, tokens, and external spend are visible and bounded.Learning changes future behavior. Postmortems update routing, policies, templates, and memory through reviewable proposals.

Human / webhook / schedule
          │
          ▼
┌─────────────────────────────────────────────────────────┐
│ AgentOS control plane                                   │
│ Goals · plans · policy · orchestration · budgets        │
│ artifacts · evidence · evaluation · memory · exceptions │
└──────────┬───────────────────┬──────────────────────────┘
           │ dispatch          │ persist/audit
           ▼                   ▼
┌──────────────────────┐   Postgres + artifact store
│ AgentBackend         │   secret manager + event log
│ Claude / Codex / ... │
└──────────┬───────────┘
           │ uses
           ▼
┌─────────────────────────────────────────────────────────┐
│ ExecutionTarget                                         │
│ managed sandbox / local Mac / VM / container platform   │
│ isolated workspace · network policy · scoped secrets    │
└─────────────────────────────────────────────────────────┘

The control plane owns intent, policy, state, orchestration, budgets, evidence, evaluation, and audit. Backends generate and reason. Execution targets provide compute and tool access. Neither backend nor target is the system of record.

An AgentBackend

adapts a model or agent harness to one control-plane contract.

interface AgentBackend {
  id: string
  capabilities(): Promise<BackendCapabilities>
  start(input: BackendRunInput): Promise<BackendHandle>
  stream(handle: BackendHandle): AsyncIterable<RunEvent>
  send(handle: BackendHandle, message: BackendMessage): Promise<void>
  checkpoint(handle: BackendHandle): Promise<BackendCheckpoint | null>
  resume(input: BackendResumeInput): Promise<BackendHandle>
  cancel(handle: BackendHandle): Promise<void>
  usage(handle: BackendHandle): Promise<UsageRecord>
}

Initial adapters may include Claude Agent SDK, Codex, OpenAI-compatible APIs, and a custom command harness. Backend-specific concepts remain inside adapters. The control plane must not encode Claude-specific sessions, tools, or model names into domain entities.

Every dispatch resolves four independent fields:

Dimension	Meaning	Examples
backend
Agent/model API or harness	codex , claude-agent-sdk , openai-compatible
model
Model offered by that backend	provider-specific model identifier
executionTarget
Where tools and workspace run	managed sandbox, local Mac, VM, container service
routingPolicy
How the first three are selected	explicit, cheapest-capable, strongest, local-only, privacy-first

An ExecutionTarget

advertises capabilities such as operating system, isolation level, region, GPU, available tools, network controls, checkpoint support, capacity, and price. A backend may reason remotely while its tools run in an isolated local target.

Routing is constraint satisfaction followed by optimization:

• Filter candidates by required capabilities, data residency, security policy, tool availability, context size, and deadline.
• Reject candidates whose worst-case estimate violates a hard budget.
• Score remaining candidates by expected quality, cost, latency, reliability, privacy, and queue time.
• Record the candidate set, chosen route, estimates, and rationale.
• Re-route on retry only when policy permits it.

Routing inputs can come from the Goal, WorkItem, agent execution profile, project policy, and organization policy. The most restrictive applicable policy wins.

A Goal is the operator’s durable statement of desired outcome.

id

,projectId

,title

,objective

,context

constraints[]

,nonGoals[]

,priority

,deadline

definitionOfDone[]

riskAssessment

,budgetPolicy

,routingPolicy

status

:draft | awaiting-approval | active | blocked | completed | cancelled | stopped

confidence

,uncertainties[]

planId

,currentRunId

,createdBy

, timestamps

Goals cannot become active until their objective, constraints, DoD, authority boundary, and hard budgets are valid. High-risk goals require explicit human approval.

Each DoD criterion is an executable assertion, not a prose checkbox.

type DoneCriterion = {
  id: string
  statement: string
  evaluator: EvaluatorRef
  inputs: ArtifactSelector[]
  passCondition: unknown
  requiredEvidence: EvidenceRequirement[]
  weight?: number
  humanApproval?: ApprovalPolicy
  status: "pending" | "passed" | "failed" | "inconclusive" | "waived"
}

Evaluator types include test command, static analysis, schema validation, policy check, artifact existence, deployment health, metric threshold, model-graded rubric, and human approval. Model-graded criteria must declare a rubric and should be paired with deterministic evidence when possible. Waivers require identity, reason, scope, and expiry.

A Plan is a versioned graph of WorkItems generated for a Goal.

Plan

: goal, version, assumptions, risk class, dependencies, critical path, approval stateWorkItem

: intent, required capabilities, inputs, expected outputs, evaluator set, permissions, budget slice, dependencies, retry policy, status

Tasks are therefore implementation details of a plan, not the operator’s primary object. A WorkItem may be performed by one agent, a deterministic job, or a human.

A Run is one orchestration episode for a Goal. An Attempt is one bounded execution of a WorkItem.

• A Run owns plan version, budget ledger, decisions, progress, exceptions, and final outcome.
• An Attempt records agent identity, execution profile snapshot, backend/model/target, workspace, events, artifacts, evidence, usage, confidence, uncertainty, and termination reason.
• Every mutation and external side effect carries the Run and Attempt IDs for auditability and idempotency.

Artifacts are first-class outputs; Evidence is a typed claim about artifacts or external state.

type Artifact = {
  id: string
  kind: "file" | "patch" | "commit" | "pr" | "report" | "log" | "dataset" | "deployment" | "checkpoint"
  uri: string
  contentHash: string
  mimeType?: string
  size?: number
  producerAttemptId: string
  provenance: Provenance
  retentionPolicy: RetentionPolicy
}

type Evidence = {
  id: string
  criterionId?: string
  claim: string
  kind: "test-result" | "inspection" | "metric" | "policy-result" | "approval" | "attestation"
  artifactIds: string[]
  observedAt: Date
  producer: string
  reproducibility: "reproducible" | "snapshot" | "subjective"
  validity: "valid" | "stale" | "superseded" | "invalid"
}

Evidence must preserve provenance: command or method, inputs, environment, relevant versions, timestamps, hashes, and raw output. Evaluations never rely solely on an agent’s narrative summary.

An Evaluation applies evaluators to evidence and produces per-criterion results, overall status, confidence, uncertainty, and recommendations.

NextAction

is one of:

continue

— dispatch the next ready WorkItem;retry

— repeat an Attempt with a bounded change;fork

— explore competing approaches in isolated branches/workspaces;revise-plan

— create a new Plan version;handoff

— transfer work and context to a different identity/profile;escalate

— create a human exception;``

— preserve checkpoints without further dispatch;cancel

— terminate requested work and revoke active authority;complete

— all required DoD criteria pass and approvals exist;stop

— a rail or policy forbids further work.

The decision and rationale are persisted as structured records.

Ship four role templates, not a large fictional organization:

Role	Responsibility
Orchestrator
assess risk, maintain the plan, dispatch work, evaluate progress, choose next actions
Planner
turn a goal into a dependency-aware plan with assumptions, evaluators, and budget estimates
Builder
produce bounded artifacts and evidence for assigned WorkItems
Reviewer
independently challenge outputs, run evaluations, identify risk, and verify evidence

These are defaults, not privileged code paths. Operators can define additional role templates when distinct capability or policy boundaries justify them.

AgentIdentity

provides a stable name, ownership, audit history, reputation metrics, and memory namespace. It does not contain mutable runtime settings.

AgentProfileVersion

is an immutable execution configuration:

• role contract and prompt version;
• required and optional capabilities;
• backend/model/target constraints;
• tool grants and secret references;
• network and workspace policy;
• budget defaults, retry policy, and escalation policy;
• memory read/write scopes.

Each Attempt stores the exact profile version used. Updating a profile never rewrites history.

Replace named collaboration lists with a registry of capabilities and policies.

Examples: code.read

, code.write

, git.commit

, github.pr.create

, tests.run

, browser.inspect

, deploy.preview

, support.read

, artifact.review

, plan.create

.

Agents request help by capability and constraints. The orchestrator resolves a suitable identity/profile through the registry. Delegation is allowed only when:

• the parent has delegate

authority for the requested capability; - the candidate is allowed by project and organization policy;

• the delegated budget and permission subset cannot exceed the parent’s remaining envelope;
• circular and excessive-depth delegation limits pass.

This removes brittle lists such as “Planner may call Reviewer A and Reviewer B” while retaining hard authorization.

The nine-step compound-engineer sequence is an optional template, not the system’s workflow.

Before planning, classify risk using at least:

• blast radius and reversibility;
• data sensitivity and credential exposure;
• production or financial side effects;
• novelty and architectural scope;
• uncertainty and missing context;
• evaluator strength;
• regulatory or policy impact.

Example process profiles:

Risk	Typical flow
Low	build → deterministic checks → complete
Moderate	plan → build → independent review → checks → complete
High	human-approved plan → fork or staged build → specialist review → sandbox validation → human approval
Critical	explicit operator authorization for each irreversible boundary; no autonomous production mutation by default

The Orchestrator may add or remove WorkItems as evidence changes the risk assessment. Any reduction in required review or approval must be justified and policy-permitted.

Confidence is structured metadata, not decorative prose.

Every Plan, Attempt result, Evaluation, and NextAction includes:

confidence

: calibrated probability orlow | medium | high

with rubric;uncertainties[]

: unknown, impact, resolvability, and proposed test;assumptions[]

: statement, evidence, owner, and expiry;disagreement

: conflicting evaluator or agent conclusions;informationGaps[]

: missing inputs that could change the decision.

Low confidence alone does not always require a human. The system should first buy information through a cheap test, independent review, or isolated fork. Escalate when uncertainty is material and cannot be safely reduced within budget or authority.

Each Attempt receives an isolated workspace and scoped session token.

Workspace policy includes:

• source snapshot or commit SHA;
• writable and read-only mounts;
• network allowlist;
• secret grants;
• maximum lifetime and idle TTL;
• checkpoint cadence and maximum retained checkpoints;
• cleanup and legal-hold policy.

Workspaces may survive a backend disconnect or human wait, but never indefinitely. On TTL expiry, the runtime creates a final checkpoint when safe, destroys compute, revokes credentials, and records cleanup evidence.

A checkpoint contains only declared resumable state: repository diff or commit, artifact manifest, tool state that can be safely serialized, event cursor, pending questions, and backend resume token when supported. It is encrypted, hashed, access-controlled, and associated with the profile and policy versions that created it.

Resume validates that credentials, code base, policy, budget, and external assumptions remain valid. Otherwise the orchestrator migrates the work into a fresh workspace or revises the plan.

Use a pluggable ArtifactStore

backed initially by local/S3-compatible object storage plus Postgres metadata. Defer the R2 virtual-filesystem MCP and file-browser product. R2 can later implement the artifact-store interface; agents should not depend on a vendor-specific filesystem abstraction.

Git remains the durable store for code. The artifact store holds reports, logs, patches, evidence bundles, checkpoints, and other non-source outputs.

Security remains a first-class product requirement.

Default deny: no tool, repository, secret, network destination, mutation, delegation, or memory scope without a grant.Short-lived authority: every Attempt gets a scoped token with expiry, audience, Run/WorkItem binding, and idempotency limits.External enforcement: prompts describe policy; gateways and runtimes enforce it.Isolated writable state: no shared writable workspace between concurrent Attempts unless an explicit coordination primitive mediates it.Network egress control: domain/IP policy is enforced below the model and tool layer.Scoped secrets: inject just in time; never store raw values in prompts, events, artifacts, checkpoints, or the application database.Tool mediation: capability gateway validates parameters, resource scope, rate, budget, and approval before execution.Mutation classes: reversible, externally visible, financially consequential, privileged, and destructive actions receive progressively stronger gates.Untrusted-input boundaries: fetched content, issues, web pages, emails, logs, and artifacts are labeled untrusted and cannot redefine policy.Evidence integrity: hash artifacts, sign high-value attestations where practical, and retain evaluator provenance.Revocation: cancel immediately prevents new calls, revokes session credentials, and asks the runtime to stop; cleanup is verified asynchronously.Audit: append-only events cover routing, grants, tool calls, approvals, side effects, evidence, evaluations, checkpoint access, and cleanup.Policy hierarchy: organization policy constrains project policy, which constrains Goal and WorkItem policy. Children can narrow but not broaden authority.

Approval gates are enforced by APIs and capability gateways, never by asking the agent to behave.

Retry requires a reason and a bounded delta: new context, different prompt/profile version, different candidate route, expanded evaluator, or transient-failure backoff. Identical retries are capped and detected.

Fork creates sibling WorkItems or Attempts with isolated workspaces and explicit comparison criteria. The merge decision is an Evaluation; losing forks are retained according to artifact policy, then cleaned up.

Cancel stops future dispatch, revokes authority, signals active backends, preserves audit/evidence, and cleans workspaces. It is idempotent and distinct from .

Handoff packages objective, constraints, plan position, artifact manifest, evidence, unresolved uncertainty, remaining budget, and current checkpoint. The receiver must explicitly accept the authority envelope.

Escalation creates a structured exception with impact, deadline, evidence, attempted remedies, recommended default, and consequences of inaction. It never forwards a raw agent transcript as the primary request.

Detect repeated failure signatures, unchanged evidence, oscillating plan revisions, evaluator disagreement, budget burn without criterion progress, and recurring human questions. Response order is diagnose → alter approach → fork or handoff → escalate or stop.

Inbox contains only items requiring human attention:

• an approval required by policy;
• a material ambiguity that cannot be safely resolved;
• a blocked credential or external dependency;
• budget or deadline intervention;
• conflicting high-impact evidence;
• completion review where human approval is part of DoD.

Every exception has severity, due time, Goal/Run link, concise question, evidence, recommended action, alternatives, and a safe default on timeout. Replies create decisions and resume orchestration; they do not revive an expired workspace without validation.

Completion notifications and routine progress belong in Goal/Run views, not Inbox.

Budgets can constrain:

• model tokens and API cost;
• execution minutes and compute cost;
• wall-clock deadline;
• external service spend;
• concurrency;
• number of retries, forks, and human escalations;
• tool call count or rate;
• carbon, region, or privacy preferences where supported.

Each Goal has hard limits and optional soft targets. Plans allocate budget slices to WorkItems; delegation can only subdivide remaining budget. The ledger reserves estimated worst-case cost before dispatch and reconciles actual usage afterward.

The Orchestrator should consider marginal value of information: spend on another test, review, or stronger model only when its expected reduction in failure risk is worth the cost. A cheap route is not economical if it causes retries or weak evidence.

On soft-limit breach, re-plan or route more cheaply. On hard-limit breach, stop unless a pre-authorized contingency applies. Budget increases require a human decision with forecast, progress, and alternatives.

Memory stores decisions and reusable operational knowledge, not hidden prompt accumulation.

User memory: communication preferences, approval patterns, and explicit standing constraints.Project memory: architecture, commands, repository conventions, evaluator history, known hazards, and prior decisions.Organization memory: policies, approved services, risk thresholds, cost benchmarks, and cross-project incidents.

Memory entries contain source, scope, owner, confidence, freshness, sensitivity, expiry/review date, and links to evidence. Retrieval is permission-filtered and logged. Higher scope does not automatically expose sensitive lower-scope content.

Agents propose durable memory changes. Policy-sensitive or organization-wide changes require review. Contradictions are surfaced; newer text does not silently overwrite authoritative decisions.

Trigger a postmortem for material failure, budget overrun, unsafe attempt, repeated retry, incorrect completion, or operator-requested review. Capture:

• expected versus actual outcome;
• timeline and decision points;
• causal factors, including policy and system factors;
• missed or misleading evidence;
• routing and budget performance;
• recovery effectiveness;
• proposed changes to evaluators, policies, profiles, templates, or memory.

Learning proposals are versioned and tested where possible. The system never autonomously weakens a security control because doing so would have made a past run easier.

Webhooks and schedules create Goals or bounded WorkItems through the same policy path as the UI.

• Authenticate, validate, rate-limit, and sanitize payloads before they become context.
• Bind each trigger to a Goal template, capability set, budget ceiling, and idempotency key.
• Never pass raw headers, secrets, or untrusted instructions as system policy.
• Repeated events deduplicate or attach to an existing Goal according to declared rules.

Support triage, diagnostics, content jobs, and maintenance are example configurations—not hardcoded core agents.

Keep the first product to five surfaces:

Goals— create/approve goals; inspect DoD, plan, progress, evidence, spend, uncertainty, and final result.** Runs**— live and historical orchestration timelines; attempts, routes, workspaces, artifacts, evidence, evaluations, usage, and control actions.Inbox— prioritized exception queue with approvals and decisions.** Agents**— identities, profile versions, four default role templates, capabilities, performance, and memory scopes.** Settings**— projects, organization policy, backends, models, execution targets, capability registry, integrations, secrets, budgets, triggers, and retention.

Artifacts are viewed contextually inside Goals and Runs. There is no separate virtual-filesystem UI in MVP. Activity is a filterable Run timeline, not a separate global feed.

POST   /goals
GET    /goals/:id
PATCH  /goals/:id
POST   /goals/:id/approve
POST   /goals/:id/
POST   /goals/:id/resume
POST   /goals/:id/cancel

GET    /goals/:id/plans
POST   /goals/:id/plans/:version/approve
GET    /goals/:id/evaluations

GET    /runs
GET    /runs/:id
GET    /runs/:id/events
POST   /runs/:id/retry
POST   /runs/:id/fork
POST   /runs/:id/handoff
POST   /runs/:id/escalate
POST   /runs/:id/cancel

GET    /artifacts/:id
GET    /evidence/:id

GET    /inbox
POST   /inbox/:id/decide

GET    /agents
POST   /agents
POST   /agents/:id/profiles
GET    /capabilities

GET    /settings/backends
GET    /settings/execution-targets
GET    /settings/policies
GET    /settings/budgets

POST   /hooks/:triggerId

POST   /internal/attempts/:id/events
POST   /internal/attempts/:id/artifacts
POST   /internal/attempts/:id/evidence
POST   /internal/attempts/:id/checkpoints
POST   /internal/attempts/:id/usage

All mutating operations support idempotency keys. Internal endpoints authorize the exact Attempt, capability, resource scope, and expiry.

• Define Goal → Plan → Work → Evidence → Evaluation → Next Action schemas.
• Define AgentBackend

,ExecutionTarget

,ArtifactStore

, evaluator, capability, policy, and event contracts. - Write threat model, mutation classes, and policy hierarchy.

• Add event log and budget-ledger foundations.

Exit: contract tests pass for one fake backend and target; prohibited authority cannot be represented as a valid dispatch.

• Goals UI and API with executable DoD.
• Planner, Builder, Reviewer, and Orchestrator profiles.
• One backend adapter and one isolated target.
• WorkItems, Attempts, artifacts, evidence, deterministic evaluators, and Run timeline.
• Hard token/cost/time limits and cancel.

Exit: a small repository goal completes only after checks produce valid evidence; cancelling revokes the Attempt and cleanup is verified.

• Capability gateway, scoped tokens, network policy, secret injection, audit.
• Workspace TTL, checkpoint, destroy, and validated resume.
• Mutation approvals and exception queue.

Exit: prompt injection cannot obtain an ungranted tool/network/secret; an interrupted run resumes from a checkpoint in a fresh validated workspace.

• Risk classifier and workflow profiles.
• Retry, fork, handoff, escalation, stuck detection, and plan versioning.
• Independent review and evaluator disagreement handling.

Exit: low-risk work takes the short path; high-risk work requires its configured review/approval path; identical retries stop.

• Multiple backend/model/target candidates.
• Capability discovery, route scoring, reservation/reconciliation ledger, and budget re-planning.
• Cost and reliability metrics by route and profile.

Exit: routing respects hard constraints and records rationale; a route cannot start without reserved budget.

• User/project/organization memory with provenance and review.
• Postmortems and learning proposals.
• Authenticated webhooks, schedules, and deduplication.

Exit: a reviewed postmortem proposal improves a later plan or evaluator; unreviewed learning cannot weaken policy.

• YAML export/import and CLI after the API and schemas stabilize.
• R2-backed artifact storage or virtual filesystem only when real workflows require it.
• Additional backends, targets, evaluator types, and role templates.

Evidence-gated completion: a Run cannot complete from an agent message; every required DoD criterion has a current passing Evaluation and required approval.Backend portability: the same WorkItem contract executes against two fake backend adapters without domain changes.Orthogonal routing: backend/model and execution target can be changed independently when capabilities allow.Risk adaptation: a low-risk fixture uses a short flow; a high-risk fixture adds independent review and human approval.Default deny: ungranted tool, repo, secret, network, delegation, and memory access are rejected outside the model.Delegation bounds: delegated capabilities and budget are strict subsets of the parent envelope.Workspace isolation: concurrent Attempts cannot read or mutate each other’s writable state.TTL cleanup: expired workspaces are destroyed, credentials revoked, and cleanup evidence recorded.Resume validation: changed policy or revoked credentials prevents blind resume and triggers re-plan or fresh execution.Retry control: identical failure signatures reach the retry cap and produce a diagnosis instead of looping.Fork comparison: competing artifacts are evaluated against declared criteria before selection.Cancellation: cancel is idempotent, prevents new calls, revokes tokens, signals the backend, and completes cleanup.Exception quality: Inbox items contain a decision, evidence, recommendation, deadline, and safe default—not a raw transcript.Hard budgets: dispatch is refused when worst-case reservation exceeds remaining budget; actual usage reconciles exactly once.Confidence honesty: material uncertainties block or change the NextAction according to policy.Artifact provenance: hashes, producer, inputs, method, and timestamps can reproduce or audit deterministic evidence.Memory boundaries: retrieval respects user/project/organization scope and sensitivity; all durable writes have provenance.Learning safety: postmortem proposals are reviewable and cannot silently weaken security or approvals.Trigger safety: invalid signatures fail, duplicate events are idempotent, and payload instructions cannot alter system policy.Audit completeness: a Run can be reconstructed from goal approval through routing, calls, artifacts, evaluations, decisions, and cleanup.

• Treat the schemas and interfaces as contracts; keep provider-specific details in adapters.
• Start with one excellent end-to-end Goal flow before adding integrations.
• Prefer deterministic evaluators; label model judgments and preserve their rubrics and inputs.
• Never allow an agent to self-certify permissions, approval, evidence validity, or completion.
• Never retry without recording what changed.
• Never persist credentials in prompts, logs, artifacts, evidence, memory, or checkpoints.
• Never let a child delegation broaden authority or budget.
• Never retain a workspace past TTL without an explicit policy-authorized extension.
• Keep the operator UI centered on outcomes, exceptions, evidence, and control.
• Defer YAML, CLI, R2 filesystem, and role proliferation until observed usage justifies them.

You create a Goal, state constraints, approve a machine-evaluable Definition of Done, and set hard budgets. AgentOS assesses risk and produces a plan. An Orchestrator dispatches capability-matched Planner, Builder, and Reviewer profiles through whichever backend, model, and isolated execution target best satisfy policy and economics. Work produces artifacts; evaluators turn them into evidence. The system retries, forks, revises, or hands off within bounded authority. It interrupts you only for a real exception. When every required criterion passes, AgentOS presents the result, evidence, provenance, cost, uncertainty, and audit trail. Workspaces expire, credentials are revoked, and useful lessons become reviewable memory and postmortem improvements.

source & further reading

gist.github.com — original article rules for ai agents Free Claude AI API keys and credits for agentic coding & vibe coding for developers. Velaru audit anchor — 658 entries — SCITT RFC9943 — 2026-08-29T00:14:22.060739