Deep Agents

The deciding trait is that the defaults are opinionated and none of them are load-bearing. You start with something that already works for long, multi-step tasks, and when a piece is wrong for you, you replace that piece instead of forking the project or rebuilding around it. That is a rare combination and it is why this one is worth the first hour.

What you inherit is a large vendor's idea of how agents should be structured, which is comfortable until you disagree with it. Pick it if you want momentum. Pick a smaller library if you would rather own every decision.

The gap is the default. Filesystem and shell backends are pluggable between local, sandboxed and remote, which is the correct architecture and also means the safe option is a choice rather than a starting point. A developer who wires this up quickly gets a shell tool pointed at the machine they are sitting at, and nothing in the row says that is unusual.

What it does right is delegation. Sub-agents receive tasks in separate context windows, so a long side quest does not poison the parent thread with its own transcript.

1. Offloading tool results to files and referring to them by path is the correct treatment of large observations, because it decouples what the agent can access from what it must currently hold. 2. Summarisation of long threads is applied as a documented stage rather than left to a prompt instruction, which makes the loss of detail a design decision instead of an accident.

2. Checkpointing under the graph runtime means a run has resumable states, so failure analysis starts from a recorded position. 4. No evaluation is published and none is claimed.

This is the strongest position on the open side of the category. A vendor with an existing developer base publishes the harness free, the harness pulls people onto the runtime underneath it, and the runtime is where the commercial platform lives. The giveaway is not charity, it is the cheapest customer acquisition in developer tooling.

Moat: distribution and habit, both real and both durable. Pricing power sits one layer up, not here. Likely path: this stays free indefinitely because it has to. Position: safe to depend on, and read the terms of the layer above before you depend on that too.

The approval gate is the part procurement can use. A documented interruption before a tool runs means an operator can be inserted into the loop by policy rather than by convention, and that is the difference between a control and a hope. I would make it mandatory in anything we deploy.

Everything else remains ours. No console, no identity integration, no retention statement, and nothing that runs unattended, so this is a component my platform team wraps in a service and operates. Approved with conditions: approval gates on, and one owning team accountable for the spend.

Model freedom here is not a footnote. Frontier, open-weight and local are all first-class, so the same harness runs against my box or somebody's API without a different code path, and my key pays for whichever I chose. MCP servers arrive as tools directly, so the things I already run plug in without an adapter.

The permissive licence means a fork outlives the vendor, which matters more here than usual because the vendor is large enough to change direction. Every piece is replaceable without forking, and that claim survives contact with the source.