AgentScope Studio Is Archived: What the Toolkit Did and What Replaces It
A development-oriented visualization toolkit
At a glance
- What is it?
- AgentScope Studio was a TypeScript visualization layer for AgentScope agents, covering runs, OpenTelemetry traces and evaluation. Its own README now tells users to migrate to AgentScope 2.0, which changes the adoption question from how to install it to whether anything here is still worth reading.
- Who is it for?
- Read this repository for reference only. Do not start a new integration against it, because the maintainers have stated it is no longer maintained as a standalone tool and will be archived.
- 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 14 days ago.
- What is it written in?
- Mainly TypeScript, 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 archive notice reframes the whole project
The first thing a reader meets in this repository is not a feature list but a migration instruction. The README states that AgentScope 2.0 ships a built-in Web UI as part of its Agent Service, a FastAPI backend paired with a pre-built frontend under examples/web_ui, and that AgentScope Studio is no longer maintained as a standalone tool. The repository will stay readable and will be archived soon. That single paragraph decides how the rest of this review should be used. AgentScope Studio is not a project you evaluate for adoption in the usual sense. It is a reference implementation of a development-time visualization layer for AgentScope, written in TypeScript, published to npm as @agentscope/studio, and licensed Apache-2.0. Its audience was narrow by design: developers building agent applications on AgentScope who wanted to watch runs, inspect traces and read evaluation output without wiring up their own dashboard. The problem it addressed is a real one. Agent frameworks produce a stream of model calls, tool invocations and token accounting that is hard to reason about from log lines alone, and the toolkit turned that stream into a chat-style runtime view plus a trace view. Anyone arriving now should treat the code and the documentation as a description of how that layer was built, and should treat AgentScope 2.0 as the supported destination.
Projects, runs and the chatbot view
The README lists five feature areas: project management, runtime visualization, tracing, agent evaluation and a built-in copilot named Friday. The organizing unit is a project, and inside a project the unit is a run. That vocabulary matters because it shapes what the tool is good at. A run is a single execution of an agent application, and grouping runs under a project is what makes comparison possible at all. The runtime view is described as a chatbot-style interface for real-time agent interaction, which is the part a developer uses while iterating: send a message, watch the agent respond, see the intermediate steps. The evaluation feature is described as analysis from a statistical perspective, which implies aggregation across runs rather than inspection of one. The README does not specify the storage backend, the schema of a run, or how long data is retained, so anyone who needs those details has to read the source or the linked documentation pages. What can be said from the material is that the tool separates the live view from the aggregate view, and that both are scoped to a project. That separation is the design decision worth noting. Plenty of agent debuggers show you one conversation at a time and stop there. AgentScope Studio's project and run model is an attempt to make repeated executions comparable, which is the harder half of debugging an agent that behaves differently on the same input.
OpenTelemetry is the integration surface
The tracing layer is built on OpenTelemetry, and the badges in the README name tracing, evaluation and the Friday copilot as distinct capabilities. The repository topics include opentelemetry and tracing alongside agent, llm and multi-agent, which is consistent with the README's own description of trace visualization for LLM calls, token usage and agent invocations. This is the most portable part of the design. Because the wire format is OpenTelemetry rather than a bespoke protocol, the data model is not tied to one runtime, and the documentation page on tracing is described as covering OpenTelemetry integration and semantic conventions. Semantic conventions are where the interesting constraints live. A trace viewer can only render what the emitter chose to record: span names, attributes for token counts, parent-child relationships for nested agent calls. If an application emits spans without the attributes the viewer expects, the trace will appear with gaps. The README does not publish the convention list inline, so the linked tracing document is the place to check which attributes are required for token usage and LLM call rendering to work. This is also the part of the project most likely to survive the archive, because OpenTelemetry conventions outlive the viewer that consumes them.
Installing and pointing an agent at it
The prerequisites are explicit: Node.js 20.0.0 or higher and npm 10.0.0 or higher, with Docker optional for container deployment. The README suggests nvm users can run nvm use to switch to the required version, and gives version check commands. Installation from npm is the recommended route: npm install -g @agentscope/studio, then start it with as_studio. From source, the sequence is git clone https://github.com/agentscope-ai/agentscope-studio, cd agentscope-studio, npm install, then npm run dev for development mode. Docker deployment is delegated to docker/README.md. Connecting an application is a one-line change on the Python side: the README shows agentscope.init with studio_url set to http://localhost:3000, in a snippet that imports agentscope and passes the URL among the initializer arguments. That is the entire documented integration. There is no mention of an API key, a token, or an authentication step for the local server, and the URL in the example is plain HTTP on localhost. Anyone exposing that port beyond a development machine is making a choice the documentation does not discuss. The as_studio binary name is worth noting too, since it is the command you would script or alias; it is the same entry point whether the package was installed globally or run from a clone.
The copilot and the parts the README leaves thin
Friday, the built-in copilot, is described in three ways: a development assistant, a playground for rapid secondary development, and an integration hub for advanced features. That is a broad remit for one component, and the README does not narrow it. The linked Friday document is the only place that would resolve what it actually does, whether it calls a hosted model, and what credentials it needs. Because the archive notice says nothing about Friday specifically, a reader cannot tell from the README whether any part of it was carried into AgentScope 2.0's Web UI. The same gap applies to the evaluation feature. Statistical analysis across runs is a claim, not a specification: no metric list, no aggregation method, no export format appears in the material. This is not unusual for a project README, but it matters here because the archive notice means the documentation will not be extended. What a reader can rely on is the shape of the tool: a local server started by as_studio, a Python client configured through studio_url, a project and run hierarchy, and an OpenTelemetry trace pipeline underneath. Everything past that shape has to be confirmed by reading the source or the tutorial pages under docs/tutorial/en.
Langfuse and the difference between a viewer and a platform
The obvious alternative for anyone who wants agent traces without adopting AgentScope's own UI is a dedicated observability platform such as Langfuse. The difference is architectural, not cosmetic. AgentScope Studio was designed as a local, development-oriented toolkit that ships with the framework and knows its run model directly: a run belongs to a project, and the chatbot view is tied to the same execution record. A platform like Langfuse is framework-agnostic by construction, ingests OpenTelemetry or SDK events from any source, and is built around a hosted service with persistence and team access as first-class concerns. Choosing between them is choosing between a bundled viewer and an external store. The bundled viewer gives tighter coupling to AgentScope's concepts and no data leaves the machine, which is what the local toolkit framing implies. The external platform gives you traces from multiple frameworks in one place and a longer retention story, at the cost of running or paying for another service. There is a third option now, and the README names it: the AgentScope 2.0 Web UI, which the notice describes as covering real-time visualization of reasoning, tool calls and multimodal content, multi-session isolation, leader-worker orchestration, permission and human-in-the-loop control, IM channels, MCP and Skill Hub management, session persistence and task scheduling. If you are already on AgentScope 2.0, that set of features is broader than what Studio offered, and it is the option the maintainers recommend.
Maintenance, licensing and what the archive costs you
The maintenance picture is stated plainly: no further updates, read-only mode, archival soon. The last push recorded for the repository is 2026-09-02, and the most recent release listed is v1.0.9 from 2026-03-06, following v1.0.8 in January 2026 and v1.0.7 in December 2025. Those dates describe a project that was receiving regular point releases before the migration notice, not one that had gone quiet long before. That makes the archive a deliberate consolidation rather than abandonment: the functionality moved into AgentScope 2.0 rather than disappearing. The licence is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes a patent grant. This is a general description of the licence text, not legal advice; if you intend to fork the toolkit and ship it, read the LICENSE file in the repository and get your own counsel. The practical upgrade cost for an existing user is the migration itself: replacing a standalone process started by as_studio and configured through studio_url with the built-in Web UI, and checking that any trace attributes your instrumentation emits still match whatever the new UI expects. Because the tracing layer is OpenTelemetry, that instrumentation is the part most likely to carry over unchanged, which is the strongest argument for not ripping it out.
Editorial conclusion
Read this repository for reference only. Do not start a new integration against it, because the maintainers have stated it is no longer maintained as a standalone tool and will be archived. If you already run it, verify two things before planning a move: which OpenTelemetry semantic conventions your traces rely on, and whether the AgentScope 2.0 Web UI under examples/web_ui covers the same tracing and evaluation views. If your only need is a local viewer for agent runs, the built-in UI is the path the README points to.
Community notes