AgentScope Runtime: a sandboxed agent server that is now read-only
A production-ready runtime framework for agent apps with secure tool sandboxing, Agent-as-a-Service APIs, scalable deployment, full-stack observability, and broad framework compatibility.
At a glance
- What is it?
- AgentScope Runtime wraps agent frameworks in a FastAPI-derived server with a hardened tool sandbox, A2A and OpenAI-compatible endpoints, and local or serverless deployment. The repository is in read-only mode because its capabilities moved into AgentScope 2.0, which changes who should look at it at all.
- Who is it for?
- Read this repository if you are evaluating how a Python agent runtime separates tool execution from the serving process, or if you maintain code already built on AgentApp. Do not start a new project on it: the README states the repository will be archived and points users to AgentScope 2.0 for continued updates.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 104 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AgentScope Runtime was built to absorb
Running an agent as a demo and running one as a service are different jobs. A demo can execute a model-generated shell command in the same process as the HTTP handler. A service cannot, because a tool call that writes files or drives a browser is untrusted code arriving from a model. AgentScope Runtime exists to put a boundary there. The README describes three core capabilities: tool sandboxing, where a tool call runs inside a hardened sandbox; Agent-as-a-Service APIs, which expose agents as streaming, production-ready endpoints; and scalable deployment across local, Kubernetes, or serverless targets. The audience is Python teams that already have an agent built on AgentScope, LangGraph, Agno, or another framework and now need to serve it without handing the host machine to the model. The topics list on the repository, which includes docker, kubernetes, mcp, a2a, and serverless, reads as a statement about where the project expects to be deployed rather than how it is prototyped.
AgentApp: three stages, direct FastAPI inheritance
The central abstraction is AgentApp, and the README frames it as a three-stage development pattern: init, query, and shutdown. The Quick Start walks from installation to a minimal agent API service, and the recommended reading order for someone who wants an app running quickly is the Agent App example followed by verification with curl against an SSE stream. The README also records an architectural change in v1.1.0: AgentApp moved from a factory pattern to direct inheritance from FastAPI, and the release note states this gives integration with the full FastAPI ecosystem and improves extensibility. That detail matters more than it sounds. Direct inheritance means the routes, middleware, and dependency-injection machinery you already know from FastAPI apply to the agent server, so the serving layer is not a bespoke protocol you have to learn separately. The cost is that your agent application is now coupled to FastAPI's request model, and the deprecation of the factory pattern means code written against the older construction style needs rework rather than a version bump.
Sandboxing tools across Python, Shell, GUI, Browser, Filesystem and Mobile
The sandbox is the part with the least ambiguity in the README and the most consequence. The Sandbox example covers executing Python, Shell, GUI, Browser, Filesystem, and Mobile tools inside an isolated environment. The reading order for anyone who cares about secure tool execution lists the sandbox examples first, then sandbox image registry, namespace, and tag configuration, and optionally production-grade serverless sandbox deployment. That ordering is a useful signal about operational reality: choosing which image your sandbox runs is a configuration decision you make before you scale anything, and the README treats it as a distinct step rather than a footnote. What the README does not give is a threat model. There is no statement about which isolation primitive backs the sandbox on each deployment target, and no published escape-testing results. If your requirement is a documented security boundary with named guarantees, this README does not supply one, and you should read the sandbox implementation directly before relying on it.
Serving one agent over A2A, Response API, and the OpenAI SDK
The Deployment example introduces DeployManager, which the README describes as handling local or serverless deployment, with the resulting service reachable through A2A, a Response API, or the OpenAI SDK in compatible mode. Three access paths over one agent is a deliberate choice: A2A suits agent-to-agent traffic, while the OpenAI-compatible mode lets existing clients talk to your agent without a new SDK. Streaming is the default posture rather than an add-on, since the Quick Start verification step uses curl against server-sent events. The practical constraint is that compatibility modes move at the speed of the protocol they imitate. If your client depends on a field the OpenAI-compatible surface does not map, the README gives you no fallback path other than the Response API. Treat the three endpoints as three contracts with three separate stability stories, not as one API with three spellings.
Installation, prerequisites and the configuration keys you actually touch
The README states Python 3.10 or later and offers installation from PyPI or from source, with the package published as agentscope-runtime. A minimal service follows the Agent App example, and the README's verification step is a curl request against the SSE endpoint. Beyond that, the named configuration surface in the material is narrow: the sandbox image registry, namespace, and tag, plus DeployManager for choosing a local or serverless target. The README does not enumerate environment variable names or a full settings schema, so the honest position is that the installation path is documented and the complete configuration surface is not. If you are sizing an evaluation, budget time for reading the Guides site and the sandbox implementation, because the README alone will not tell you every knob. The Cookbook at runtime.agentscope.io is presented as the place where concepts, architecture, and APIs are covered in more depth than the repository front page.
The archive notice is the deciding fact
The most important line in the README is at the top, not in the feature list. An Archive Notice states that with the release of AgentScope 2.0, all capabilities of AgentScope Runtime, specifically tool sandboxing, Agent-as-a-Service APIs, and full-stack observability, have been natively integrated into AgentScope 2.0. The notice recommends that all users migrate to AgentScope 2.0 for continued updates, new features, and community support, and says this repository will remain available in read-only mode for reference and will be archived soon. The repository metadata still shows a recent push and a v1.1.6.post2 release, so the code is not stale in the sense of being abandoned mid-change. It is frozen by intent. Any evaluation has to answer a prior question: are you reading this to understand a design, or to build on it? The answer changes everything downstream, including how much weight you give to the FastAPI refactor in v1.1.0, which is a genuine improvement that will not see further development here.
Where a framework-native runtime beats this, and where it does not
The obvious alternative is to serve the agent from the framework that defines it. LangGraph, for instance, ships its own server path, and the difference in approach is philosophical rather than merely technical: a framework-native server treats the graph definition as the deployment artifact, so state, checkpoints, and streaming semantics come from the same library that executes the graph. AgentScope Runtime inverts this. It is a serving and isolation layer that sits above whichever framework you chose, which is why the topics list spans langgraph and agno alongside agentscope. That inversion is the reason to pick it: you get one sandbox and one deployment story across frameworks, and you can swap the agent implementation without rewriting the server. It is also the reason to avoid it: you inherit a second abstraction over your framework, and when the framework changes its execution model, the runtime layer is where the mismatch surfaces. With this repository read-only, that mismatch has no upstream fix. The comparison is not which is better in the abstract, it is whether you want the sandbox boundary owned by your framework or by a layer above it.
Licence, maintenance and the migration you should scope now
The repository is Apache-2.0, which permits commercial use, modification, and redistribution provided you retain the licence and notices, and it includes a patent grant. That licence does not expire when the repository is archived, so existing deployments are not in legal jeopardy from the archive notice alone. The maintenance question is separate and less comfortable. Read-only means no further security patches to the sandbox, and a sandbox is exactly the component where an unpatched issue is most expensive. The release history shows a v1.1.6 line with two post releases and a v.1.1.6 tag whose version string is inconsistent with the others, a small sign of release hygiene that is worth noting but not worth overreading. This is not legal advice, and the migration decision is not purely legal either: it is whether you want to run a security-sensitive isolation layer that no longer receives updates. For anyone with a live deployment, the concrete next step is to inventory which AgentApp handlers and which sandbox image settings you depend on, then check those against AgentScope 2.0 before the archive completes. For anyone without a deployment, there is nothing here to adopt.
Editorial conclusion
Read this repository if you are evaluating how a Python agent runtime separates tool execution from the serving process, or if you maintain code already built on AgentApp. Do not start a new project on it: the README states the repository will be archived and points users to AgentScope 2.0 for continued updates. Verify first whether AgentScope 2.0 exposes the sandbox image registry, namespace, and tag configuration keys your deployment depends on, then diff that against your current AgentApp init, query, and shutdown handlers before you port anything.
Community notes