# Tinyflow: a Web Component for embedding AI agent orchestration in any frontend

> Tinyflow is a lightweight AI agent component rather than a product. It ships a framework-agnostic web component for designing agent workflows and a Java backend that executes them. Here is what the repository actually documents, and where it stops.

**tinyflow-ai/tinyflow** — Tinyflow is a lightweight AI agent solution. 

- Repository: https://github.com/tinyflow-ai/tinyflow
- Website: https://www.tinyflow.cn
- Stars: 700 · Forks: 80
- Language: Svelte
- License: LGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/tinyflow-ai-tinyflow

## What Tinyflow is, and the problem it targets

Tinyflow describes itself as a lightweight AI agent solution, and then immediately qualifies that: it is not a product but a development component. The distinction matters for anyone evaluating it. You are not adopting a hosted agent platform with accounts and dashboards. You are adding an orchestration surface to an application you already own.

The problem it addresses is a narrow one. A team has a working web application, written in some framework or in plain HTML, and wants users to visually assemble AI agent workflows inside that application. Building a workflow canvas from scratch is a large amount of work that has nothing to do with the product being shipped. Tinyflow supplies that canvas as an embeddable component, plus a runtime on the backend that executes whatever the canvas produces.

The audience follows from that. This is for frontend and backend engineers integrating agent authoring into an existing product, not for end users looking for an agent tool. The README's own framing supports this: integration is what makes a traditional application capable of AI agent orchestration.

One thing the README does not do is define what counts as an agent here. There is no description of tool calling, memory, retries, or multi-step planning. The feature list covers frontend framework support and backend language support, and stops. Treat the scope as whatever the workflow JSON can express, and verify that against your requirements rather than against the marketing line.

## Web Component frontend, JSON workflows, pluggable providers

The frontend is built on Web Components. That single choice explains the framework claim in the README: React, Vue, Angular, Svelte, and plain HTML, CSS and JavaScript are all listed as supported, because a custom element does not care which framework rendered the surrounding page. The repository layout is consistent with this. There are separate packages under packages/ with published names like @tinyflow-ai/ui, @tinyflow-ai/vue and @tinyflow-ai/svelte at version 1.3.7, so the Svelte build is the primary implementation with thin adapters for other ecosystems.

The data model is a JSON object. The constructor accepts a data parameter described as the workflow data, and the instance exposes getData() to export it and getOptions() to read back the initialization configuration. That round trip is the core of the design: the editor holds a JSON graph, you export it, and a backend executes it.

The third piece is the provider. The README says provider supplies data for the large model configuration (llm) and knowledge base (knowledge). This is how Tinyflow avoids hardcoding a vendor. The component asks the host application for model and knowledge base options, and the host answers. In practice that means you write the glue that lists your available models and your available knowledge bases. The README does not document the provider interface shape, so expect to read the type definitions in the packages rather than the documentation.

Execution is deliberately out of the frontend's hands. The README points to a separate Java repository for running designed workflows. The frontend designs, the backend runs. Nothing in the README suggests the browser executes the graph.

## Installing the frontend and mounting a first editor

The README gives a two-step quick start. Install the UI package with npm, then import the class and its stylesheet, then construct it against a container element. The element parameter accepts either a CSS selector string or a DOM element, so the container can be created programmatically if your framework prefers that.

```bash
npm install @tinyflow-ai/ui
```

After that install completes, the package exposes a Tinyflow class and a compiled stylesheet at dist/index.css. Both imports are required. The README imports the CSS separately, which is the usual pattern for a component library that does not inject styles at runtime.

```ts
import { Tinyflow } from '@tinyflow-ai/ui';
import "@tinyflow-ai/ui/dist/index.css";

new Tinyflow({
    element: '#tinyflow',
});
```

With that code running, the element matching #tinyflow should contain the workflow editor. The README shows only element being passed. It documents data and provider as additional parameters but does not show them in the example, so a first run without a provider will render the canvas without populated model or knowledge base choices. To read the current graph back, call getData(), and to inspect how the instance was configured, call getOptions().

The repository requires Node 20.19 or newer in its engines field, and uses pnpm 10.34.5 with Turborepo across the workspace. That applies to building the project from source. Installing the published package into your own application is a normal npm install and does not require the monorepo tooling.

## The Java execution backend is a different repository

This is the part most likely to trip up an evaluation. The JavaScript repository you are looking at does not execute workflows. The README states that the Java backend exists mainly to execute workflows designed in Tinyflow, and gives its open source address as a separate Gitee repository, tinyflow-java.

Integration is through Maven. The README gives the coordinates directly, with group id dev.tinyflow, artifact id tinyflow-core and version 2.0.3.

```xml
<dependency>
    <groupId>dev.tinyflow</groupId>
    <artifactId>tinyflow-core</artifactId>
    <version>2.0.3</version>
</dependency>
```

Two consequences follow. First, the JSON your frontend exports has to be understood by that Java library, and the README does not describe the schema or promise compatibility between frontend and backend versions. The frontend packages are at 1.3.7 while the Java artifact is at 2.0.3, and the README gives no mapping between those version lines. Second, the Java side is not restricted to a particular framework according to the README, which means you bring your own web layer and wire the execution call yourself.

For a Java shop this is a reasonable shape: the agent runtime lives next to your existing services and shares their deployment. For anyone else it is a hard stop, because the only execution path the README documents is Java.

## Python and Node.js backends are not available yet

