Tinyflow: a Web Component agent editor you embed in your own app
Tinyflow is a lightweight AI agent solution.
At a glance
- What is it?
- Tinyflow is not an agent product but a front-end component that gives an existing application a workflow canvas for AI agents. The README claims cross-framework support through Web Components and a Java execution backend hosted in a separate repository, while the Node.js and Python backends are listed as still in development.
- Who is it for?
- Adopt Tinyflow if you already run a Java service and want a workflow canvas inside an existing React, Vue, Angular, Svelte or plain HTML application without building a graph editor yourself. Do not adopt it if you need a Python or Node.js execution backend today, since the README lists both as not yet open, or if you cannot accept LGPL-3.0 terms on a component you ship to browsers.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Svelte, 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 gap Tinyflow targets: agent orchestration inside apps that already exist
Most agent tooling arrives as a standalone application. You get a hosted console or a self-hosted server, your team builds workflows there, and the result lives outside your product. Tinyflow takes the opposite position. The README states plainly that it is not a product but a development component, and the goal is that integrating it lets any traditional application gain the ability to orchestrate AI agents. That framing decides the audience. It is for teams that already have a working application and want a canvas for building and editing agent flows inside it, rather than a separate tool their users have to visit. The repository is primarily Svelte, but the README says the front end is built on Web Components, which is the mechanism behind the claim that React, Vue, Angular, Svelte, and plain HTML, CSS and JavaScript are all supported. The published packages track that split: @tinyflow-ai/ui, @tinyflow-ai/vue and @tinyflow-ai/svelte all carry the same 1.3.7 version in the recent release list.
What the front end actually does: a canvas, a JSON document, and a provider
The component surface described in the README is small. You construct a Tinyflow instance against a container element. Three parameters are documented: element, which accepts a selector string or a DOM element; data, described as the workflow data and typed as a JSON object; and provider, described as a data provider that currently covers large model configuration under the key llm and knowledge base data under the key knowledge. Two methods are listed: tinyflow.getData() exports the workflow data, and tinyflow.getOptions() returns the initialization parameters. That is the whole documented contract. The data flow implied by it is straightforward. The canvas edits a JSON graph, getData() hands that graph back to your application, and your backend receives it for execution. The provider option is the interesting part, because it is where Tinyflow stops being self-contained. The component does not appear to own model credentials or retrieval indexes; it asks your application for them through provider. The README does not document the shape of the provider object beyond the two keys, so anyone integrating should expect to read the source or the site documentation at tinyflow.cn to learn the exact structure. This is the thinnest part of the supplied material and the first thing an integrator will hit.
The execution half lives in a different repository, and that matters
Designing a workflow and running it are separate concerns in Tinyflow, and they are separated by repository. The front-end packages ship from tinyflow-ai/tinyflow. The README points execution at https://gitee.com/tinyflow-ai/tinyflow-java, consumed as a Maven dependency on dev.tinyflow:tinyflow-core, version 2.0.3 in the documented example. Two consequences follow. First, the version numbers do not move together. The front end is at 1.3.7 in the release list while the Java core example shows 2.0.3, so upgrade planning has to track two artifacts with independent release cadences. Second, the JSON that getData() produces is a contract between two codebases that are not versioned as one, which is the classic place where a canvas upgrade silently breaks the executor. The README gives no schema version field or compatibility statement, so that risk is unquantified from the material available. Anyone evaluating Tinyflow should treat the front-end and Java core as a coupled pair and pin both.
Getting it running: two installs and a container element
The front-end path is documented as npm install @tinyflow-ai/ui, then importing Tinyflow from that package alongside @tinyflow-ai/ui/dist/index.css, then instantiating it with an element selector. The CSS import is separate from the JavaScript import, which is normal for a Web Component bundle that ships its styles as a file rather than injecting them, and it is easy to forget in a bundler that does not pick up bare CSS imports automatically. The Java path is the Maven coordinates above, groupId dev.tinyflow, artifactId tinyflow-core, version 2.0.3. The README states that the Java backend is not tied to a particular framework, which matters if you are on something other than Spring. For other runtimes the README is explicit that Node.js and Python are in development and not yet open, while still listing the install commands npm install @tinyflow-ai/nodejs and pip install tinyflow-ai-python. Those commands should be read as placeholders for future packages, not as working instructions today. There is no documented configuration file, no environment variable list, and no CLI in the supplied material, so setup is entirely library integration on both sides.
Where Tinyflow is the wrong choice
The most concrete limitation is backend coverage. If your stack is Python or Node.js, the README says both backends are still in development and not open, which leaves Java as the only execution option described. A Python team would have to either write its own executor against the JSON the canvas produces or run a JVM service alongside its application purely to execute workflows. Neither is disqualifying, but both change the cost of adoption substantially, and the README does not describe the workflow JSON schema in enough detail to estimate the work of a custom executor. A second limitation is scope. Tinyflow is an editor and an execution library, not an agent runtime with memory, scheduling, retries, or observability. Nothing in the README claims those, and nothing in it suggests where they would come from. A team that needs long-running agents with persistence and monitoring will find the component covers only the authoring and execution slice. A third is the provider contract: because llm and knowledge are supplied by the host application, Tinyflow does not reduce the work of connecting to models or retrieval systems, it only moves that work to your side of the boundary.
How this differs from building on a general graph editor
The obvious alternative is to assemble the same feature from a general-purpose node editor such as React Flow or Svelte Flow plus your own node definitions and serialization. The difference in approach is real and worth stating precisely. A general graph editor gives you a canvas and leaves the domain model, the node palette, the property panels, and the export format entirely to you. Tinyflow ships an opinionated agent-shaped model instead: the provider option already distinguishes model configuration from knowledge base data, and getData() already emits a workflow document that a matching executor understands. You trade control over the schema for not having to design one. The cost of that trade is that custom node types and non-standard execution semantics have to fit inside a format documented elsewhere, and the README does not describe how far that format extends. If your agent graph is unusual, a general editor plus your own schema may be less friction than bending an existing one. If your graph looks like the common shape of model call plus retrieval plus branching, Tinyflow starts you further along.
Maintenance, licensing, and what LGPL-3.0 means for a browser component
The repository is licensed LGPL-3.0. For a component that is installed as a dependency and bundled into a front-end build, the practical question is whether your distribution triggers the relinking and source obligations the licence carries, and that depends on how you link and ship it, including whether you modify the package. This is not a question to settle from a README, and nothing here is legal advice. Get a real answer from whoever handles licensing at your organisation before you ship a modified build. On maintenance, the material shows an active release train: three packages at version 1.3.7 published within seconds of each other, and a last push date of 2026-08-25. Coordinated multi-package releases suggest the front-end packages are versioned together, which simplifies upgrades on that side. The Java core is the opposite situation, since it lives in a separate Gitee repository with its own version line, and its release cadence is not visible in the supplied material. Budget for reading two changelogs, not one, and for testing a canvas upgrade against your pinned executor before rolling it out.
Editorial conclusion
Adopt Tinyflow if you already run a Java service and want a workflow canvas inside an existing React, Vue, Angular, Svelte or plain HTML application without building a graph editor yourself. Do not adopt it if you need a Python or Node.js execution backend today, since the README lists both as not yet open, or if you cannot accept LGPL-3.0 terms on a component you ship to browsers. Before committing, verify three things: that the Java core at gitee.com/tinyflow-ai/tinyflow-java supports the node types you need, that the provider contract for llm and knowledge matches your own model and retrieval endpoints, and that your build tooling can consume a Web Component bundle plus its separate dist/index.css.
Community notes