Agent Harness vs. Framework vs. Runtime vs. Control Plane

Frameworks build agents and harnesses run them; Paperclip decides who works on what and who signs off. A coding runtime is a harness packaged for software work, and a control plane sits above all of them and keeps the record of the work itself.

That split matters when something goes wrong. An agent tries to force-push a branch. Another reaches for a file outside its workspace. A session ends halfway through a task whose next step belongs to someone else. Each layer can answer part of that, and none answers all of it.

What are the four layers?

• An agent framework gives you building blocks for agent logic: model and tool abstractions, agent loops and workflow primitives.
• An agent harness runs that loop as a working agent. It drives model and tool calls, manages context and state, applies approval policies and keeps a multistep task moving.
• A coding runtime such as Claude Code or Codex is a harness packaged for software work, with its own tools, permission system, sandbox and session store.
• A multi-agent control plane governs the work: which tasks exist, who owns each one, what it depends on, what it may spend and who must review it.

These are responsibilities, not exclusive product categories. LangChain’s documentation calls LangGraph an orchestration runtime, and many teams also use it as a framework. AWS runs its managed harness inside AgentCore Runtime. Claude Code is a harness, a runtime and a product at once.

The examples come from each vendor’s own documentation, linked at the end. The table describes documented responsibilities. It isn’t a security rating of any product.

Which layer can block a tool call, resume a run or keep ownership?

Harnesses and runtimes block tool calls, and each runtime resumes its own sessions. Paperclip keeps the task-owner record after a session ends. Paperclip can also gate calls to tools connected through Paperclip, and how much of the runtime’s own shell it restricts depends on how the agent runs.

What does an agent framework own?

LangChain describes LangGraph as an orchestration runtime with durable execution, streaming, human-in-the-loop and persistence. If you build your own agent, this is where you decide its shape.

A framework can give you real controls. You can interrupt a graph before a risky step, or checkpoint its state so a failed run resumes where it stopped. Those controls exist because you wired them into your own graph. They do nothing for an agent you didn’t build with that framework, such as a coding session a colleague started.

What is an agent harness?

Microsoft’s Agent Framework documentation defines a harness as “the runtime scaffolding that turns a language model into an agent that can perform work.” It drives model and tool calls, manages conversation state and context, applies approval policies and keeps the agent moving through a multistep task.

AWS uses the word more broadly: the loop plus the infrastructure under it. Its AgentCore harness runs each session in an isolated microVM backed by AgentCore Runtime. That isolation belongs to AWS’s product, not to harnesses in general. LangChain’s Deep Agents is a third shape: planning, subagents, filesystem tools and context management on top of LangGraph.

Across all three, the harness is where per-step decisions happen: whether a tool call runs, what context the model sees and how a session continues.

What does a coding runtime own?

Claude Code and Codex ship a terminal or IDE surface, local tools, a permission system, a sandbox and a session store. Two of those matter most here.

Permissions. Claude Code evaluates permission rules “in order: deny, then ask, then allow,” and says rules “are enforced by Claude Code, not by the model.” A Bash rule matches the command text Claude writes, so it isn’t a security boundary around the program. For enforcement that doesn’t depend on command text, Claude Code has an OS-level sandbox. Codex offers --sandbox modes and an --ask-for-approval policy. Its --dangerously-bypass-approvals-and-sandbox flag runs commands without approvals or sandboxing.

Sessions. claude --resume and claude --continue reopen a Claude Code conversation. codex resume does the same for Codex. Each resumes from the runtime’s own records.

What does a multi-agent control plane own?

Paperclip describes itself as “the layer above all of that,” and is direct about the boundary: “It’s not the AI.” Agents run on the runtimes you connect through adapters, including Claude Code and Codex.

Paperclip governs the task. A Paperclip task has one owner, a status and blocked by links. While a blocker is unresolved, agents treat the task as not ready to start. An execution policy catches an agent’s attempt to mark work done and routes it to a reviewer or approver first. If the reviewer requests changes, the task goes back to the agent that did the work. Paperclip also tracks spend per agent.

Two Paperclip controls can stop something, and they’re easy to confuse. The execution policy gates task transitions, such as marking work done. It doesn’t see the commands an agent runs. Connector action permissions gate calls to tools connected through Paperclip: each action is Allowed, Ask first or Off. Neither one reviews the runtime’s own shell and file commands.

Those commands run inside the runtime, and what contains them depends on how Paperclip launches the agent. New Codex and Claude Code agents run on Paperclip Runner by default on macOS, or on Linux x64/ARM64 with glibc 2.39 or newer. Native Codex on the Runner runs in one mode only, Automatic (isolated), and Paperclip keeps its own workspace, network and environment restrictions around it. Agents on the Legacy runner use the runtime’s sandbox and the adapter’s permission settings instead. The Runner is still marked experimental, so check which runner each agent uses.

Approving a task and authorizing a tool call are different decisions. The first signs off a result. The second decides whether an agent may take one action at all.

One blocked command and one handoff, step by step

For example, let’s say you are a team lead running two coding agents on one feature, but the second agent’s work can’t start until the first one’s change is reviewed. Here’s how each layer handles four things that can go wrong.

The setup