The README lists Python and Node.js as backend options, then qualifies both in the same breath: under development, not yet open. The install commands are shown anyway, npm install @tinyflow-ai/nodejs and pip install tinyflow-ai-python, but the surrounding text says the packages are not released.

This is a genuine limitation, not a documentation gap. If your stack is Python or Node.js, you can embed the editor today and you cannot execute what it produces without either running the Java backend somewhere or writing your own executor against the exported JSON. The README does not publish that JSON schema, so writing your own executor means reverse-engineering it from the frontend packages.

The version numbers reinforce the point. The published releases in this repository are all frontend packages at 1.3.7, dated 2026-08-25. There is no Node.js or Python release in the list. The repository's own test script runs two Vitest configurations, including one named vitest.adapters.config.ts, which suggests adapter packages are tested in the monorepo, but a test configuration is not a published backend.

If your only requirement is the visual editor and you plan to execute the graph in your own runtime, this limitation does not block you. If you expected a drop-in Python agent runtime, it does not exist yet in anything the README points to.

## How Tinyflow differs from building on a general workflow canvas

The obvious alternative is a general-purpose node-based editor library, of which there are several in the JavaScript ecosystem, paired with your own execution engine. The difference is where the domain knowledge sits. A generic canvas gives you nodes, edges, panning and zooming, and nothing about models or retrieval. You define every node type, every configuration form, and every runtime handler yourself.

Tinyflow's bet is that the AI-specific parts are the expensive ones. The provider concept for llm and knowledge exists precisely so the component can render model pickers and knowledge base pickers without you designing those forms. The Java core exists so the exported graph has a runtime that already knows what those nodes mean. You trade flexibility at the node level for not building the AI layer.

That trade has a cost. A generic canvas places no constraints on your data model, and Tinyflow's graph has to be one the Java runtime can execute. If your agent needs a node type the runtime does not implement, the generic route lets you add it in an afternoon, while Tinyflow requires either a contribution to the Java project or a custom executor.

A second alternative is a full agent platform with its own UI and hosting. Those give you execution and observability out of the box but take over the user-facing surface. Tinyflow's explicit position as a component rather than a product is the opposite bet: you keep the application, and the agent editor is a panel inside it.

## Licence, release cadence and what upgrades cost

Tinyflow is licensed under LGPL-3.0. For the frontend packages this is the term that matters most, because you are distributing the component inside a web application. LGPL obligations attach to the library itself and to modifications of it, and the usual question is whether bundling a minified component into a larger frontend build counts as distribution that triggers relinking obligations. That question is jurisdiction and fact specific, and it is not something this article can settle. If your organisation has rules about copyleft in frontend bundles, route the LGPL-3.0 text past whoever owns that decision before you integrate, not after.

The Java core lives in a separate repository, and the README does not state its licence. Do not assume it matches. Check the licence file in tinyflow-java before depending on it.

On upgrades, the repository is wired for versioned releases. It uses Changesets with the GitHub changelog plugin and Turborepo, and the last push was on 2026-08-25, with the 1.3.7 packages published the same day. That tooling means each release carries a changelog entry, which is what you want when deciding whether to move.

The upgrade cost you should plan for is the frontend and backend version lines moving independently. Frontend packages are at 1.3.7 while the Java artifact is at 2.0.3. The README states no compatibility matrix between them, so an upgrade on one side is a change you should test against the other. Pin both versions explicitly rather than letting a range resolve to whatever is newest.

## Conclusion

Adopt Tinyflow if you already have a Java service and want a drag-and-drop agent editor inside an existing web app without rewriting the frontend in a new framework. Do not adopt it if you need a Python or Node.js execution backend today, since the README marks both as in development and not yet open. Before committing, verify the tinyflow-core 2.0.3 artifact resolves from Maven Central, confirm the provider interface covers your LLM and knowledge base, and check that the LGPL-3.0 terms fit how you distribute the built component.

## FAQ

### Which frontend frameworks does Tinyflow support?

The README states the frontend is built on Web Components, so it lists React, Vue, Angular and Svelte as supported, along with plain HTML, CSS and JavaScript. Published packages include @tinyflow-ai/ui, @tinyflow-ai/vue and @tinyflow-ai/svelte at version 1.3.7.

### How do I install Tinyflow in a project?

Install the UI package with npm install @tinyflow-ai/ui, then import the Tinyflow class and the stylesheet at @tinyflow-ai/ui/dist/index.css. Construct it with an element option pointing at a container, which can be a selector string or a DOM element.

### Does Tinyflow have a Python or Node.js backend for running workflows?

The README lists both, but marks each as under development and not yet open, and the releases in this repository are all frontend packages. The only backend the README points to for executing designed workflows is the Java project tinyflow-java, used through the dev.tinyflow:tinyflow-core artifact.

### What can I do with the workflow data after designing it in Tinyflow?

The instance exposes getData() to export the workflow data as a JSON object, and getOptions() to read back the initialization parameters. The README does not document the JSON schema or how the Java backend consumes it.

### What licence does Tinyflow use?

This repository is licensed under LGPL-3.0. The README does not state the licence of the separate tinyflow-java repository, so that needs checking independently.

## Sources

- [License: LGPL-3.0](https://github.com/tinyflow-ai/tinyflow/blob/main/LICENSE)
- [Project website](https://www.tinyflow.cn)
- [README](https://github.com/tinyflow-ai/tinyflow/blob/main/README.md)
- [Releases](https://github.com/tinyflow-ai/tinyflow/releases)
- [tinyflow-ai/tinyflow on GitHub](https://github.com/tinyflow-ai/tinyflow)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tinyflow-ai-tinyflow