Heym
Self-hosted AI workflow automation with agents, RAG, and MCP
44 followers
Self-hosted AI workflow automation with agents, RAG, and MCP
44 followers
Build AI workflow automations visually, with no coding required. Heym supports multi-agent orchestration, RAG pipelines, and MCP, plus a powerful AI builder for faster creation. Heym is a source-available, self-hosted AI workflow automation platform. It offers a visual canvas, many node types, multi-agent orchestration, RAG capabilities, HITL approvals, an MCP server/client, full LLM traces, and a portal that turns any workflow into a public chat UI. Ready to setup with no vendor lock-in.
Heym
Used to build a lot of workflows on n8n and after a point it started feeling like the workflows needed a number of extra systems around it just to make it reliable. Went through Heym’s docs and really liked the philosophy behind it. Agents, orchestration, traces, evals, RAG, HITL all being built into the workflow layer itself makes way more sense than bolting everything on separately later.
The orchestrator/sub-agent approach especially feels much cleaner for bigger workflows instead of endlessly stuffing context into one agent.
The Skills system is probably the part I’m most curious about. Reusable capability bundles across workflows/agents sounds incredibly powerful long term, but also feels like something where versioning could become important very quickly once multiple workflows depend on the same skill. Is there a versioning or rollback path for skills, or is managing that left to the developer?
Can already tell I’m going to build a lot with this!
Heym
@eshitakundu Really appreciate this. That n8n feeling is exactly the thing Heym is trying to avoid: once workflows become AI-heavy, the workflow layer has to own orchestration, traces, evals, RAG, HITL and review state instead of asking you to glue five systems around it later +1.
On Skills: today they are intentionally bundle-based. A skill is a SKILL.md instruction file plus optional Python files, resources, attached to an Agent node and exportable/importable as a zip. So the current rollback story is workflow-level and developer-controlled: skills live in the workflow/node state, Edit History can revert the workflow to an earlier saved version, and you can keep skill zips in Git or name/pin them with your own versions like research-pack.
What we do not have yet is a centralized skill registry with semver, dependency pinning and one-click rollback across every workflow that uses a skill. I agree that becomes important fast once teams start sharing skills. The direction that makes sense is explicit versioned skills where workflows pin a version, and upgrades are opt-in, so one skill edit does not silently change production workflows.
For a concrete example of a skill bundle in a workflow, this template is a good one: https://heym.run/templates/youtube-rss-csv-exporter
Skills docs are here too: https://github.com/heymrun/heym/blob/main/frontend/src/docs/content/nodes/agent-node.md#skills
Excited to see what you build with it.
@mbakgun Thanks for the detailed reply. The skills explanation genuinely helped me understand Heym’s direction a lot better, and the versioning approach makes sense for where the platform is right now.
While building a multi-agent research workflow, I ran into something with the MCP Call node. When connecting to Tavily’s MCP server, optional tool arguments that are left empty still get serialized as empty strings and sent to the server. Tavily’s pydantic validation rejects that because it expects actual typed values like enums, lists, and booleans instead of "", so the call fails even though those fields are intentionally unused.
I tried working around it by exporting the workflow JSON, manually removing the unused keys from toolArguments, and re-importing it. The fields disappeared from the UI, but the MCP call then started returning an authentication-related error, so I’m guessing something in the connection state or credential binding did not survive the round-trip properly.
Is there currently a proper way to omit optional MCP arguments entirely from the request payload? Or for stricter MCP servers like Tavily, is the better approach right now to just use an HTTP node instead?
Heym
@eshitakundu Thanks for the clear report. You’re right to treat this as an MCP Call node issue rather than a Tavily quirk.
At the moment, there is not a proper UI-level way to omit an optional MCP argument entirely from the MCP Call node payload. Empty optional fields can still end up in `toolArguments` as `""`, and strict servers such as Tavily throws an error.
Could you open a GitHub issue or discussion with a sanitized workflow JSON, the Tavily tool name, and the exact validation/auth error? Please remove API keys or tokens first. That would give us a reproducible case and help us fix MCP Call so blank optional args are omitted instead of sent as empty strings.
Issues: https://github.com/heymrun/heym/issues
Discussions: https://github.com/heymrun/heym/discussions
While we fix this, you can try the Agent node’s MCP client feature if you’d like; maybe the behavior is different there.
Heym
@eshitakundu @mbakgun Fixed with v0.0.32 thx for reporting the issue !
The human-in-the-loop checkpoints are what make this production-ready rather than just a demo tool , the most visual workflow builders skip that entirely. How does Heym handle a long-running agent that hits a review checkpoint at 2am -does it pause and wait, or time out?
Heym
@sailikhith It pauses and waits. Heym treats HITL as a persisted checkpoint, not an in-memory sleep: when the agent asks for review, the run is marked pending, a one-time /review/{token} link is created, and the full execution snapshot is stored.
So if it hits that checkpoint at 2 AM, the review branch can notify Slack/email/on-call immediately, while the normal path stays blocked. When someone reviews it later, they can accept, edit and continue, or refuse, then Heym resumes from the stored snapshot with the approved context.
There is a 168-hour TTL on the review link to avoid stale approvals, but it does not auto-approve or ship the output just because nobody woke up :)
Reference: https://github.com/heymrun/heym/blob/main/frontend/src/docs/content/reference/human-in-the-loop.md
OpenPlugin
the 'observability + execution traces in the same workflow' part is the unsung hero. most agent platforms treat traces as a debug afterthought, then your post-mortem on a failed run is just guessing. how granular are the events, every llm + tool call, or only at workflow boundaries?
Heym
@sebastian_sosa1 Great question — and yes, it's by design.
Heym traces at every individual LLM call, not at workflow boundaries. Each trace captures the exact node, full request/response payload, token counts, latency, and error. For agent nodes, every tool call in the chain is logged separately too.
So when a run fails, you open the trace viewer, find the exact node and the exact call — no guessing needed.
OpenPlugin
@ceren_kaya_akgun that's the right level. the next layer that surfaces once teams have call-level traces is correlating across runs, like 'this same agent call shape failed 8 times in the last week, here's the pattern.' how does heym handle aggregation/grouping over time? is there a recurring-trace-shape alert, or is it more on-demand investigation per-run?
Heym
@sebastian_sosa1 Yes , thank you & today Heym has two observability layers: call-level trace inspection and workflow-level analytics over time.
Every LLM/agent call is captured with request, response, tool calls, timing, token usage, workflow/node metadata, source, credential, model, and error state. The Analytics tab then aggregates execution count, success/error rate, latency, trends, and “most failed” workflows across windows like 24h, 7d, and 30d.
What we don’t ship yet is automatic recurring trace-shape clustering or a “this same agent-call shape failed 8 times this week” alert. Right now that part is more on-demand: use analytics to spot the workflow/node area, then filter/search traces and inspect representative runs.
That said, the raw ingredients are already there in the trace schema, so recurring-shape grouping is a natural next layer for us. I’d think of the current version as strong per-run debugging plus time-window workflow aggregation, with trace-shape alerts still ahead.
OpenPlugin
@ceren_kaya_akgun yeah, holding the alert until you have enough trace volume to tune clustering is the right call. the version that ships before it's ready ends up firing on every minor arg drift and people turn it off.
the self-hosted angle here is what makes it genuinely interesting — most workflow automation tools with RAG built in are SaaS-only and you just have to trust them with your data. being able to run this on your own infra changes who can actually use it, especially for teams in industries where data leaving the building is a non-starter. curious how the RAG setup works — do you bring your own vector DB or does it come bundled with one, and how much configuration does it need out of the box?
Heym
Thanks Priyanka, exactly. The self-hosted part is the main reason we built RAG this way.
Right now Heym is Qdrant-first: you point it at a Qdrant instance you control, either self-hosted or cloud, then Heym manages the collections, document uploads, chunking, embeddings, metadata filters, search, sharing, and optional Cohere reranking from the UI/workflow nodes.
Setup is pretty small: add a Qdrant credential with host, port, optional API key, and an OpenAI key for embeddings, create a vector store, upload PDFs/Markdown/TXT/CSV/JSON, then wire the RAG node into an LLM or Agent node.
We also have ready templates for both sides of the flow:
https://heym.run/templates/rag-document-ingest
https://heym.run/templates/rag-qa-agent
Really like the focus on solving actual workflow pain points instead of just adding AI features. Curious how Heym prevents context loss or agent drift during long-running multi-agent workflows?
Heym
@tejaswi_devalla Thanks Tejaswi, that is exactly the problem we are trying to design around. Heym does not treat long-running agent workflows as one giant prompt. The orchestrator delegates to named sub-agents with scoped prompts and explicit handoffs, so each agent only sees the context it needs.
For longer runs, Agent nodes automatically compress accumulated tool and message history when context usage approaches the model window, while preserving the system instructions, original task, and latest user intent. Agents can also use optional persistent memory, stored as a per-agent knowledge graph, and shared between agents when needed.
On the drift side, we keep the execution observable: tool calls, sub-agent outputs, timing, context compression events, traces, and HITL checkpoints are visible in the run history. So the pattern is: scoped delegation, explicit memory, automatic compression, and inspectable execution.
This template shows the orchestrator + sub-agent handoff pattern: https://heym.run/templates/research-writer-pipeline
Source is here too: https://github.com/heymrun/heym
Heym
Two weeks in : thank you, and here's what's new
325 GitHub stars in two weeks. We didn't expect that. Genuinely grateful to everyone who tried Heym, opened issues, patch security vulnerabilities , or just starred the repo.
Here's what we've been working on since launch:
We started publishing blog posts covering real workflow patterns and use cases
A template gallery is live so you can grab working workflows and customize from there.
And we added a video gallery for those who prefer to see things running before diving in.
If you haven't tried it yet, the repo is public and the setup is a single docker-compose up. We'd love feedback, bug reports, or just to hear what you're building.
heym.run · github.com/heymrun/heym