{"slug": "agentos-blueprint-reconstructed-from-danny-postma-s-agent-sdk-talk-so-an-agent", "title": "AgentOS blueprint — reconstructed from Danny Postma's Agent SDK talk so an agent can build the system", "summary": "A developer reconstructed a blueprint for a personal AgentOS from Danny Postma's talk on building an agent control plane using Anthropic's Claude Agent SDK. The system automates coding and operational tasks via ephemeral agent containers, a Kanban task board, goal loops, and least-privilege isolation, with persistent storage on Cloudflare R2. The blueprint is intended as both a product spec and an implementation prompt for an AI coding agent.", "body_md": "Reconstructed from Danny Postma's talk *How I Built My Own AgentOS on Claude's Agent SDK (So You Can Too)* (2026). This document is both a product spec for a human and an implementation prompt for an AI coding agent. Build exactly this system. Do not invent features that are not specified here.\n\n**Role contracts and prompts in this file are reconstructed from the talk, not his verbatim files.** Mark every reconstructed prompt in code comments and docs as such.\n\nBuild a personal AgentOS: a control plane + UI on top of cloud-managed agents (Anthropic Claude Agent SDK / Claude managed agents) that lets a human set a goal or task, assign a scoped agent, and walk away. Agents run in ephemeral containers, do the work (plan, implement, review, commit), and only message the human when they are stuck or need a decision.\n\nThe system should automate the majority of coding and operational work: cron, webhooks, Kanban tasks, and open-ended goal loops. After each session the container is destroyed. The next session reinitializes cleanly.\n\n- Multi-agent control plane with per-agent prompts, skills, MCPs, repos, env, and collaboration lists\n- Least-privilege isolation: per-agent container, per-agent MCP/repo/network access, per-agent filesystem folder ACLs\n- Ephemeral session lifecycle: pull repo → inject secrets → do work → commit → destroy container\n- Persistent filesystem via Cloudflare R2 + an MCP that enforces read/write/delete server-side\n- Task Kanban (\n`todo`\n\n/`doing`\n\n/`review`\n\n/`done`\n\n) with assign-agent, run-now, schedule, recurring, attachments, templates, approval gates, and follow-up chains - A default \"compound engineer\" / feature-build template (9 steps, including human approval gates)\n- Goals (\"gauntlet loop\"): definition of done, orchestrator that spawns the next specialist, progress log, spend/time/stuck caps\n- Inbox MCP: agents message the human; human replies resume the session; multiple-choice questions; PWA + push\n- Activity feed + live session viewer (watch tool calls in real time)\n- Triggers: inbound webhooks spawn a scoped job\n- Automations: cron jobs that spawn tasks/agents\n- Runner routing: Claude managed-agents cloud vs cheap local VM (Claude\n`--dangerously-skip-permissions`\n\nand Grok in yolo mode); per-goal and per-agent routing - YAML-as-code per project + CLI (\n`help`\n\n, push/pull sync, create project/goal/task, adjust agents, create skills) - Encrypted secret storage (he used Google's token encryption system; name forgotten — treat as Secret Manager / Cloud KMS)\n- UI to inspect/edit/download/preview files on the R2 filesystem\n\n- Deep-dive videos / publishing exact code of his production system\n- Open-sourcing his exact agents/skills/prompts (he offered; we do not have them)\n- His own future custom runner replacing Claude managed agents\n- Game-project specifics (\n`fight-for`\n\nrepo is only an example of a mounted repo) - Exact spend numbers as product requirements (\n`$500/day`\n\ncloud,`$1000`\n\nuncapped goal,`$10`\n\nHetzner VM are anecdotes, not SLOs)\n\n- A multi-tenant SaaS for other companies. This is a single-operator AgentOS.\n- Giving every agent full filesystem, Gmail, GitHub, and production credentials \"for convenience.\"\n- Persistent long-lived agent containers. Sessions are throwaway.\n- Inventing extra agent roles, extra template steps, or extra UI beyond what he described.\n- Copying his verbatim system prompts (unknown). Reconstruct role contracts only.\n\nAgentOS is a **control plane** you own, sitting on top of **Claude managed agents / Agent SDK**.\n\n```\n Human\n   │  writes spec / creates task / creates goal / replies in inbox\n   ▼\n┌──────────────────────────────────────────────────────────┐\n│  AgentOS control plane (your app)                        │\n│  UI · API · CLI · YAML sync · webhooks · cron            │\n│  Kanban tasks · Goals/orchestrator · Inbox · Sessions    │\n└───────────────┬──────────────────────────┬───────────────┘\n                │ spawn session            │ persist\n                ▼                          ▼\n     Claude Agent SDK /              R2 filesystem MCP\n     local runner (Hetzner)          Secrets store\n                │\n                ▼\n     Ephemeral container\n       - clone allowed repos\n       - inject allowed env\n       - attach allowed MCPs\n       - apply network allowlist\n       - run agent with skills\n       - commit if allowed\n       - DESTROY\n```\n\nMental model:\n\n- A\n**Project** is the unit of YAML-as-code. It declares agents, skills, templates, MCP connections, repos. - An\n**Agent** is a named role with a foundational prompt + role prompt, a model, skills, MCPs, repos, a collaboration list, an environment, and a runner preference. - A\n**Task** is a Kanban card. One agent works it. It can be one-shot, scheduled, recurring, gated, or part of a follow-up chain. - A\n**Goal** is an open-ended loop. An orchestrator keeps spawning specialists until a human-approved Definition of Done is fully checked, or a safety rail trips. - A\n**Session** is one containerized agent run. It is born empty, initialized, executed, committed, and thrown away. - The\n**Inbox** is the only human interrupt channel. Agents do not wait on the human unless they are stuck or need a decision. **Least privilege is first-class.** Access is granted per agent, enforced at MCP, network, filesystem, and repo layers. Prompt leaks must not be able to reach anything the agent was not given.\n\n| Layer | Responsibility |\n|---|---|\n| Control plane + UI | Projects, agents, tasks, goals, inbox, triggers, automations, session records, YAML sync, ACL policy. Your code. |\n| Runtime | Claude Agent SDK / Claude managed agents (cloud) or a cheap local runner (Hetzner VM running Claude Code with `--dangerously-skip-permissions` , and Grok in yolo mode). |\n| Persistence | Cloudflare R2 (files) via a custom MCP; encrypted secrets (Google Secret Manager / Cloud KMS — he forgot the product name); app DB for domain objects. |\n\nHe started in the Claude Code terminal and realized he wanted to overload work, leave, and come back hours later. Cron and triggers require unattended runs. Each session therefore:\n\n- Starts a unique container.\n- Pulls the allowed repo(s).\n- Gets a scoped view of the filesystem (R2 MCP), allowed MCPs, allowed env, allowed network hosts.\n- Does the task.\n- Commits (if the agent/repo policy allows).\n- Cleans up. The container is destroyed.\n- The next session reinitializes the project cleanly. No leftover state except what was committed to git or written to R2 through the MCP.\n\nThe SDK already gives: spin up sessions, MCP connections, files API. AgentOS is **your UI and policy on top**: agent catalog, least-privilege walls, Kanban, goals/orchestrator, inbox, triggers, cron, YAML, runner routing, live session viewer.\n\nHe said he is starting to work out his own runtime pieces. Do not build a from-scratch agent runtime in MVP. Use the SDK. Local runners are an alternative execution backend with the same control-plane contract.\n\nThese are opinionated defaults so an agent can start. They are not his exact stack.\n\n| Concern | Assumption |\n|---|---|\n| Language | TypeScript (Node 20+) |\n| API | Hono or Fastify on a single service |\n| DB | Postgres + Prisma (or Drizzle) |\n| Queue / cron | A durable job runner (e.g. pg-boss or Inngest). Cron automations and scheduled tasks enqueue jobs. |\n| Agent runtime (cloud) | Anthropic Claude Agent SDK / Claude managed agents |\n| Agent runtime (local) | A worker on a cheap VM that can run Claude Code (`--dangerously-skip-permissions` ) and Grok in yolo mode |\n| Files | Cloudflare R2 + a custom MCP server that enforces ACLs |\n| Secrets | Google Secret Manager (he said \"Google's token encryption system\" and forgot the name; Cloud KMS is the alternative). Never store raw tokens in the app DB. |\n| Auth | Single-operator. One human user. Session cookie or personal access for CLI. |\n| UI | React + Vite. Sidebar app. Mobile-responsive PWA for inbox + push. |\n| Webhooks | Public HTTPS receiver with per-trigger secrets. |\n| Push | Web Push (VAPID) for the PWA. |\n\nDo not pretend this is his production stack. It is a buildable default that matches the capabilities he described.\n\nImplement these entities. Names can vary; the fields and relationships cannot be dropped.\n\nA workspace that maps to a YAML AgentOS file.\n\n`id`\n\n,`name`\n\n,`slug`\n\n`yamlDocument`\n\n(canonical on disk / in git; DB is a projection)- has many: Agents, Skills, TaskTemplates, MCPConnections, Repos, Triggers, Automations, Tasks, Goals\n\n`id`\n\n,`projectId`\n\n`name`\n\n(e.g.`default`\n\n,`senior-dev`\n\n,`plan`\n\n,`spec`\n\n,`review-coordinator`\n\n,`feasibility`\n\n,`scope-guardian`\n\n,`coherence`\n\n,`implementation-plan-executioner`\n\n,`librarian`\n\n,`customer-support`\n\n,`diagnostic`\n\n,`linkedin-content`\n\n)`title`\n\n`model`\n\n(e.g. a Claude model for planners; Grok 4.6 for workers — routing is also a runner concern)`foundationalPrompt`\n\n— shared AgentOS prompt: which files/systems exist, which MCPs exist, how inbox works, how to finish a task, least-privilege rules`rolePrompt`\n\n— the one-job contract (see §8)`skillIds[]`\n\n`mcpConnectionIds[]`\n\n`repoAccess[]`\n\n—`{ repoId, mountPath, permissions: git-read | git-write }`\n\n`filesystemGrants[]`\n\n—`{ folderPath, canRead, canWrite, canDelete }`\n\n`collaborationList[]`\n\n— agent ids this agent may spawn as subtasks`environmentId`\n\n`runnerPreference`\n\n—`cloud`\n\n|`local`\n\n|`inherit`\n\n`inboxAccess`\n\n— boolean (some tasks need it; spec step does)**Least privilege default: deny.** An agent gets nothing that is not listed.\n\nConcrete agents he named (implement these as defaults; more can be added via YAML/UI/CLI):\n\n| Agent | One job |\n|---|---|\n| default | General workhorse |\n| senior-dev | Implement / apply review fixes |\n| plan | Turn an approved spec into a concrete implementation plan; write it to the task; finish |\n| spec | Produce a detailed feature spec (used in the template; approval-gated) |\n| review-coordinator | Spawn specialized reviewers; consolidate must-fix / should-fix |\n| feasibility | Review a plan for feasibility |\n| scope-guardian | Review a plan for scope creep |\n| coherence | Review a plan for coherence |\n| implementation-plan-executioner | Implement the code from the plan |\n| librarian | Update the internal wiki from how the codebase actually works |\n| customer-support | Handle support chats via Front MCP only |\n| diagnostic | Given a bug + support chat + repo, produce a cause report |\n| linkedin-content | Recurring content automation |\n\nYou may add agents through YAML. Do not hard-require every named agent for MVP, but ship `default`\n\n, `plan`\n\n, `senior-dev`\n\n, `spec`\n\n, `review-coordinator`\n\n, `feasibility`\n\n, `scope-guardian`\n\n, `coherence`\n\n, `implementation-plan-executioner`\n\n, `librarian`\n\nso the feature template runs.\n\n`id`\n\n,`name`\n\n`networking`\n\n—`open`\n\n|`limited`\n\n`allowedHosts[]`\n\n— e.g.`api.front.com`\n\n. If`limited`\n\n, the container/proxy**blocks everything else at the base level**, including GitHub, even if a leaked prompt asks.- This is independent of MCP grants. Network deny is a second wall.\n\n`id`\n\n,`name`\n\n,`slug`\n\n(e.g.`plan-mode`\n\ninvoked as`/plan`\n\n)`kind`\n\n—`prompt`\n\n|`file`\n\n(e.g. a Python script the agent can run)`body`\n\nor`filePath`\n\non the R2 filesystem- Skills are attached per agent. Plan mode is a skill.\n\n`id`\n\n,`name`\n\n(e.g.`github`\n\n,`front`\n\n,`agentos`\n\n,`r2-fs`\n\n,`inbox`\n\n)`transport`\n\n/ connection config`credentialSecretId`\n\n— pointer into the secret store, not a raw token`allowedOperations`\n\nif the MCP supports scoping- Agents reference connections by id. Example: customer-support gets Front, never Gmail, never GitHub. Plan agent gets plan-mode + AgentOS MCP, not Ahrefs, not GitHub.\n\nBuilt-in MCPs you must implement:\n\n**AgentOS MCP**— read/write the current task, mark status (except when an approval gate forbids the agent from marking`done`\n\n), spawn a collaborator subtask, read project metadata the agent is allowed to see**Inbox MCP**— send a message to the human; send a multiple-choice question; read replies** R2 filesystem MCP**— list/read/write/delete under granted folders only** GitHub MCP**— only if the agent is granted that connection + repo access\n\nExternal MCPs he mentioned as examples (configure, do not hardcode product logic): Front, Ahrefs, Gmail (explicitly **not** given to support), MongoDB read-only via env.\n\n`id`\n\n,`name`\n\n(example:`fight-for`\n\nfor a game project — example only)`remoteUrl`\n\n`mountPath`\n\ninside the container`credentialSecretId`\n\n(PAT or deploy key)`defaultBranch`\n\n`id`\n\n,`name`\n\n,`providerRef`\n\n(Google Secret Manager / KMS resource name)`purpose`\n\n—`mcp`\n\n|`repo`\n\n|`env`\n\n|`webhook`\n\n- Injected into a session only if the agent/environment lists them.\n- Stored encrypted at rest in Google's system. App DB holds only the reference.\n\n`id`\n\n,`projectId`\n\n`name`\n\n,`description`\n\n`status`\n\n—`todo`\n\n|`doing`\n\n|`review`\n\n|`done`\n\n`assigneeType`\n\n—`agent`\n\n|`human`\n\n`assigneeAgentId`\n\nnullable`attachments[]`\n\n— FileObject ids (spec files, etc.)`approvalGate`\n\n— if true,**the assigned agent can never mark this task**. Only the human can. The next follow-up must not start until status is`done`\n\n`done`\n\n.`followUpTaskId`\n\n/`chainId`\n\n+`chainIndex`\n\n— template-generated chain`schedule`\n\n—`once-now`\n\n|`{ runAt }`\n\n|`{ cron, timezone }`\n\n(e.g. every Monday of the month, summarize inbox)`templateId`\n\nnullable`activity[]`\n\n— messages the agent writes into the task/inbox`sessionIds[]`\n\n`id`\n\n,`projectId`\n\n,`name`\n\n(e.g.`compound-engineer-workflow`\n\n)`description`\n\n— \"~3-hour fully managed feature build\" (his words; actual runs were ~5–6 hours)`variables[]`\n\n— e.g.`branchName`\n\n`steps[]`\n\n— each step: name, assignee agent, prompt, approvalGate, attachmentsFromPrevious, spawnPolicy- Instantiating a template creates a chain of Tasks. Step N+1 is blocked until step N is\n`done`\n\n.\n\n`id`\n\n,`projectId`\n\n`title`\n\n,`spec`\n\n(or a generated-from-spec-sheet DoD)`definitionOfDone[]`\n\n— checkboxes, written by the human or generated from a spec sheet, then human-approved`status`\n\n—`active`\n\n|`paused`\n\n|`completed`\n\n|`stopped-spend`\n\n|`stopped-time`\n\n|`stopped-stuck`\n\n`spendCapUsd`\n\nnullable —**required in product UX**; he ran one overnight without a cap and hit $1000`maxDuration`\n\nnullable`stuckThreshold`\n\n— default 19 identical iterations, then orchestrator stops`runnerPreference`\n\n—`cloud`\n\n|`local`\n\n|`auto`\n\n(\"when busy use cloud; otherwise local\"; per-goal override: \"this one should only run on local runners\")`progressLog`\n\n— append-only, shared across sessions`sharedInbox`\n\n+ shared filesystem folder`sessionIds[]`\n\n`id`\n\n,`projectId`\n\n`name`\n\n(e.g.`customer-support-inbound`\n\n,`bug-report`\n\n)`webhookSecretId`\n\n`agentId`\n\n— the scoped agent that runs`jobPrompt`\n\n/ mapping from payload → task description- Example: support message in → webhook → job. Agent has Front (or equivalent) only, analyzes chat, assigns a support rep or account executive. One trigger fired 600 times.\n- Example: support submits a bug → diagnostic agent with\n**repo + support chat**, writes a report. If the human approves, start the implement → plan → plan review → fix → E2E test chain. Human only reviews and merges.\n\n`id`\n\n,`projectId`\n\n`name`\n\n(e.g. weekly LinkedIn content, first-of-month LinkedIn content bot)`cron`\n\n,`timezone`\n\n`taskTemplateId`\n\nor inline task spec +`agentId`\n\n- Distinct from Task.recurring: Automations are named cron entries in the sidebar. Recurring tasks are a schedule field on a Task. Implement both; they can share the same scheduler.\n\n`id`\n\n`from`\n\n—`agent`\n\n|`human`\n\n`agentId`\n\n,`sessionId`\n\n,`taskId`\n\n,`goalId`\n\nnullable`kind`\n\n—`text`\n\n|`multiple-choice`\n\n(radio buttons, like Claude's ask-user-question)`body`\n\n,`choices[]`\n\n,`selectedChoice`\n\n`status`\n\n—`open`\n\n|`answered`\n\n|`closed`\n\n- Answering an open message\n**resumes the waiting session**(sends the reply back into the agent).\n\n`id`\n\n,`agentId`\n\n,`taskId`\n\n/`goalId`\n\n`runner`\n\n—`cloud`\n\n|`local`\n\n`status`\n\n—`starting`\n\n|`running`\n\n|`waiting-inbox`\n\n|`committing`\n\n|`destroyed`\n\n|`failed`\n\n`containerId`\n\n/ SDK session id`toolCallLog[]`\n\n— for the live viewer`startedAt`\n\n,`endedAt`\n\n,`costUsd`\n\nif available`commitShas[]`\n\n`id`\n\n,`bucketKey`\n\n(R2)`path`\n\n,`projectId`\n\n`mime`\n\n,`size`\n\n- Previewable in UI. Agents never touch R2 except through the filesystem MCP.\n\nThese are product requirements, not suggestions.\n\n**Default deny.** An agent has no MCPs, no repos, no env, no filesystem write, no network, no collaboration spawn, unless listed on the agent.**One container per session.** No shared writable container between agents.**Customer-support bot** may have Front MCP. It must never have Gmail. It must never have GitHub / repo access. He was explicit: do not leak codebase info while doing support.**Plan agent** has plan-mode skill + AgentOS MCP. It does**not** get Ahrefs or GitHub MCP.**Network allowlist is a second wall.** If the environment is`limited`\n\nto`api.front.com`\n\n, the process cannot reach GitHub even if a prompt leak or a mis-attached MCP tries.**Filesystem is not a mounted superuser disk.** It is an MCP. Server-side checks enforce folder ACL and verb (read / write / delete separately). An agent that \"can write\" still cannot delete unless`canDelete`\n\nis true. Unlimited filesystem access will wipe the disk — that is why this exists.**Folder grants are per agent.** An agent may be allowed to read another agent's folder without write.**Secrets are injected only for listed env/MCP/repo credentials.** Encrypted at rest. Even if the app DB is stolen, tokens stay in Google's secret system.**Approval gates are not honor-system.** The API refuses`PATCH status=done`\n\nfrom an agent session token when`approvalGate=true`\n\n.**Collaboration list is the only spawn path.** Plan agent may spawn listed helpers as subtasks. It cannot spawn an agent that is not on its list.**Prompt injection / leak assumption.** Design as if the model will try to use every tool it has. If it should not be able to do a thing, do not attach the tool, and block the network path.\n\nImplement this state machine exactly.\n\n```\nrequested\n  → provision container (cloud SDK session or local runner slot)\n  → inject env from Secret store (only listed keys)\n  → attach allowed MCP connections\n  → apply environment network policy\n  → clone each granted repo to mountPath using repo credential\n  → mount R2 filesystem MCP with that agent's folder ACLs\n  → inject foundational prompt + role prompt + skills\n  → status=running\n  → agent works (tool calls streamed to live viewer + activity feed)\n  → if inbox question: status=waiting-inbox; pause; on reply, resume with answer\n  → if task complete and not approval-gated: AgentOS MCP marks task done / review\n  → if git-write granted and work produced: commit, record sha\n  → cleanup\n  → destroy container\n  → status=destroyed\n```\n\nRules:\n\n- After destroy, nothing from the container remains except git commits and R2 writes that went through the MCP.\n- The next session must clone/pull again. No \"warm\" dirty workspace.\n- Failures still destroy the container. Persist logs and tool-call history on the Session row first.\n- For goals: after destroy, the orchestrator runs (see §10) and may enqueue the next specialist session.\n\nBecause sessions are ephemeral, there is no durable container disk.\n\n- Store blobs in Cloudflare R2.\n- Expose them only through an\n**R2 filesystem MCP**. - UI can list, open, edit, download, preview files (high-level file browser).\n- MCP tools (minimum):\n`fs.list`\n\n,`fs.read`\n\n,`fs.write`\n\n,`fs.delete`\n\n,`fs.mkdir`\n\n. - Every call is authorized server-side:\n\n```\nif !grant.canRead && op in (list, read) → deny\nif !grant.canWrite && op in (write, mkdir) → deny\nif !grant.canDelete && op == delete → deny\nif path is outside granted folder prefix → deny\n```\n\n- Do not give the agent a raw S3/R2 SDK or a FUSE mount that bypasses the MCP.\n- Per-agent home folder convention:\n`/agents/{agentSlug}/`\n\nplus any extra grants. - Shared goal folder:\n`/goals/{goalId}/`\n\ngranted read/write to agents on that goal (delete still explicit).\n\nEvery agent session is prompted as:\n\n**Foundational AgentOS prompt**(shared)** Role prompt**(per agent)** Runtime inputs**— current task/goal, attachments, allowed MCP list, allowed folder list, collaboration list\n\n```\nYou are running inside AgentOS.\n\nYou have only the tools, MCPs, repos, environment variables, and filesystem\nfolders listed in your session manifest. If a tool is not listed, you cannot\nuse it and you must not try to. Do not ask for more access. Do not attempt\nto reach hosts outside your network policy.\n\nThe container you are in will be destroyed at the end of this session.\nPersist work by (a) committing to a granted repo if you have git-write, or\n(b) writing files through the filesystem MCP. Do not assume a local disk\nsurvives.\n\nWhen you need a human decision or you are stuck, use the Inbox MCP.\nDo not message the human for routine progress. They are not watching.\nWrite notable progress to the task activity log.\n\nYour job is the role prompt below. Do that job, then finish. Use the\nAgentOS MCP to update the task. If this task has an approval gate, you\nmust NOT mark it done — leave it in review and inbox the human.\n\nYou may spawn a collaborator only if they appear on your collaboration list.\nSpawn them as a subtask with a tight brief.\n\nLeast privilege is a safety rule, not a suggestion.\n```\n\n**plan**\n\n```\nYou are a plan agent. You have one job: turn an approved specification\ninto a concrete, ordered implementation plan. Write the plan onto the\ntask (and as a file attachment). Then finish the task. You do not\nimplement. You do not open unrelated tools.\n```\n\n**spec**\n\n```\nYou are a spec agent. Produce a detailed specification for the requested\nfeature. Attach the spec file. Refine it if the human replies. You cannot\nmark this task done — it is approval-gated. Inbox the human when the spec\nis ready for review.\n```\n\n**senior-dev**\n\n```\nYou are a senior developer. Implement the assigned work, or apply review\nfixes, in the granted repo. Follow the plan if one is attached. Commit\nwhen done. Run available tests. Inbox the human only if you are blocked.\n```\n\n**implementation-plan-executioner**\n\n```\nYou implement the code according to the attached implementation plan.\nDo not re-litigate the plan. Commit. Leave notes in activity.\n```\n\n**review-coordinator**\n\n```\nYou are a review coordinator. Spawn the listed review specialists\n(feasibility, scope-guardian, coherence for plans; the code-review\nspecialists for implementation). Each writes a report. You consolidate\ninto must-fix and should-fix. Attach the consolidated report. Do not\nimplement fixes yourself.\n```\n\n**feasibility** / **scope-guardian** / **coherence**\n\n```\nYou review the attached plan only through your lens\n(feasibility / scope / coherence). Write a report. Finish.\n```\n\n**librarian**\n\n```\nYou update the internal wiki (filesystem folder you are granted) to\nreflect how the codebase actually works after this change. Do not\nchange product code.\n```\n\n**customer-support**\n\n```\nYou handle inbound customer support. You have the support MCP (e.g. Front)\nonly. Analyze the conversation. Assign the correct human rep or account\nexecutive. You do not have Gmail. You do not have GitHub. You must not\nexfiltrate or request codebase information.\n```\n\n**diagnostic**\n\n```\nYou diagnose a bug. You have the repo and the customer-support chat.\nProduce a cause report. Do not implement until a human approves and a\nfollow-up implementation chain is started.\n```\n\n**linkedin-content**\n\n```\nYou produce the scheduled LinkedIn content. Use only the MCPs and folders\nyou were granted. Inbox if you need a human approval before posting, if\nposting is even in your tool list.\n```\n\n**default**\n\n```\nYou are the default AgentOS agent. Do the assigned task with the tools\nyou have. Finish or inbox if stuck.\n```\n\nOrchestrator is **not** a user-facing chat agent. It is control-plane code that runs after each goal session (see §10). It may call a model to choose the next specialist; that call still uses a tight reconstructed prompt:\n\n```\nYou are the AgentOS goal orchestrator. Read the progress log, the\ndefinition of done, and the last session summary. Choose the next\nspecialist agent from the allowed list (or declare the goal complete\nif every DoD checkbox is satisfied, or stop if stuck/spend/time rails\ntrip). Output a structured decision. Do not do the specialist's work.\n```\n\nColumns: **todo → doing → review → done**.\n\nA task is \"to do, doing, review, done.\" Per subject of the task, an agent starts working on it.\n\n- name\n- description\n- attachments\n- assign an agent (e.g. senior-dev)\n- run: immediately | schedule a datetime | recurring (cron; example: every Monday of the month, summarize inbox)\n- optional: start from a template\n\nA step can be marked `approvalGate: true`\n\n. Then:\n\n- Agent work can move the card to\n`review`\n\n. - AgentOS MCP / API reject any agent attempt to set\n`done`\n\n. - Human must manually put it on\n`done`\n\n. - Follow-up tasks stay blocked until that happens.\n\nUsed for: spec approval, and the final human PR/deploy review.\n\nA template is a chain of follow-up tasks. Each step names an agent and a prompt. Completing step N (status `done`\n\n) enqueues step N+1 (`todo`\n\n→ runner picks it up).\n\nAgents write details into the task activity / inbox. The UI shows this next to the card.\n\nShip this as the built-in template `compound-engineer-workflow`\n\n. He described it as a ~3-hour fully managed feature build; a concrete run was spawned 15:00, done 21:00 (~5–6 hours), PR ready the next day. 99% of the time it works because **E2E testing is implemented inside the workflow**. Include an E2E step in implementation and in the post-bugfix chain.\n\nTemplate variables: at least `branchName`\n\n(and whatever the feature title/spec needs).\n\n| # | Step | Assignee | Approval gate | Notes |\n|---|---|---|---|---|\n| 1 | Write a spec | `spec` |\nyes |\nAgent produces a detailed spec, attaches the spec file, may refine via inbox. Human reads, approves, marks `done` . Next step cannot start before that. |\n| 2 | Plan | `plan` |\nno (but tells human to review via inbox/activity) | One job: spec → concrete ordered plan. Writes details in activity/inbox. |\n| 3 | Plan review | `review-coordinator` |\nno | Coordinator spawns four review agents: he named feasibility, scope-guardian, coherence — implement those three plus a fourth plan-review specialist (`plan-risk` or a second coherence/feasibility pass; he said \"four different review agents\" and named three). Each writes a report. Coordinator consolidates must-fix / should-fix. |\n| 4 | Revise plan | `plan` |\nno | Gets the plan from step 2 and the review from step 3; adjusts. |\n| 5 | Implementation | `implementation-plan-executioner` |\nno | Implements the code. E2E tests run as part of this work. |\n| 6 | Code review | `review-coordinator` |\nno | Reviews the code; how it should be fixed. Consolidated must-fix / should-fix. |\n| 7 | Apply review fixes | `senior-dev` |\nno | Applies the review fixes. |\n| 8 | Librarian | `librarian` |\nno | Updates the internal wiki based on how the codebase works. |\n| 9 | Human review of deployment / PR | `human` |\nyes |\nHuman checks out the PR, reviews, merges. |\n\nAfter a **bug-report trigger** that the human approved, the chain is: implement → plan → plan review → fix → E2E test, then human reviews and merges. Reuse the same agents; do not invent a second product.\n\nFor unstructured, open-ended work (he also called this the gauntlet loop).\n\nDaily workflow he described: write a spec in the morning, throw it into the goal system, it writes a Definition of Done, he approves the DoD, it runs 5–6 hours, end of day he gets a PR, reviews, merges.\n\n- Human creates a Goal with a spec (or a task-like brief).\n- System (or a planning call) drafts\n`definitionOfDone[]`\n\ncheckboxes from the spec sheet if the human did not write them. - Human approves the DoD. Do not start the loop without that approval.\n- Orchestrator picks the first specialist (senior-dev, plan, etc.) and spawns a session.\n- Session runs the lifecycle in §6. Shared inbox + shared filesystem + append-only progress log.\n**At the end of every session**, the orchestrator:- reads progress logs\n- reads definitions of done\n- reads what was implemented\n- marks DoD checkboxes that are satisfied\n- if all checkboxes satisfied → Goal\n`completed`\n\n- else if safety rail trips → stop\n- else spawn the next specialist\n\n- Repeat until done or stopped.\n\n| Rail | Behavior |\n|---|---|\n| Spend cap | Stop spawning when estimated/actual spend ≥ cap. UX should make a cap hard to forget. |\n| Maximum time | Stop when wall-clock since start ≥ maxDuration. |\n| Stuck detection | If the same iteration happens 19 times (same specialist + same unresolved DoD + no meaningful progress-log delta), orchestrator stops. |\n\nA goal without a spend cap is allowed only if the human explicitly confirms. Default to requiring a cap.\n\n- Progress log (append-only, visible in UI)\n- Shared inbox thread for the goal\n- Shared R2 folder\n\nInbox is an MCP agents call. It is also a UI surface.\n\nCapabilities:\n\n- Send a text message to the human\n- Send a multiple-choice question with radio buttons (same idea as Claude's ask-user-question)\n- Human replies in the UI; the reply is sent back into the waiting session and the session resumes\n- Chat / communicate across multiple turns\n- Agents message\n**only when stuck or they need a decision**— not for chatter\n\nPWA:\n\n- Mobile-responsive\n- Installable\n- Web push when something is done or needs help\n\nDo not build a second messaging product. Inbox is the interrupt channel for tasks, goals, and triggers.\n\n- Global activity feed of agent actions / inbox / task transitions.\n- Live session viewer: watch tools being called in real time while a session is\n`running`\n\n. - Persist tool-call logs on the Session so a finished run can be replayed.\n\n- Each Trigger has a public URL + webhook secret.\n- On valid POST: create a Task (or Goal job) assigned to the trigger's scoped agent, enqueue a session immediately.\n- Agent receives a sanitized payload (do not dump raw headers/secrets into the prompt).\n\nExamples to ship as seed config (not hardcoded business logic):\n\n**Support inbound**— payload is a conversation. Agent:`customer-support`\n\n. Tools: Front (or configured support MCP) only. Output: assignment to a support rep or AE. This pattern fired 600 times for him.**Bug report**— support submits a bug in the backend. Agent:`diagnostic`\n\nwith repo**and** support chat. Output: cause report. Human approval then starts the fix chain with E2E.\n\n- Named automations with cron + timezone + agent + task body or template.\n- Examples: weekly LinkedIn content; first-of-the-month LinkedIn content bot.\n- Scheduler creates a Task and a Session on fire.\n- Recurring Tasks (§9.2) use the same scheduler.\n\nOriginally everything ran on Claude managed agents API — expensive (anecdote: ~$500/day). He added a $10 Hetzner VM running Claude with `--dangerously-skip-permissions`\n\nand Grok in yolo mode.\n\nRouting rules to implement:\n\n| Signal | Where it runs |\n|---|---|\nControl plane `busy` (cloud queue saturated / cost policy) |\nprefer `local` if a local runner is healthy |\n| Otherwise | `cloud` is fine |\nGoal.runnerPreference = `local` |\nonly local runners |\nAgent.runnerPreference = `cloud` (planners) |\nClaude cloud |\nAgent.runnerPreference = `local` (workers) |\nGrok 4.6 / local Claude, fast |\n| Per-goal override | wins over default |\n\nImplement a `Runner`\n\ninterface:\n\n```\nprovision(session) → handle\nstreamToolCalls(handle) → events\ninjectReply(handle, inboxAnswer)\ndestroy(handle)\n```\n\nTwo backends: `CloudClaudeRunner`\n\n, `LocalVmRunner`\n\n. Local VM is a worker process that pulls jobs; it is not the control plane.\n\nDo not build \"his own future runner\" beyond this interface. He said he is starting to work out his own stuff — that is an unknown, not a spec.\n\nEvery project has an AgentOS YAML file that mimics the online UI: agents, skills, templates, MCP connections, repo access, prompts.\n\nExample shape (illustrative, reconstructed):\n\n```\n# agentos.yml\nproject: acme\nagents:\n  spec:\n    title: Spec agent\n    model: claude-opus-4\n    skills: [inbox]\n    mcp: [agentos, inbox, r2-fs]\n    repos: []\n    environment: limited-none\n    runner: cloud\n    prompt: |   # reconstructed — not his verbatim file\n      You are a spec agent. ...\n  plan:\n    title: Plan agent\n    model: claude-opus-4\n    skills: [plan-mode]\n    mcp: [agentos, inbox, r2-fs]\n    repos: []\n    collaboration: []\n    environment: limited-none\n    runner: cloud\n    prompt: |\n      You are a plan agent. ...\n  senior-dev:\n    title: Senior dev\n    model: grok-4.6\n    skills: []\n    mcp: [agentos, inbox, r2-fs, github]\n    repos:\n      - id: app\n        mount: /workspace/app\n        permissions: git-write\n    environment: open\n    runner: local\n    prompt: |\n      You are a senior developer. ...\nskills:\n  plan-mode:\n    kind: prompt\n    body: |\n      /plan — enter plan mode and produce an ordered implementation plan.\ntemplates:\n  - id: compound-engineer-workflow\n    variables: [branchName]\n    steps:\n      - { name: Write a spec, agent: spec, approvalGate: true }\n      - { name: Plan, agent: plan }\n      - { name: Plan review, agent: review-coordinator }\n      - { name: Revise plan, agent: plan }\n      - { name: Implementation, agent: implementation-plan-executioner }\n      - { name: Code review, agent: review-coordinator }\n      - { name: Apply review fixes, agent: senior-dev }\n      - { name: Librarian, agent: librarian }\n      - { name: Human PR review, agent: human, approvalGate: true }\n```\n\nCLI (he named these):\n\n| Command | Behavior |\n|---|---|\n`agentos help` |\nusage |\n`agentos push` |\nsync local YAML → control plane |\n`agentos pull` |\nsync control plane → local YAML |\n`agentos project create` |\ncreate a project |\n`agentos goal create` |\ncreate a goal from details (used after local Claude brainstorming) |\n`agentos task create` |\ncreate a task; CLI knows which agents to apply from YAML/template |\n`agentos agent update` / create |\nadjust agents |\n`agentos skill create` |\ncreate a new skill |\n\nMost of the time he chats with Claude locally while brainstorming. When done, he tells the CLI to create a goal or session on AgentOS with the details. The CLI creates the task/goal and applies the right agents. Templates have variables (branch name, etc.); Claude Code implements the template steps locally as a convenience, but AgentOS is the system of record once created.\n\nAuth: CLI uses a personal token against the control-plane API.\n\nSingle app, sidebar sections — \"all the different aspects\":\n\n**Agents**— list (default, senior-dev, plan, …). Detail: name, title, model, foundational + role prompt, skills, MCPs, repos, filesystem grants, collaboration list, environment, runner preference.**Skills**— list/create; prompt or file (e.g. Python script).** Files**— R2 browser: open, edit, download, preview.** MCPs**— connections, credential refs, which agents use them.** Repos**— name, mount path, credential ref, how it connects to the GitHub MCP.** Environment variables**— inject into sessions; values come from the secret store.** Tasks**— Kanban; create form; template picker; activity on the card.** Goals**— DoD checkboxes, progress log, spend/time/stuck, runner preference.** Inbox**— thread, radio-button questions, reply. This view is also the PWA home.** Triggers**— webhook URL, secret rotation, target agent, recent fires.** Automations**— cron list.** Sessions**— live viewer + history of tool calls.** Activity**— global feed.\n\nMobile: inbox + push is the required responsive surface. The rest can be desktop-first.\n\nPostgres-oriented. Adjust names, not relationships.\n\n```\n// types — implement as Prisma/Drizzle models\n\ntype Project = {\n  id: string\n  name: string\n  slug: string\n  yaml: string\n  createdAt: Date\n}\n\ntype Agent = {\n  id: string\n  projectId: string\n  name: string\n  title: string\n  model: string\n  foundationalPrompt: string\n  rolePrompt: string\n  skillIds: string[]\n  mcpConnectionIds: string[]\n  repoAccess: { repoId: string; mountPath: string; permissions: \"git-read\" | \"git-write\" }[]\n  filesystemGrants: { folderPath: string; canRead: boolean; canWrite: boolean; canDelete: boolean }[]\n  collaborationList: string[]\n  environmentId: string\n  runnerPreference: \"cloud\" | \"local\" | \"inherit\"\n  inboxAccess: boolean\n}\n\ntype Environment = {\n  id: string\n  projectId: string\n  name: string\n  networking: \"open\" | \"limited\"\n  allowedHosts: string[]\n}\n\ntype Skill = {\n  id: string\n  projectId: string\n  name: string\n  slug: string\n  kind: \"prompt\" | \"file\"\n  body?: string\n  filePath?: string\n}\n\ntype McpConnection = {\n  id: string\n  projectId: string\n  name: string\n  config: unknown\n  credentialSecretId?: string\n}\n\ntype Repo = {\n  id: string\n  projectId: string\n  name: string\n  remoteUrl: string\n  mountPath: string\n  credentialSecretId: string\n  defaultBranch: string\n}\n\ntype SecretRef = {\n  id: string\n  projectId: string\n  name: string\n  providerRef: string\n  purpose: \"mcp\" | \"repo\" | \"env\" | \"webhook\"\n}\n\ntype Task = {\n  id: string\n  projectId: string\n  name: string\n  description: string\n  status: \"todo\" | \"doing\" | \"review\" | \"done\"\n  assigneeType: \"agent\" | \"human\"\n  assigneeAgentId?: string\n  attachmentIds: string[]\n  approvalGate: boolean\n  chainId?: string\n  chainIndex?: number\n  scheduleKind: \"now\" | \"at\" | \"cron\"\n  runAt?: Date\n  cron?: string\n  timezone?: string\n  templateId?: string\n}\n\ntype TaskTemplate = {\n  id: string\n  projectId: string\n  name: string\n  description: string\n  variables: string[]\n  steps: TemplateStep[]\n}\n\ntype TemplateStep = {\n  name: string\n  agentName: string // \"human\" for the final PR step\n  prompt: string\n  approvalGate: boolean\n}\n\ntype Goal = {\n  id: string\n  projectId: string\n  title: string\n  spec: string\n  definitionOfDone: { id: string; text: string; done: boolean }[]\n  dodApproved: boolean\n  status: \"active\" | \"paused\" | \"completed\" | \"stopped-spend\" | \"stopped-time\" | \"stopped-stuck\"\n  spendCapUsd?: number\n  spendUsd: number\n  maxDurationMinutes?: number\n  stuckThreshold: number // default 19\n  runnerPreference: \"cloud\" | \"local\" | \"auto\"\n  progressLog: string\n}\n\ntype Trigger = {\n  id: string\n  projectId: string\n  name: string\n  webhookSecretId: string\n  agentId: string\n  jobPrompt: string\n}\n\ntype Automation = {\n  id: string\n  projectId: string\n  name: string\n  cron: string\n  timezone: string\n  agentId: string\n  taskTemplateId?: string\n  taskBody?: string\n}\n\ntype InboxMessage = {\n  id: string\n  from: \"agent\" | \"human\"\n  agentId?: string\n  sessionId?: string\n  taskId?: string\n  goalId?: string\n  kind: \"text\" | \"multiple-choice\"\n  body: string\n  choices?: { id: string; label: string }[]\n  selectedChoiceId?: string\n  status: \"open\" | \"answered\" | \"closed\"\n}\n\ntype Session = {\n  id: string\n  agentId: string\n  taskId?: string\n  goalId?: string\n  runner: \"cloud\" | \"local\"\n  status: \"starting\" | \"running\" | \"waiting-inbox\" | \"committing\" | \"destroyed\" | \"failed\"\n  runtimeHandle?: string\n  toolCallLog: unknown[]\n  startedAt: Date\n  endedAt?: Date\n  costUsd?: number\n  commitShas: string[]\n}\n\ntype FileObject = {\n  id: string\n  projectId: string\n  path: string\n  bucketKey: string\n  mime: string\n  size: number\n}\n```\n\nSingle-operator API. Session-cookie for the UI; bearer token for the CLI and runners.\n\n```\nPOST   /projects\nGET    /projects/:id\nPUT    /projects/:id/yaml          # push\nGET    /projects/:id/yaml          # pull\n\nGET    /projects/:id/agents\nPUT    /projects/:id/agents/:name\nGET    /projects/:id/skills\nPOST   /projects/:id/skills\n\nGET    /projects/:id/files?path=\nGET    /projects/:id/files/content?path=\nPUT    /projects/:id/files/content\nDELETE /projects/:id/files/content  # UI only if operator; agents use MCP\n\nPOST   /projects/:id/tasks\nPATCH  /projects/:id/tasks/:id      # human may set done on gated tasks\nPOST   /projects/:id/tasks/:id/run\nPOST   /projects/:id/templates/:id/instantiate\n\nPOST   /projects/:id/goals\nPOST   /projects/:id/goals/:id/approve-dod\nPOST   /projects/:id/goals/:id/pause\n\nGET    /inbox\nPOST   /inbox/:id/reply             # resumes session\n\nGET    /sessions\nGET    /sessions/:id                # includes toolCallLog; SSE at /sessions/:id/live\n\nPOST   /hooks/:triggerId            # public, HMAC/secret\nGET    /projects/:id/triggers\nGET    /projects/:id/automations\n\n# Runner / MCP internal (not public)\nPOST   /internal/sessions/:id/tool-events\nPOST   /internal/sessions/:id/cost\n```\n\nAgentOS MCP maps to the same task/goal/spawn endpoints but is authorized with a **session-scoped token** that is limited to that agent’s ACL. Approval-gate `done`\n\nis rejected for that token.\n\nInbox MCP: `inbox.send`\n\n, `inbox.ask`\n\n(choices required), `inbox.read`\n\n.\n\nFilesystem MCP: see §7.\n\nDo not start phase N+1 until phase N acceptance tests pass.\n\n- TS service, Postgres, single-user auth, empty React shell with the sidebar routes (can 404).\n`agentos help`\n\nstub CLI.\n\n- Project + Agent + Task CRUD.\n- Cloud runner via Claude Agent SDK: create session, attach a hardcoded AgentOS MCP + Inbox MCP, run, destroy.\n- Kanban UI: create task, assign default agent, run now, watch status go todo → doing → done.\n- Session record with basic tool-call log.\n- Foundational + default role prompt (reconstructed).\n**Done when:** you can create a task, an agent session starts, the agent updates the task through the MCP, the container/session is destroyed, the card is`done`\n\n.\n\n- Environment network policy (\n`open`\n\n|`limited`\n\n+ allowlist) enforced at the runner proxy. - Per-agent MCP / repo / env grants.\n- R2 + filesystem MCP with server-side read/write/delete ACLs and per-agent folders.\n- Secret refs via Google Secret Manager (or Cloud KMS). Inject at session start only.\n- UI file browser (open/edit/download/preview).\n**Done when:** a support-style agent with only a fake Front MCP cannot call GitHub or read another agent's folder; a plan agent cannot use a GitHub connection that exists on the project but is not granted to it; delete is denied without`canDelete`\n\n.\n\n- TaskTemplate + instantiate.\n- Approval gates enforced in API + MCP.\n- Follow-up chain scheduler.\n- Seed\n`compound-engineer-workflow`\n\nwith all 9 steps and the four plan-review specialists. - Schedule-at and recurring cron on tasks.\n**Done when:** instantiating the feature template creates 9 cards; step 2 does not start until a human marks step 1`done`\n\n; an agent token cannot mark step 1`done`\n\n.\n\n- Goal + DoD generate/approve + progress log.\n- Orchestrator after every session.\n- Spend cap, max time, stuck-at-19.\n- Per-goal runner preference.\n**Done when:** a small goal with a 2-item DoD completes by spawning at least two specialist sessions; a goal with stuckThreshold=2 stops after two no-progress iterations; a spend cap of $0.00 refuses to spawn.\n\n- Webhook receiver + secret.\n- Seed support-inbound and bug-report trigger shapes.\n- Bug-report approval → fix chain (implement → plan → plan review → fix → E2E).\n- Named cron automations (LinkedIn examples as fixtures).\n**Done when:** a signed webhook creates a task and session for the scoped agent; a cron entry fires once in a test clock.\n\n`agentos.yml`\n\nschema matching UI.`push`\n\n/`pull`\n\n/`project create`\n\n/`goal create`\n\n/`task create`\n\n/ agent update /`skill create`\n\n.**Done when:** a YAML file pushed from CLI produces the same agents+template you can see in the UI, and`pull`\n\nis a no-op after`push`\n\n.\n\n- Inbox as installable PWA, web push on \"needs help\" and \"done\".\n- Multiple-choice radio questions.\n- Live session viewer (SSE/websocket of tool calls).\n- Activity feed.\n- Local runner worker + routing (planners cloud, workers local/Grok).\n**Done when:** an agent`inbox.ask`\n\nshows radio buttons on a phone-sized viewport; answering resumes the session; a planner session is routed cloud and a worker session can be forced local.\n\nAutomated tests an implementing agent must add:\n\n**Session destroy:** after a successful run, no runner handle remains; a second task reclones the repo rather than reusing a dirty workspace.**ACL filesystem:** write without`canWrite`\n\nfails; delete without`canDelete`\n\nfails; path escape (`../`\n\n) fails.**ACL MCP:** agent without GitHub connection cannot invoke GitHub tools even if the project has one.**Network wall:** limited environment to`api.front.com`\n\ncannot open`github.com`\n\n.**Approval gate:** agent session token`PATCH done`\n\n→ 403; human token → 200; follow-up still`todo`\n\nuntil then.**Template chain:** 9 tasks, order respected, variables (branchName) interpolated into prompts.**Inbox resume:**`waiting-inbox`\n\n+ reply → session continues with the answer in context.**Multiple-choice:** message with`choices`\n\nrenders and stores`selectedChoiceId`\n\n.**Goal rails:** spend / time / 19-iteration stuck all set`stopped-*`\n\nand do not spawn.**DoD approval:** goal will not spawn before`dodApproved`\n\n.**Webhook auth:** bad secret → 401; good secret → task+session.**YAML round-trip:** push then pull is identity (modulo whitespace).**Least-privilege support agent:** fixture agent with Front only; test asserts GitHub, Gmail, and repo clone are absent from the session manifest.**Orchestrator spawn list:** cannot spawn an agent not on the collaboration / project allow list.\n\nManual / demo script (human):\n\n- Morning: write a spec, create a goal, approve DoD, leave.\n- Evening: PR exists or inbox asked a real question.\n- Trigger: POST a fake support payload, see an assignment note.\n- Phone: receive a push, answer a radio question.\n\n| Item | Status |\n|---|---|\n| His exact foundational and role prompt files | Unknown. Use reconstructed contracts in §8 and label them. |\n| Exact Google secret product name | He forgot. Use Secret Manager; Cloud KMS is acceptable if you need envelope encryption. |\n| His own future custom runner | Mentioned as in progress. Not specified. Use SDK + local VM interface only. |\n| Exact fourth plan-review agent name | He said four reviewers and named feasibility, scope-guardian, coherence. Add a fourth `plan-risk` specialist with a reconstructed \"risk / missing-test\" lens, and label it reconstructed. |\n| Exact E2E harness | \"E2E testing is implemented inside the workflow\" — require the implementation step (and bugfix chain) to run the repo's existing E2E if present; do not invent a product-wide test framework. |\n| Front / Ahrefs / Gmail / MongoDB | Examples of MCP/env grants. Integrate as configurable connections, not hardcoded vendors in the core. |\n`fight-for` game repo |\nExample mount only. |\n| Cost figures ($500/day, $1000 night, $10 VM) | Anecdotes that motivate runner routing and spend caps, not SLOs. |\n| Open-sourced agents/skills/prompts | Offered, not provided. Do not block on them. |\n| Deep-dive / code-walk videos | Future content, not a spec. |\n| Multi-user / teams / billing | Not described. Single operator. |\nExact CLI binary name beyond `agentos` |\nUse `agentos` . |\n| Exact YAML filename | He said \"an AgentOS file.\" Use `agentos.yml` at project root. |\n\n- Implement in the phase order in §21.\n- Least privilege is not a phase-2 nice-to-have you skip; Phase 1 may hardcode grants, Phase 2 must enforce them.\n- Do not add Slack, email-the-user, or extra chat products. Inbox is the human channel.\n- Do not persist a container to \"save time.\"\n- Do not give agents raw cloud credentials.\n- Do not copy this document's transcript-of-origin story into the product UI.\n- Every reconstructed prompt file must start with a comment:\n`Reconstructed from Danny Postma's AgentOS talk — not his verbatim prompt.`\n\n- If a choice is not specified here, pick the simplest thing that preserves isolation and the session lifecycle.\n\nYou define agents (plan, senior-dev, …) with only the tools they need. You file a task or a goal. AgentOS starts a throwaway container, clones the allowed repo, injects allowed secrets, and lets that agent work. When it needs you, you get an inbox push. When it is done, the container is gone and a commit or a PR is left behind. Recurring jobs and webhooks use the same path. A feature template runs spec (you approve) → plan → multi-agent plan review → revise → implement with E2E → code review → fixes → wiki → you merge. A goal loop keeps dispatching specialists until the definition of done is checked, or spend/time/stuck rails stop it.", "url": "https://wpnews.pro/news/agentos-blueprint-reconstructed-from-danny-postma-s-agent-sdk-talk-so-an-agent", "canonical_source": "https://gist.github.com/iannuttall/8152098b5ce8e6c1a7499ee561ed93f4", "published_at": "2026-08-14 12:10:25+00:00", "updated_at": "2026-08-14 13:20:52.096790+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools", "artificial-intelligence"], "entities": ["Danny Postma", "Anthropic", "Claude Agent SDK", "Cloudflare R2", "Google", "Hetzner", "Grok"], "alternates": {"html": "https://wpnews.pro/news/agentos-blueprint-reconstructed-from-danny-postma-s-agent-sdk-talk-so-an-agent", "markdown": "https://wpnews.pro/news/agentos-blueprint-reconstructed-from-danny-postma-s-agent-sdk-talk-so-an-agent.md", "text": "https://wpnews.pro/news/agentos-blueprint-reconstructed-from-danny-postma-s-agent-sdk-talk-so-an-agent.txt", "jsonld": "https://wpnews.pro/news/agentos-blueprint-reconstructed-from-danny-postma-s-agent-sdk-talk-so-an-agent.jsonld"}}