• Paperclip runs two agents. The API engineer runs on Claude Code and the integration engineer on Codex. Both work in git worktrees.
• Task A, “Add pagination to the runs endpoint,” belongs to the API engineer and has a review stage.
• Task B, “Update the client SDK for paginated runs,” belongs to the integration engineer and is blocked by A.
• Your Claude Code settings include the deny rule Bash(git push --force *).

1. The agent tries a forbidden command. Midway through A, Claude Code proposes git push --force origin feature/pagination. If your deny rule is in force, Claude Code blocks it. Claude Code’s permission-mode docs say deny rules block in every mode, including when permission prompts are skipped. Paperclip does skip them, because no one is there to click approve. On the classic Claude Code adapter, dangerouslySkipPermissions defaults to true, and on the Runner, Claude uses its own acpxPermissionMode, which defaults to approve-all. Before you count on a rule, confirm it’s loaded for the way Paperclip launches that agent. Paperclip isn’t consulted about the command. It sees what the run outputs and what the agent reports afterward.

Three separate boundaries could stop a force push, and each checks something different:

• The deny rule matches the command text. The same push wrapped in a script may not match.
• The OS-level sandbox limits which files a command can write and which hosts it can reach. Your Git host has to be allowed for ordinary pushes, so the sandbox doesn’t stop a force push to it.
• Branch protection on your Git host decides whether the remote accepts a force push at all. If it isn’t configured, nothing on the remote side refuses it.

2. The session ends before the work is done. The run ends with A half finished. Claude Code keeps its own conversation state, and Paperclip can resume that same session on the next run when the working directory still matches. If it can’t, the agent starts fresh. A fresh session doesn’t have the old conversation. It has what survived outside it: the task, its comments and documents, and the branch. So write progress into the task, not only into the transcript.

3. The work changes hands. The API engineer marks A done. The execution policy moves A to review instead of done, and the reviewer takes over. When the reviewer approves, A is done, B’s blocker clears, and B is ready for the integration engineer’s next run in Codex. The record shows who held A, who reviewed it, what they decided and who owns B now.

4. Codex reaches its own boundary. Working on B, Codex tries to edit a configuration file outside its workspace. What stops it depends on the runner. On Paperclip Runner, the write runs into Paperclip’s workspace restrictions for native Codex. On the classic Codex adapter, the default ACP engine keeps Codex in its writable workspace sandbox, with network access on for each turn, while the CLI engine passes --dangerously-bypass-approvals-and-sandbox unless you turn that off. If the sandbox is bypassed, nothing in this stack blocks that write. Review and budgets still apply to the task, but neither one sandboxes a shell command.

When do you need a control plane?

If one developer runs one runtime and can see every session, the runtime’s own tools cover it. claude --resume and codex resume answer “what’s running and how do I get back to it?” Our guide to managing Claude Code and Codex sessions compares those options.

That changes when responsibility outlives the session:

• More than one runtime contributes to the same deliverable.
• The next owner of a piece of work isn’t in the session that produced it.
• Someone other than the agent doing the work has to review or approve the result.
• Someone needs to answer “whose job was this?” after every session has ended.

For how organizational control compares with workflow, gateway and identity control planes, see What is an AI agent control plane?

Assign each responsibility before the first unattended run

1. Which component blocks a risky tool call, and is it still active when the agent runs unattended? Check each agent’s runner and permission mode.
2. Is that block a text match, an OS-level sandbox or a rule on the remote service, such as branch protection?
3. Where does a session resume from, and what makes it start fresh?
4. What would a fresh session need to continue? Put that in the task.
5. Which record names the owner after the session ends?
6. Which system decides merge and deploy? Usually your Git host and CI, not a task status.

FAQ

What is an agent harness?

The software that runs the model-and-tool loop: it calls the model, runs tools, manages context and applies approval policies. Claude Code and Codex are harnesses packaged for coding.

What’s the difference between an agent framework and a control plane?

A framework gives you parts to build an agent. A control plane governs the work across agents you already run: owners, blockers, review and spend. You can use both.

Is LangGraph a framework or a runtime?

Both. LangChain calls it an orchestration runtime with durable execution and persistence, and developers also use it to define agent workflows. Ask which responsibility you need it to own.

Does Paperclip replace my framework or runtime?

No. Your agents still run on their own runtime. Paperclip sits above them and keeps the task, the owner and the review.

Can Paperclip block or sandbox the commands its agents run?

Partly, and it depends on the runner. Paperclip’s execution policy and connector permissions don’t see shell commands. For native Codex on Paperclip Runner, Paperclip applies its own workspace, network and environment restrictions. On the Legacy runner, the runtime’s own sandbox and the adapter’s permission settings are the boundary.

Related reading

• What is an AI agent control plane?
• Manage multiple Claude Code and Codex sessions
• Agent observability platforms: tracing, evaluation and team management
• Assign and review AI agent work without a terminal

Sources

• Microsoft, Agent harness
• AWS, AgentCore harness and AgentCore harness vs. Runtime
• LangChain, LangGraph overview and Deep Agents overview
• Anthropic, Claude Code permissions, permission modes, sandboxing and CLI reference
• OpenAI, Codex CLI commands
• Paperclip, What is Paperclip, agent adapters, Paperclip Runner, Claude Code adapter, Codex adapter, tasks, execution policy and connector action permissions