{"slug": "what-we-learned-building-heym-for-production-ai-workflows", "title": "What We Learned Building Heym for Production AI Workflows", "summary": "Heym, a source-available platform for building AI workflows, announced new capabilities including RAG synchronization, multi-instance execution, OIDC single sign-on, and execution inspection. The updates address production challenges such as document changes, scaling across machines, and integration with existing identity providers, aiming to make AI workflows more inspectable and reliable beyond the demo stage.", "body_md": "AI workflow demos are easy.\n\nConnect a model to a prompt, add a tool, run it once, and the result looks impressive.\n\nProduction is where the harder questions begin.\n\nWhat happens when a document changes in your knowledge base? Can a second machine take over the heavy workflows? Can your team use its existing identity provider? When something fails after three retries, can you see what actually happened?\n\nThese are the questions shaping [Heym](https://heym.run), a source-available and self-hostable platform for building AI workflows on a visual canvas.\n\nThe latest set of releases make that direction clearer. We have been working on RAG synchronization, multi-instance execution, OIDC single sign-on, execution inspection, and more practical browser automation.\n\nAt the same time, our recent writing has focused on the less comfortable side of AI agents: governance, sandboxing, specifications, and the difference between having a feature and having evidence that it works.\n\nHeym is an AI-native workflow automation platform built around LLMs, agents, RAG, browser automation, and MCP.\n\nYou can connect nodes on a visual canvas, generate workflows with an AI assistant, attach tools and skills to agents, and run independent branches in parallel.\n\nThe same workflow can then be called from:\n\nThe important part is not only building the graph. Heym also keeps the execution history, LLM traces, token usage, costs, logs, evaluations, and outputs around that graph.\n\nWe think an AI workflow should be inspectable after it leaves the demo environment.\n\nThe newest RAG release adds **Upsert** and **Delete** operations to the RAG and Vector Store node.\n\nA workflow can now address a document using an identifier from the source system, such as:\n\nThis is different from depending on the vector database's internal point ID.\n\nWhen an upsert runs, Heym removes the existing chunks associated with that document ID before writing the new version. This prevents an updated document from appearing beside its outdated chunks.\n\nDelete uses the same external identifier and returns a normal result even when the document does not exist.\n\nMetadata also supports expressions. A workflow can store values such as a source URL, customer ID, or category directly from an earlier node while preserving the original data type.\n\nBoth operations work with Qdrant and PostgreSQL with pgvector.\n\nThis turns RAG from a one-time ingestion task into a synchronization workflow.\n\nYou can read the [RAG node documentation](https://heym.run/docs/nodes/rag-node) for the complete configuration.\n\nAI workflows tend to be uneven.\n\nA webhook that transforms JSON may finish in milliseconds. A browser automation or multi-agent workflow can occupy a machine for much longer.\n\nHeym can now distribute background executions across multiple instances connected to the same PostgreSQL database.\n\nYou can start another instance as a worker and assign execution weights from the settings panel. PostgreSQL carries the work, so workers do not need to expose a port or communicate directly with the main instance.\n\nPlacement is also explicit.\n\nWorkflows that depend on local files, installed plugins, coding-agent workspaces, or a fixed outbound IP remain on the main instance. Compute-heavy work that does not depend on local state can move to workers.\n\nExecution history records which instance ran each workflow, and the history interface can filter runs by instance.\n\nThat makes horizontal scaling visible instead of turning it into infrastructure hidden behind the application.\n\nMore details are available in the [load distribution documentation](https://heym.run/docs/reference/cluster).\n\nTeams can now connect Heym to any OpenID Connect provider.\n\nAn administrator enters the issuer URL, and Heym discovers the provider's authorization, token, and signing-key endpoints.\n\nThe same configuration works with providers such as:\n\nAdministrators can restrict automatic account creation to approved email domains and test the connection before disabling password login.\n\nWe also keep workforce identity separate from agent credentials.\n\nOIDC answers how a person signs in to Heym. It does not answer which credentials a workflow should use when calling a database, CRM, or external API. Those are separate security boundaries and should be managed separately.\n\nThe [SSO documentation](https://heym.run/docs/reference/sso) covers the setup and safety checks.\n\nWhen a workflow fails, a red node is not enough.\n\nThe execution timeline now includes a span details inspector. Selecting a span shows:\n\nThis keeps the investigation connected to the timeline. You can identify the slow or failed step, inspect its output, and follow its trace without reopening several different panels.\n\nFor AI workflows, observability is not an optional dashboard. Model calls are probabilistic, tool calls touch external systems, and retries can change both latency and cost.\n\nThe details are described in the [execution history documentation](https://heym.run/docs/reference/execution-history).\n\nHeym's Playwright node supports deterministic steps and AI-generated browser actions.\n\nRecent additions make those AI steps easier to operate:\n\nThe design we prefer is hybrid.\n\nUse deterministic browser steps for navigation and stable selectors. Use an AI step only for the part of the page that genuinely changes. Save the generated action, replay it, and validate the extracted result.\n\nThis idea is explored in our article, [AI Web Scraping: Read the Page Once, Not Every Run](https://heym.run/blog/ai-web-scraping).\n\nOur recent blog posts are not release announcements. They document the questions that appeared while building the product.\n\nEvery enterprise platform can say that it supports SSO, audit logs, and horizontal scaling.\n\nThe more useful questions are concrete:\n\nIn [Enterprise AI Agents: Everyone Passes the Checklist](https://heym.run/blog/enterprise-ai-agents), we applied that checklist to Heym and published the gaps as well as the capabilities.\n\nAn agent inventory tells you how many agents exist. It does not tell you whether they are controlled.\n\nOur [AI Agent Governance](https://heym.run/blog/ai-agent-governance) article reduces the problem to four questions:\n\nThe first two produce records. The last two require enforceable controls.\n\nThat distinction matters because a policy saying an agent should not delete production data is not the same as a system refusing the delete operation.\n\nWe also reviewed how coding agents followed our own repository instructions across more than a thousand commits.\n\nThe result was not simply that longer specifications worked or failed.\n\nRules naming a specific file, a destination, and a forbidden pattern were followed much more consistently than broad rules such as keeping every component below a certain size.\n\nThe lesson from [Spec Driven Development: What Our Agents Ignored](https://heym.run/blog/spec-driven-development) was simple: if a rule cannot be evaluated during one edit, it probably needs an automated check.\n\nOur article [AI Agent Sandbox: We Shipped the Bug First](https://heym.run/blog/ai-agent-sandbox) came from an uncomfortable place.\n\nAfter discovering that one code execution path did not use the isolation we expected, we stopped treating sandbox configuration as evidence.\n\nFor the Code node, we ran a probe through the real execution path and checked what the container could actually see:\n\nA sandbox controls where code can reach. It does not decide whether the action should have been allowed in the first place. Isolation, authorization, and human approval remain separate mechanisms.\n\nThe direction is straightforward.\n\nWe want building an AI workflow to feel visual and fast, while operating it remains explicit.\n\nThat means combining:\n\nThe goal is not to hide complexity behind an agent.\n\nThe goal is to make that complexity visible at the points where a developer or operator needs to make a decision.\n\nHeym is self-hostable, and the repository is available on [GitHub](https://github.com/heymrun/heym).\n\nYou can try it locally with:\n\n```\nbash\ngit clone https://github.com/heymrun/heym.git\ncd heym\n./run.sh\n```\n\n", "url": "https://wpnews.pro/news/what-we-learned-building-heym-for-production-ai-workflows", "canonical_source": "https://dev.to/mbakgun/what-we-learned-building-heym-for-production-ai-workflows-5d1o", "published_at": "2026-09-02 17:47:27+00:00", "updated_at": "2026-09-02 17:53:51.870874+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-tools", "developer-tools", "ai-agents", "mlops"], "entities": ["Heym", "Qdrant", "PostgreSQL", "OpenID Connect"], "alternates": {"html": "https://wpnews.pro/news/what-we-learned-building-heym-for-production-ai-workflows", "markdown": "https://wpnews.pro/news/what-we-learned-building-heym-for-production-ai-workflows.md", "text": "https://wpnews.pro/news/what-we-learned-building-heym-for-production-ai-workflows.txt", "jsonld": "https://wpnews.pro/news/what-we-learned-building-heym-for-production-ai-workflows.jsonld"}}