One notebook becomes a UI page, an HTTP endpoint and an agent tool, inside a React and Express app.

One workflow can have three kinds of caller: a person who fills in a form and reads the result, another program that calls it over HTTP, and an AI agent that calls it as a tool. In Zaatool all three come from the same notebook.

That notebook is ordered cells in one scope, written in JavaScript or Python. It is not a node graph of boxes joined by lines. The project’s own line for this is “Stop drawing boxes.”

Serving all three callers from one notebook meant building the whole application, not a library that plugs into someone else’s runner: a React 19 interface for writing and running notebooks, an Express 5 REST API behind it, a PostgreSQL schema with its own migrations, and a Docker Compose file that starts the pair. One person writes and maintains all of it.

Zaatool is in real use at a small scale: a research group at Telkom University, the OCR team, uses it for a data pipeline into an LLM. The use is unpaid.

Cells in one scope, not a node graph

Chosen: a workflow is a sequence of cells that share one scope, each in JavaScript or Python, edited in CodeMirror 6.

Not chosen: a node graph as the way to write a workflow. Maps still exist as views. A system map shows the dependencies between notebooks, and a notebook map draws the cells of one notebook; both are in the videos under Evidence.

One notebook, three outputs

Chosen: the notebook itself produces a UI page, an HTTP endpoint and a tool for AI agents. Inputs and outputs are declared on the notebook, and the form and the API schema are generated from those declarations automatically.

In the screenshots under Evidence, one notebook, financial-report-demo-v2, appears three ways: as cells in the editor, as a page after a run with a table, a summary and charts built from its outputs, and as a shared read-only page with a Run button. The apps list shows each notebook with its declared inputs and outputs.

Agents reach Zaatool over MCP: 13 core tools, plus one tool per notebook. The resources page holds the rules that every agent connected over MCP reads, next to tabs for secrets and API keys, files, accounts and agent tokens.

Not chosen: a page, an endpoint and an agent tool built as three separate things.

The application around the notebooks

Chosen: a React 19 interface over an Express 5 REST API, with the PostgreSQL schema and its migrations in the same repository. The interface holds the CodeMirror 6 editor, the notebook and app lists, and result pages whose tiles can be arranged: text, charts, images and tables.

Notebooks do not only run when someone asks. Cron and webhook triggers start them, and the secrets those runs need are managed in the app rather than typed into a cell. Cell edits carry an etag guard, so two people editing one notebook do not overwrite each other unnoticed.

Not chosen: letting the last save win.

One Node process and PostgreSQL

Chosen: Zaatool runs as a single Node process plus PostgreSQL, started with Docker Compose.

Not chosen: Redis, a queue or an object store. The consequence is listed under Limits: it is single-node.

• Shipped as a public repository under the MIT license: a working beta with one maintainer, started in June 2026.
• Used by a research group at Telkom University (the OCR team) for a data pipeline into an LLM. Small scale, unpaid.
• Over MCP: 13 core tools, plus one tool per notebook.
• Triggers: cron and webhook, with secret management.
• Result pages built from a notebook’s own outputs, with tiles for text, charts, images and tables.
• A system map of dependencies between notebooks.
• A shared page that can be opened read-only, optionally behind a password.

This page quotes no usage or performance numbers.

The code is public under the MIT license in the Zaatool repository.

The screenshots below show the notebook editor, the same notebook as a page and as a shared read-only page, the apps and notebooks lists, and the resources that agents connected over MCP read. The two videos show the system map and the notebook map. They load only when played.

• No integration library yet.
• Single-node: one Node process and PostgreSQL.
• No SSO or email yet.
• One maintainer, and one small, unpaid user group.
• Rewind-Bench surfaced a real concurrency bug in Zaatool.