Hexabot v3: an AI workflow runtime that puts YAML, actions and channels in one process

What Hexabot v3 actually replaces

Most chatbot stacks end up as three separate things: a workflow engine, a set of channel integrations, and a pile of prompt or tool code that nobody validates. Hexabot v3's pitch is that these live in one runtime. The README describes it as "an automation platform with first-class AI capabilities, combining workflows, actions, and conversational channels in one runtime."

The intended audience is a team that already knows it wants agentic behaviour (tools, memory, retrieval) but does not want to hand-roll the orchestration. The repository topics list agent, agentic, llm, chatbot and workflow alongside specific model names such as ollama, mistral and llama, which suggests the project expects you to bring your own model rather than accept one.

It is not a hosted product you sign up for. The Quick Start is entirely local: install a CLI, generate a project, run a dev server. That framing matters, because it means the adoption cost is a Node.js environment and a package manager, not a vendor contract.

The mechanism: YAML workflows, typed actions, bindings

The architectural claim in the README is schema-first. Zod is used broadly for validation and shared contracts, and actions are described as defining workflow behaviour with "schema-validated inputs/outputs/settings." In practice that means the boundary between a workflow step and the code behind it is a typed contract, not a convention.

The second piece is the binding system. The README calls it "reusable capability/config bindings separated from task logic." That separation is the interesting design choice: a workflow references a capability, and the binding decides which concrete configuration or credential satisfies it. You can point the same workflow at a different model or channel configuration without editing the workflow itself.

Memory and MCP are first-class concepts rather than add-ons. The README lists "explicit memory definitions and runtime memory integration" and "Model Context Protocol support for tool/context interoperability." Channels and helpers remain core concepts, so a single workflow is meant to be reachable from more than one conversational surface.

The data layer is TypeORM, with SQLite as the default local option and Postgres described as first-class for production. Runtime database configuration goes through DB_TYPE and the DB_* variables. Nothing in the README suggests a separate migration service; migrations are exposed through the CLI as hexabot migrate.

Installing Hexabot and running a first project

The prerequisites are narrow: Node.js ^24.17.0, one package manager (npm, pnpm, yarn or bun), and Docker only if you want Docker-based services. The Quick Start explicitly targets projects generated with the CLI, and tells contributors working on the monorepo itself to use PNPM instead.

Install the CLI globally, or skip the global install and call it through npx:

npm install -g @hexabot-ai/cli

Then generate a project. The create command auto-detects your package manager, and you can force one with --pm:

hexabot create my-project --pm npm
cd my-project
hexabot dev

One constraint to plan around: hexabot create prompts for initial admin credentials and requires an interactive terminal (TTY). The README states that in CI or non-interactive shells you should run it from a local terminal first. There is no documented non-interactive flag to bypass the prompt.

Once the dev server is up, the default local endpoints are the Admin UI at http://localhost:3000, the API at http://localhost:3000/api, and API docs at http://localhost:3000/docs (non-production only). If you prefer containers, hexabot dev accepts --docker and --services, and hexabot start adds --build for production-style runs. The CLI also exposes hexabot env init, hexabot check, hexabot config show and hexabot migrate.

Where Hexabot gets in the way

The interactive-only project creation is the first real friction point, and it is not a minor one. Any team that treats environment provisioning as a pipeline step will hit it immediately, because the documented workaround is a human running the command locally. The README does not document a flag or environment variable that supplies admin credentials non-interactively.

Node.js ^24.17.0 is a strict floor. That is a recent major line, and it rules out hosts pinned to an older LTS release unless you are willing to move the runtime. The README does not describe a supported older version.

The release history is worth reading carefully before you assume stability. The most recent release listed is v2.2.2 from 2025-01-24, while the monorepo package.json declares version 3.5.0 and the README describes v3 throughout. That gap is consistent with v3 being published through the CLI and pre-release channels rather than through the tagged releases shown, but the README does not explain the versioning scheme, and a reader comparing the two will be confused. Treat the release list as incomplete evidence about v3's maturity rather than as a statement that v3 is unreleased.

Finally, the licence is FCL-1.0-ALv2. That is not a standard OSI identifier, and the README defers entirely to LICENSE.md for terms. If your organisation has an allowlist of licences, this one will need a manual read.

How it differs from a general bot framework

The closest comparison in the search data is Tiledesk, which is a conversational platform with its own visual flow builder and a hosted option. The difference in approach is where the definition of a flow lives. Tiledesk centres on a design-time canvas that non-developers can edit. Hexabot v3 centres on YAML workflow definitions with typed runtime contracts, which means the flow is a file you can diff, review and keep in version control.

That trade-off cuts both ways. A YAML-defined workflow is easier to review and to test, and it fits teams that already treat configuration as code. It is harder to hand to a support agent who wants to drag boxes around. If your organisation's bottleneck is non-technical authoring rather than engineering review, a canvas-first tool will get you further faster.

The second comparison is with wiring an LLM directly into an existing application. That works until you need memory, multiple channels and tool interoperability, at which point you are rebuilding the parts Hexabot already names: bindings, memory definitions and MCP integration points. The cost of Hexabot is the runtime and the Node.js floor; the cost of the alternative is the code you write to replace it.

Maintenance, upgrades and the licence question

The repository is not archived, and the last push was on 2026-08-24, which puts it inside the six-month window. That is the only maintenance signal available here; the README does not publish a support policy or a deprecation schedule.

Upgrades run through the CLI. hexabot migrate takes arguments and is the documented path for schema changes, which matters because TypeORM backs the data layer and the README gives no separate migration tool. hexabot check and hexabot config show exist for inspecting state, but the README does not document rollback, so plan a database backup before running migrations against Postgres.

The monorepo uses PNPM 11.8.0 as its package manager and Turbo for task running, with scripts for lint, test, typecheck and format. If you fork or contribute rather than consume the CLI, that is the toolchain you inherit. Note the distinction the README draws: generated projects can use any package manager, the monorepo itself expects PNPM.

On licensing, the code is under FCL-1.0-ALv2, copyright Hexastack. The README points to LICENSE.md for full terms and says nothing about what the FCL prefix implies for commercial use, redistribution or modification. That is a question for whoever reads licences at your organisation, not something the README answers.

Editorial conclusion

Adopt Hexabot if you want agentic workflows expressed as YAML with schema-validated actions, and you are comfortable on Node.js 24.17.0 or later with the CLI driving project creation. Do not adopt it if you need a non-interactive install path today: hexabot create requires an interactive terminal, and the README points CI users back to a local terminal first. Before committing, verify two things yourself: the FCL-1.0-ALv2 terms in LICENSE.md, since the licence is not an OSI identifier the tooling recognises, and whether the Postgres path with DB_TYPE and the DB_* variables matches your production setup, because SQLite is only the default local option.

Frequently asked questions

Official sources

1. hexabot-ai/Hexabot on GitHub
2. Issues
3. Project website
4. README
5. Releases