Launch HN: Inkeep (YC W23) – Open Source Agent Builder

18 comments

·October 16, 2025

Hi HN! I'm Nick from Inkeep. We built an agent builder with true 2-way sync between code and a drag-and-drop visual editor, so devs and non-devs can collaborate on the same agents. Here’s a demo video: https://go.inkeep.com/video.

As a developer, the flow is: 1) Build AI Chat Assistants or AI Workflows with the TypeScript SDK 2) Run `inkeep push` from your CLI to publish 3)Edit agents in the visual builder (or hand off to non-technical teams) 4) Run `inkeep pull to edit in code again.

We built this because we wanted the accessibility of no-code workflow builders (n8n, Zapier), but the flexibility and devex of code-based agent frameworks (LangGraph, Mastra). We also wanted first-class support for chat assistants with interactive UIs, not just workflows. OpenAI got close, but you can only do a one-time export from visual builder to code and there’s vendor lock-in.

How I've used it: I bootstrapped a few agents for our marketing and sales teams, then was able to hand off so they can maintain and create their own agents. This has enabled us to adopt agents across technical and non-technical roles in our company on a single platform.

To try it, here’s the quickstart: https://go.inkeep.com/quickstart.

We leaned on open protocols to make it easy to use agents anywhere: An MCP endpoint, so agents can be used from Cursor/Claude/ChatGPT A Chat UI library with interactive elements you can customize in React An API endpoint compatible with the Vercel AI SDK `useChat` hook Support for Agent2Agent (A2A) so they work with other agent ecosystems

We made some practical templates like a customer_support, deep_research, and docs_assistant. Deployment is easy with Vercel/Docker with a fair-code license and there's a traces UI and OTEL logs for observability.

Under the hood, we went all-in on a multi-agent architecture. Agents are made up of LLMs, MCPs, and agent-to-agent relationships. We’ve found this approach to be easier to maintain and more flexible than traditional “if/else” approaches for complex workflows.

The interoperability works because the SDK and visual builder share a common underlying representation, and the Inkeep CLI bridges it with a mix of LLMs and TypeScript syntactic sugar. Details in our docs: https://docs.inkeep.com.

We’re open to ideas and contributions! And would love to hear about your experience building agents - what works, hasn’t worked, what’s promising?

Visit

r0b05

This is not an open source application. Here is the definition of open source should you wish to correct your post - https://opensource.org/osd

yujzgzc

My experience building agents is that the "main loop" of the framework is really not the hard part, and too much time gets devoted to framework picking. It reminds me a lot of early web application days, stuff feels at the level of PHP and WordPress in their attempt to simplify things, when in reality we still need low level stuff a lot of time and the framework gets in the way.

engomez

Generally agree, we're targeting teams who need to make agents accessible to both their developers and non-developers in one platform. There's not really a way to do that as far as I know in any other framework. That said, I do find with multi-agent systems, having good abstraction layers makes things like observability, tracing, etc. cleaner. When the LLMs are driving the execution, normalizing on how the LLMs interact with each other can simplify the stack.

thedevilslawyer

Fake "Open source" all over again.. why do we repeatedly have to do this? You can own the "Fair source" and call it that.

I was excited with the pitch. And then had this completely ruin your image. If you'd been upfront, then you could still have retained the interest.

esafak

Since this is for people who can't code, I'd make sure the debugging capabilities are beefed up. Otherwise what's going to happen when the code doesn't work? This is the whole problem with no code tools. Does the visualization help here? If not, what do the visuals add; why not stick with a simple text prompt?

engomez

Agree. The visual builder has a live tracer that shows visually the state of the execution, which can be helpful (even as an engineer). Working on other debugging utilities.

That said - for devs, you still get the TypeScript representation, so you can always interface with the system that way if you prefer.

endymion-light

Genuine question, what makes this more effective than something like N8n? Right now i'm not seeing what I could achieve within Inkeep that I couldn't on N8n. Less being snide and more being genuinely curious

engomez

Good question! Main things: n8n you can't export to code (or import). It's all visual, so you don't get CI/CD, typesafety, etc. when you want it. That can be fine if visual is all you need.

Architecturally, n8n is good for deterministic workflows and adding some LLM nodes for data transformations and tool calling, but because their system is not truly multi-agent, then a) it's not good for conversational experiences like chatbots or copilots and b) agents can't actually go back and forth with each other to solve problems with a shared conversation history, etc.

endymion-light

Great, thank you, that makes the benefits stand out a lot to me.

engomez

You got it. Feel free to shoot us over any feedback - nick @inkeep.com.

thesandlord

Is this primarily for building chat based agents? What if I want to trigger a workflow via API or webhook and the wait for some sort of human in the loop verification? Do you have an example for something like that?

The visual UI + code is really cool, addresses the weaknesses of both approaches.

engomez

Both work - Agents can be triggered via API just like any normal process, so they will go do the work async and post the result via e.g. an MCP of your choice to Slack, backend forms, etc. We don't have a built-in human-in-loop orchestration layer just yet, but since each execution has a conversation thread, you could orchestrate a way for your human-in-loop process to simply submit a new message with whatever was sent. Basically using the messaging as the event queue system.

That said, yes, we deal with a lot of customer support use cases so conversational experiences were a top priority for us. It's nice to be able to interact with an agent as a workflow or conversationally.

rvz

This is not "open source" at all.

It looks like OpenAI really has messed around with the definition of "Open" and we are seeing lots of startups run with that to the point where the definition is meaningless.

Just like "AGI" is also meaningless.

d0100

How does it compare to OpenAI agents builder?

inkeep isn't open source with a Elastic License 2.0, why not just go with OpenAI agents sdk (MIT)?

engomez

We made a good video about the differences between n8n, OpenAI, and Inkeep here: https://youtu.be/tRgU5FQoe3s. Short overview.

Re:OpenAI agents builder - there is a hard one-time ejection to code. You can export to their TypeScript or Python SDKs (in some limited use cases), but it's a one-way fork. Their visual canvas is meant to stay visual canvas.

Their SDK is open source -- it's basically for calling the OpenAI APIs downstream. But their visual builder / orchestration layer is not.

nextworddev

Was expecting MIT license but disappointed. If not there’s plenty of established “OSS” options.

xpe

The opening line from the video [1] impressed me:

> We built an agent builder with true two-way sync between code and a drag-and-drop visual editor.

Wow, what a clear pitch. I like it.

At the same time, I think about design space between Visual/DAG editors (here, a directed graph of agent workflows) versus, say, a high level textual configuration format (a la Dockerfiles).

- I think back ... how many visual tools have I been excited by [2] [3] [4] [5] [6], only to find that I usually prefer the textual editing most of the time? There are certainly cases where the visual editors really catch on. But on the other hand, when it comes to the programming world, it seems like the configuration format approach works more often.

- What do customers want here? (I don't have any particular expertise here) In my footnoted examples, my guess is that visual tools catch on the best when the target audience has a deep physical, even tactile, connection to the domain rather than a preference for textual representations.

Personally, I really like both. I like being able to quickly edit and share text files and also switch to a visualization. But it can be hard to make the visualization capture the necessary details without too much clutter.

All in all, delivering on two-way sync between code and visual editors might be hard. Hard is not necessarily bad. Delighting customers on both fronts could be a competitive advantage, for sure. [7]

I know this comment could be better organized, sorry about that. This is a "thinking out loud comment"... I haven't even touched on the "no code" and "low code" angle to it. I'd be happy to hear from others on their experiences.

[1]: https://www.youtube.com/watch?v=4FuEnAEPqwU

[2] Tools like SAS Enterprise Miner (https://www.sas.com/en_us/software/enterprise-miner.html) or Orange Data Mining: Visual Programming: (https://orangedatamining.com/home/visual-programming/)

[3]: Max for Live (integrated with Ableton for sound design)

[4]: LabVIEW (used for electrical engineering)

[5]: Various visual SQL Schema editors

[6]: Graphical views of document linkages: e.g. Obsidian, The Brain (going way back)

[7]: It may be difficult in achieve parity between the different capabilities of each. It seems to me many applications recognize that full parity isn't practical and instead let each "view" do what it does best. Traditionally, the visual approaches help with the top-level view and the code versions get into the details.

engomez

Yes! This is what I struggled with prior. A Multi-agent system makes a lot of sense to the person who wired it up, less so to other people, even when looking at just code. We architected the SDK so it feels like a declarative ORM - similar to Drizzle for databases. In a way, it is a DSL, just in TypeScript, so you get full typesafety and devex of an IDE.

Being able to handle off and give the same system to other engineers or non-engineers in a visual format for them to own and edit makes it easy to make these agents portable and explainable.