Why I built Heym instead of extending n8n

#ai #selfhosted #agents #automation

I've been building AI workflows for a while. And for a while, n8n was the right tool for the job.

Then the workflows started getting more complex.

Not in terms of the number of steps, but in terms of what the steps needed to do. Agents that reason and call tools. Document retrieval wired directly into the execution flow. Approval checkpoints before anything consequential happens. Full observability into what the model actually did, why, and when.

n8n wasn't designed for this. Neither was Zapier or Make. They were designed for deterministic, rule-based automation. Excellent at what they do. But the moment a workflow becomes AI-native, you're fighting the platform instead of building.

So I built Heym.

What Heym actually is

Heym is a self-hosted, source-available AI workflow automation platform. One runtime for everything an AI workflow needs: agents, retrieval, approval steps, observability, scheduling, and the ability to expose workflows as callable tools for AI assistants. Runs on your own infrastructure via Docker Compose. No data leaves your stack.

The execution model

The workflow engine builds a directed acyclic graph from the canvas and runs independent nodes concurrently with a thread pool. Streaming mode emits events as each node completes, so the frontend updates in real time.

Agent nodes have a full tool-calling loop. They can run Python tools, connect to external MCP servers, delegate to sub-agents, and call other workflows as tools. When context usage approaches 80% of the model window, the engine automatically compresses history so long-running agents don't silently fail mid-task.

Human-in-the-Loop as a first-class primitive

This is the feature I'm most opinionated about.

AI output has real consequences: drafted emails, generated reports, data transformations that feed into something downstream. The HITL node pauses execution at any point, generates a public one-time review URL, and waits. A reviewer can accept, edit, or refuse without needing a Heym account. Execution resumes from an exact stored snapshot. The same run can pause more than once.

It's not a workaround. It's a workflow design primitive.

Built-in knowledge retrieval

Document retrieval should be native to your workflow runtime, not a separate service you call via API. When retrieval is bolted on from outside, you get two systems to maintain, two places to debug, and no unified trace.

Heym has built-in vector store management. Upload documents, create stores, wire semantic search directly into your workflow. The full pipeline runs inside a single workflow and shows up in a single trace.

MCP Server

Every Heym instance runs a built-in MCP Server. Any workflow you build can be exposed as a tool that Claude Desktop, Cursor, or any MCP client can call directly. Agent nodes can also connect to external MCP servers as tool sources, so capabilities flow in both directions.

Observability

If you can't inspect what your AI workflow did, you can't trust it in production. The Traces tab logs every execution automatically. The Evals tab lets you create test suites and run evaluations across multiple models simultaneously with configurable scoring. This isn't bolted on — it's how we debug our own workflows.

Stack

Vue 3 with TypeScript and Vue Flow on the frontend, Python and FastAPI with async SQLAlchemy on the backend, PostgreSQL 16 for storage, all shipping as a Docker Compose stack.