Hexabot v3: YAML Workflows, Actions, and Channels in One Runtime

The problem Hexabot solves is workflow sprawl, not chatbot authoring

Most conversational AI projects start as a single bot answering messages on one channel. Then someone wants the same logic on a second channel, someone else wants a tool call inserted before the reply, and the reply path slowly becomes a pile of conditionals inside a request handler. Hexabot's answer is to separate the pieces. The README describes the project as an automation platform combining workflows, actions, and conversational channels in one runtime, and the core capability list names agentic workflows, action-based execution, a binding system, memory support, MCP integration points and multi-channel continuity as distinct concerns. That separation is the actual product. If your problem is one bot on one channel, Hexabot is more structure than you need. The intended user is a team building automation that has to survive a second channel and a third tool, where the workflow definition should be reviewable as a file rather than reconstructed from handler code. The TypeScript and Zod emphasis points at that reader specifically: someone who wants shared contracts between the workflow layer and the runtime, not a drag-and-drop builder.

Actions carry the schema, bindings carry the configuration

The mechanism worth understanding before adopting is the split between actions and bindings. According to the README, actions define workflow behaviour with schema-validated inputs, outputs and settings, and the binding system holds reusable capability and configuration bindings separated from task logic. Read that together and you get a picture of the runtime: a workflow file references actions, each action declares what it accepts and produces, and the environment-specific wiring lives in bindings instead of inside the action. That is the difference between a workflow you can promote from staging to production and one you have to edit per environment. The schema-first claim is backed by the README's note that Zod is used broadly for validation and shared contracts, which means a malformed workflow should fail at a defined boundary rather than midway through a conversation. Memory is handled the same way, as explicit memory definitions plus runtime integration, rather than an implicit conversation buffer. MCP integration points are listed as a capability, not described in the README, so how tool and context interoperability is actually wired is something you would need to confirm in the documentation site. The README does not spell out the workflow execution engine, so treat any assumption about scheduling, retries or concurrency as unverified until you read docs.hexabot.ai.

Getting a project running takes three commands and a TTY

The Quick Start is short and the commands are literal. Install the CLI globally with `npm install -g @hexabot-ai/cli`, or skip the install and run `npx @hexabot-ai/cli --help`. Then `hexabot create my-project`, `cd my-project`, `hexabot dev`. The README notes that `hexabot create` auto-detects your package manager and that you can force one with `--pm`, for example `hexabot create my-project --pm npm`. The constraint that will bite people in automation is stated plainly: `hexabot create` prompts for initial admin credentials and requires an interactive terminal, so in CI or non-interactive shells you have to run it from a local terminal first. Node.js `^24.17.0` is required, and Docker is optional for Docker-based services. Default local endpoints are the admin UI and API at `http://localhost:3000`, with API docs at `http://localhost:3000/docs` in non-production. The CLI surface beyond that includes `hexabot start`, `hexabot stop --docker`, `hexabot env <init|list>`, `hexabot check`, `hexabot config <show|set>` and `hexabot migrate`. On the data side, TypeORM is the standard backend, SQLite is the default local option, Postgres is described as first-class for production, and runtime configuration goes through `DB_TYPE` and `DB_*` variables. If you are contributing to the monorepo rather than a generated project, the README points you at PNPM and CONTRIBUTING.md.

The release list and the v3 claim do not line up

This is the first thing to resolve, and the README does not resolve it. The repository's most recent releases are v2.2.2 from 2025-01-24, v2.1.5 from 2024-12-10 and v2.0.2 from 2024-10-27. The README and the repository description both describe Hexabot v3, and the last push to the default branch is dated 2026-08-24. So the v3 material is newer than every tagged release shown. That does not mean v3 is unreleased, but it does mean the tags you can see do not correspond to the version the documentation is written for. If you pin dependencies or vendor a release, you need to find out where the v3 code actually lives before you build a deployment plan around it. The README's own framing supports a second reading too: it distinguishes projects generated with the CLI from the monorepo itself, and directs monorepo contributors to a separate document. A generated project and the monorepo are two different surfaces with two different package managers, and the release tags may track one more closely than the other.

Where Hexabot is the wrong tool

Two failure modes are visible from the material. The first is the non-interactive scaffold. Because `hexabot create` requires a TTY and prompts for admin credentials, a pipeline that provisions a fresh environment from scratch cannot complete the documented setup path unattended. You can work around it by preparing a project locally and committing it, but that is a different workflow than the one the README describes, and it means your generated project becomes an artifact you maintain rather than something the CLI reproduces. The second is the runtime requirement. Node.js `^24.17.0` is not a caret range most production fleets are already on, so adopting Hexabot may pull a Node upgrade across whatever else shares that host. Beyond those, the honest limitation is documentation depth in this README. MCP integration points are named as a bullet and not explained. The binding system is described in one sentence. Memory definitions are mentioned without a format. None of that is a defect in the project, but it does mean the README is a map, not the territory, and the actual answers are on docs.hexabot.ai. If your evaluation stops at the repository page, you will not have enough to judge whether the workflow engine fits your use case.

Against a general-purpose agent framework

The nearest comparison is a general-purpose agent framework where you write the orchestration in application code and the agent loop lives in your process. The difference in approach is where the definition sits. In that model, the workflow is TypeScript you import, and changing the order of steps is a code change. In Hexabot, the workflow is a YAML definition with typed runtime contracts, and actions are the units it composes, each with schema-validated inputs, outputs and settings. That shifts review to a file diff and shifts environment differences into bindings rather than branches in code. The cost is a layer of indirection: you are learning Hexabot's action and binding vocabulary instead of writing plain functions, and anything the action model does not express becomes a fight with the framework. The benefit appears when the same workflow has to run across multiple channels, which is the case Hexabot is built around and the case where hand-rolled orchestration usually starts leaking channel-specific conditionals. If your automation is single-channel and short-lived, the framework layer is overhead. If it is multi-channel and long-lived, the YAML plus action contract is the part you would otherwise end up building badly.

Licence and maintenance cost

The licence field for this repository is NOASSERTION, and the README states the project is licensed under FCL-1.0-ALv2, with full terms in LICENSE.md. Those two signals disagree in the sense that an automated classifier could not map the licence text to a known identifier, which usually means the terms are custom or modified. I am not going to characterise what FCL-1.0-ALv2 permits, because the README does not summarise it and I have not read the file. Read LICENSE.md yourself before you build a commercial product on this, and if the terms are unclear to you, that is a question for someone qualified to answer it. On maintenance, the material supports a limited statement. The default branch was pushed on 2026-08-24, so the repository is active. The published release tags stop at v2.2.2 in January 2025, so the tagged release cadence visible here is not the same as the commit cadence. Upgrading means tracking a branch rather than a tag unless you find v3 tags elsewhere. Two CLI commands are relevant to that cost: `hexabot check` for validating a project, and `hexabot migrate` for schema or data migrations, which implies the data layer is expected to change shape between versions. Budget for running both when you move.

Editorial conclusion

Adopt Hexabot if you want workflow behaviour expressed as versioned YAML with Zod-validated action contracts, and you are willing to run Node.js ^24.17.0 and read the FCL-1.0-ALv2 terms yourself before shipping anything commercial. Do not adopt it if you need a project scaffolded from a non-interactive CI shell, or if you expect the v3 line to be the one tagged in the repository's published releases. Verify three things first: whether the FCL-1.0-ALv2 text in LICENSE.md permits your intended use, which branch or tag actually carries the v3 code you are reading about, and whether `hexabot check` passes on the project `hexabot create` generates on your machine.

Official sources

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