Agentok Studio: AG2 Visualized as a Drag-and-Drop Code Generator

What Agentok Studio Is For, and Who It Is Not For

AG2 (formerly AutoGen) is a Python framework for multi-agent applications. Writing those applications means describing agents, the tools each one may call, and how messages move between them. Agentok Studio puts that description into a canvas. The README describes the output plainly: "Agentok Studio is a diagram-based code generator for AG2." The artifact you keep is Python, not a runtime you are locked into.

The intended user is someone who already understands AG2 concepts and wants to sketch conversation patterns faster than typing them. The README points readers to the official Conversation Patterns documentation for background, which is a signal that the tool assumes you know what a group chat or a sequential chat is before you draw one.

The tool is not for people who want to describe an agent in prose and get a working app. Every node maps to AG2 constructs, and the generated code targets the protocol-driven API (import ag2, Agent, and ag2.network hubs and channels). If you do not want to read that generated code, the visual layer is buying you very little.

The Canvas, the Edges, and Why Tools Live on Connections

The architecture is a browser frontend, a FastAPI backend, and Supabase for authentication and storage. The frontend is a Next.js app; the API is a Python service that runs on port 5004. The diagram is the source of truth, and the backend turns it into Python.

One design decision stands out. Tools are configured on the edge between two agents, not on the agents themselves. The README explains the reasoning: to include tool calls in a conversation, the LLM has to decide which tools to invoke while the user proxy is told which nodes to execute, so configuring tools on the edge is "crucial for optimal operation." This is a real modeling choice rather than a cosmetic one. It means the same agent reused in two places can expose different tool sets depending on who it is talking to.

The README also states that the RAG feature has been removed, on the grounds that it belongs in a separate service. That is a deliberate reduction in scope, and it means retrieval has to be wired in yourself.

Visibility is treated as a feature. The UI exposes the underlying data representation of the flow, and it attaches the original stdout and stderr from AG2 execution. When a run behaves oddly, you are reading the same logs the Python process produced, not a paraphrase.

Running the API in Docker and Building a First Flow

The fastest path to a working local stack is the API container plus a locally run frontend. Before starting anything, the README says to prepare the API environment by copying two sample files:

cp api/.env.sample api/.env
cp api/OAI_CONFIG_LIST.sample api/OAI_CONFIG_LIST

With those in place, docker-compose starts the API. The compose file builds from ./api, publishes port 5004, and reads ./api/.env, so the credentials you just copied are what the container sees:

docker-compose up -d

If you prefer to skip compose, the README gives the equivalent direct build and run. The port mapping and env file match the compose service:

docker build -t agentok-api ./api
docker run -d -p 5004:5004 --env-file api/.env agentok-api

The frontend is a standard Next.js app and is not containerized. From the frontend directory you copy .env.sample to .env.local, install with pnpm, and start the dev server:

cd frontend
pnpm install
pnpm dev

For a production build, the README warns that NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, and NEXT_PUBLIC_BACKEND_URL are baked into the Next.js bundle at build time, so they must be set in the hosting provider's environment before building, not after. If you hit repeated useContext server errors in development, the README suggests removing --turbo from the dev command in package.json.

Once the app is up, signing in with GitHub, Google, or email leads to Create New Project. Each new project arrives with a sample workflow, and the Chat tab starts the conversation. Model credentials come from Studio settings or from api/OAI_CONFIG_LIST.

Codegen Targets ag2 1.0, and Several Node Types Still Fail

The most important limitation is stated in the README itself. Agentok Studio now targets AG2 v1, with ag2==1.0.0b0, and codegen emits the protocol-driven API rather than the classic autogen / ConversableAgent stack. That is a beta dependency, and it is a hard boundary on what you can build.

Legacy node types are not supported yet. The README names Captain, Nested Chat, Retrieve, and GPT Assistant as examples, and says they will fail codegen with a clear error. A clear error is better than silent miscompilation, but it still means a diagram that looks valid on the canvas may not produce a script. If your workflow depends on nested chats or the retrieval node, this release cannot express it.

There is a second boundary around execution. Generated scripts default to a local sandbox via LocalEnvironment. The README is direct that stronger isolation requires configuring a Docker-backed environment in your own extensions. Running generated agent code that can execute tools on the host is a real risk, and the default does not remove it.

The hosted studio at studio.agentok.ai is a third constraint. The README states it is not intended for production, the service level agreement is not guaranteed, and stored data may be wiped due to breaking changes. Treat it as a demo, not as infrastructure.

Agentok Studio Compared with Hand-Written AG2 Code

The obvious alternative is writing AG2 directly in Python with no visual layer. The difference is not capability, because the output is the same framework either way. The difference is where the structure lives while you are still changing your mind.

In hand-written code, the topology of a group chat is spread across constructor arguments and registration calls, and rearranging who talks to whom means editing several places. In Agentok Studio, the topology is a graph you edit before generating. That is genuinely faster for exploring conversation patterns, and it is why the README frames the project as visualization first.

The trade-off runs the other way once the workflow stabilizes. A generated script is a snapshot; if you keep editing it by hand, regenerating from the canvas will overwrite your changes. The README's framing of the output as self-contained and runnable anywhere as a normal Python program is accurate, but self-contained also means the canvas is no longer the source of truth the moment you fork the file. Teams that expect round-tripping between the diagram and an edited script should check whether that is supported before committing, because the README does not describe an import path for existing AG2 code.

Maintenance Status, Licence, and Upgrade Cost

The repository is not archived, and the last push was on 2026-07-08. The most recent tagged release listed is v0.30.0 from 2025-02-10, so the release cadence and the commit activity are not moving at the same speed. Release automation is wired up through semantic-release with commitlint, so version numbers follow conventional commit messages rather than a hand-managed changelog.

The README also notes that the team is busy working on VibeX, described as the new backend of Agentok. That is worth reading carefully before you build on the current API, because it signals where future effort is going.

Licensing is the least clear part. The repository metadata reports NOASSERTION, while the README carries an Apache 2.0 badge and there is a LICENSE.md at the top level. Those two signals do not agree, and the README itself does not resolve the question. Check LICENSE.md directly, and if you are redistributing the generated output or the API image, get your own read on it rather than relying on a badge.

Upgrade cost is dominated by the AG2 beta pin. Codegen targets ag2==1.0.0b0, so a breaking change in AG2 v1 before its stable release lands on generated scripts, and the unsupported node list is likely to shift as that work continues.

Editorial conclusion

Agentok Studio fits teams who already write AG2 code and want a visual layer that emits readable Python they can inspect and run anywhere. It is the wrong tool if your workflow depends on the legacy node types the README lists as unsupported, or if you need production-grade hosting, since the online deployment is explicitly not for production and stored data may be wiped. Before adopting it, check two things: that your target pattern is expressible with the current node set, and that the generated script runs against the AG2 version you have pinned. Start from the docker-compose API on port 5004 with a local frontend, not from the hosted studio.

Frequently asked questions

Official sources

1. Issues
2. lyuai/agentok on GitHub
3. Project website
4. README
5. Releases