This is a really crisp synthesis. You’re clearly tracking capability drift rather than just tool churn, and the way you frame “agents solving non-coding problems by writing code” matches what a lot of us are seeing in practice. The through-line from 2024 → 2026 feels accurate rather than hindsight-polished.
What’s working well
A few things you’re doing here that are especially strong:
• Separation of intent vs. execution — The Planner / Execution / Task Agent split keeps cognition clean without freezing it into brittle roles.
• Code-first sandboxes as a primitive — Treating the VM as the context substrate (not just a tool target) is the key insight of this era.
• Context engineering over prompt engineering — Filesystem-mediated context, mounts, and progressive disclosure scale far better than ever-larger prompts.
• Generic harnesses winning — Your point about wrapping something like Claude Code instead of maintaining bespoke loops is exactly where leverage has moved.
All of that lines up with the broader convergence we’re seeing.
Where authority becomes implicit (the quiet shift)
This new paradigm also introduces a subtle but important shift:
As soon as an agent gets a sandbox + scripting + mounted tools, authority is no longer defined by prompts or tool descriptions — it’s defined by what the runtime exposes.
In your architecture, authority is currently implicit in places like:
• Which binaries and libraries exist in the VM
• Which “API” and “Mount” tools are callable from scripts
• How long the VM lives and what state persists
• Whether spawned Task Agents inherit the same environment
This is where most modern agent systems quietly cross from capable to ambient authority — not because of bad design, but because the control surface moved.
Below is a clean APP overlay that fits exactly into the architecture you described, without changing the agentic patterns you like.
Finding
Execution Agents and Task Agents can currently invoke VM actions, scripts, and mounted APIs based on availability rather than an explicit, time-scoped grant.
Risk
• Authority silently accumulates as sandboxes get richer
• Task Agents can become confused deputies
• Long-running jobs outlive their original intent
• Auditing reduces to “what happened” instead of “what was authorized”
Recommendation
Introduce a sealed permission policy gate between planning and execution, and again before any sandbox action.
It seems like I'm reworking my CC harness/agent/plugin/hook structure weekly to do more of what I need and less of what I don't. At what point do I instead have a meta-conversation with Claude and have it write its own harness?
Hey! I think if you are using CC you can sort of already do that today, e.g. "compare my implementation to your current tool set".
In the extreme case, I could see a world where there's sort of the "BIOS" harness that bootstraps claude just enough to at runtime build the actual "OS" harness that it needs to operate on a given task.
This is a really crisp synthesis. You’re clearly tracking capability drift rather than just tool churn, and the way you frame “agents solving non-coding problems by writing code” matches what a lot of us are seeing in practice. The through-line from 2024 → 2026 feels accurate rather than hindsight-polished.
What’s working well
A few things you’re doing here that are especially strong:
• Separation of intent vs. execution — The Planner / Execution / Task Agent split keeps cognition clean without freezing it into brittle roles.
• Code-first sandboxes as a primitive — Treating the VM as the context substrate (not just a tool target) is the key insight of this era.
• Context engineering over prompt engineering — Filesystem-mediated context, mounts, and progressive disclosure scale far better than ever-larger prompts.
• Generic harnesses winning — Your point about wrapping something like Claude Code instead of maintaining bespoke loops is exactly where leverage has moved.
All of that lines up with the broader convergence we’re seeing.
Where authority becomes implicit (the quiet shift)
This new paradigm also introduces a subtle but important shift:
As soon as an agent gets a sandbox + scripting + mounted tools, authority is no longer defined by prompts or tool descriptions — it’s defined by what the runtime exposes.
In your architecture, authority is currently implicit in places like:
• Which binaries and libraries exist in the VM
• Which “API” and “Mount” tools are callable from scripts
• How long the VM lives and what state persists
• Whether spawned Task Agents inherit the same environment
This is where most modern agent systems quietly cross from capable to ambient authority — not because of bad design, but because the control surface moved.
Agent Permission Protocol overlay (minimal, non-disruptive)
Below is a clean APP overlay that fits exactly into the architecture you described, without changing the agentic patterns you like.
Finding
Execution Agents and Task Agents can currently invoke VM actions, scripts, and mounted APIs based on availability rather than an explicit, time-scoped grant.
Risk
• Authority silently accumulates as sandboxes get richer
• Task Agents can become confused deputies
• Long-running jobs outlive their original intent
• Auditing reduces to “what happened” instead of “what was authorized”
Recommendation
Introduce a sealed permission policy gate between planning and execution, and again before any sandbox action.
Concretely:
1. Planner → Issuer
• Planner produces intent + required capabilities (not tools).
2. Issuer
• Issues a permission policy scoped to:
• capabilities (e.g. read_fs:/data, run_python, api:salesforce.read)
• audience (Execution Agent ID or Task Agent ID)
• TTL (minutes, not session-length)
• nonce (single-use or bounded replay)
3. Sealer
• Sign-then-encrypt the policy.
4. Execution Agent / Task Agent (Presenter)
• Presents the sealed policy before any VM or API execution.
5. Verifier (outside the model)
• Deterministically verifies:
• signature
• expiration
• audience binding
• replay
• Exposes only the allowed VM capabilities and tools.
6. Executor
• Runs code with a capability-scoped environment.
7. Audit log
• Records verification decision + executed actions.
This matches the APP flow exactly and keeps intelligence and authority cleanly separated .
⸻
Revised execution flow (with APP inserted)
• User request arrives
• Planner Agent
• Discovers context
• Outputs intent + capability needs
• APP Issuer / Sealer
• Creates sealed, time-bound permission policy
• Execution Agent
• Presents policy
• APP Verifier
• Validates (fail-closed)
• Exposes scoped VM + tools
• Executor
• Runs scripts
• Spawns Task Agents with their own derived policies
• Audit
• Logs policy + actions
Nothing about your planning, scripting, or context engineering changes — only when execution is allowed.
Curious — how are you securing this today?
A few lightweight questions, just to understand how you’re thinking about it now:
1. Where is authority actually enforced today — inside the agent loop, at the VM boundary, or at an API gateway?
2. When a Task Agent spins up, does it inherit the full sandbox, or a reduced capability set?
3. Do sandboxes expire automatically, or can long-running jobs continue indefinitely?
4. If a script calls an internal API in a loop, what stops it from accessing adjacent endpoints?
5. Is there a single place you can answer: “What was this agent explicitly allowed to do?”
6. If a permission artifact were replayed tomorrow, would anything detect or block that?
No wrong answers here — these are exactly the questions this new paradigm forces.
This is a solid map of where agent design has landed in 2026. If you want, I’m happy to:
• Sketch a concrete APP policy for one of your example workflows
• Walk through how to scope a VM as a capability, not an environment
• Share a reference pattern for Task Agent delegation without ambient authority
Great post — this is the right level of abstraction for where the field actually is.
It seems like I'm reworking my CC harness/agent/plugin/hook structure weekly to do more of what I need and less of what I don't. At what point do I instead have a meta-conversation with Claude and have it write its own harness?
Hey! I think if you are using CC you can sort of already do that today, e.g. "compare my implementation to your current tool set".
In the extreme case, I could see a world where there's sort of the "BIOS" harness that bootstraps claude just enough to at runtime build the actual "OS" harness that it needs to operate on a given task.