AgentScope

Version 2.0 makes a bet you will feel on day one: agents manage their own tools, so your job is writing good Python functions and skills rather than choreographing who speaks when. When the model is strong, that is far less code than the alternative and much easier to extend, because adding a capability means adding a function.

Pick it if you trust a frontier model to drive and want to spend your time on the tools it drives with. Pick LangGraph when the sequence matters more than the improvisation, because here the sequence is the model's decision.

The risk is where the weights live. The framework accepts any provider, and running one on your own hardware is not part of what it documents. For a system whose whole premise is that the model does the reasoning, that means the reasoning happens on somebody else's machine, permanently, and an air-gapped deployment is not on the map.

Anyone with a data-residency requirement should confirm this before designing around it. What it does right: tool calls execute in an isolated environment rather than in the host process, and that isolation is a first-class part of the design instead of an example in a footnote.

1. Capability is assembled from three sources: Python functions, MCP servers and named skills, all managed by the agent rather than fixed at construction. 2. Every tool call runs in an isolated environment, and four backends are documented: Docker, E2B, Kubernetes and a Daytona workspace, which lets the isolation level match the deployment instead of forcing one choice.

2. Verification is not described. Nothing in the documentation defines how an agent decides a task succeeded, and no benchmark is published, so the capability claim rests on the workspace documentation and the examples beside it.

A cloud vendor giving away an agent framework is buying default placement for its own models and its own infrastructure. That is a sound trade and it makes the project unusually well funded for something with no price. It also makes it a line item in a research lab's plan rather than a product with a customer, and lab priorities change without a press release.

Moat: distribution through a large cloud. Likely path: quiet absorption into the parent's managed platform, or a slow fade if the lab's attention moves. Position: adopt the library, assume the roadmap belongs to somebody else.

Cost at sixty engineers is zero plus whatever inference we consume, and that is the whole finance conversation. The gaps are elsewhere. There is no unattended execution mode, so this is a thing engineers run at their desks rather than something we can schedule, monitor and bill centrally. Access control is our problem because there is no console to control.

Onboarding is a week for a Python engineer. Support means opening an issue against a research group. Approved with conditions: one product team, our own deployment wrapper, and a review before anything customer-facing depends on it.

Apache-2.0, one pip install, and the source is readable enough that I found what I needed in an evening. As an MCP client it takes every server I already run, which saved rewriting a stack of tools I finished months ago.

What is missing is the other half. It does not expose itself over MCP, so an agent I build here is reachable only from code I also write. I want the thing I built to be a tool in somebody else's client, and that means either a wrapper or a patch. The licence means the patch is mine to keep, which is the part I care about most.