This two-way sync is slick—saves us from the usual “designer broke prod” dance. One edge case: if a non-tech user renames a sub-agent in the visual builder while a dev still references the old ID in TypeScript, do you:

automatically rewrite the TS file on the next pull, or surface a merge conflict and let the dev hand-fix? Curious how deep the refactor detection goes.

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.

I think we are going through the langchain era for agents. the world will look really different in couple month and the stack will be wildly different and more unified.

> true 2-way sync between code and a drag-and-drop visual editor...

EXACTLY what was missing in many tools, and exactly what is required for reducing the time from quick prototype to production quality code.

Congrats on the launch. Looking forward to trying this out. Please add support for AWS Bedrock based models.

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)?

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.

The Git-style workflow is super clever. How do teams typically collaborate around it? For example, can multiple people work on different branches of the same agent (visual and code), or is the sync more linear?

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

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?

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.

I started to follow documentation here (https://docs.inkeep.com/self-hosting/docker-local) to run things with Docker.

-> connect to the locally installed instance of SigNoz

-> It asks for an email -> when I type it, it says: "This account does not exist. To create a new account, contact your admin to get an invite link"

-> But I am the admin :'), also tried to create an account there https://signoz.io/

-> but they refuse personal Github or Gmail accounts for now.

Conclusion

So it's literally impossible to run your app for a 'normal person' running their own server :(

Or maybe I missed a step :/

I see "Get a demo" as the only call-to-action and a bunch of other venture-backed Saas startups as your customers...so I'm guessing pricing will be...high.

This might sound vaguely pessimistic, but I'm getting the nagging feeling lately that we might be inflating a ponzi scheme of B2B saas selling exclusively to other B2B saas companies for niche B2B saas use cases.

In earlier generations of Saas the assumption was you land and expand from there to wider markets. But this seems so specifically tailored to the needs of other VC-funded B2B Saas companies...

As the things that fall under [vibe code-able in 1 hour] expands, at what point does building platforms like this for semi-technical B2B Saas employees not make sense any more?

Like, if you're smart enough to figure out an agent that connects the OpenAI API to the Zendesk API can automate something...at what point do you just set it up yourself instead of dealing with the sales vultures at [insert YC startup] and also fighting your own internal procurement process...just so you might be able to have that agent running in 1-6 months?

In enterprise I can totally see value in having help during setup and an external throat to choke when things go wrong, but at that point, isn't that a consulting agency masquerading as a Saas platform?

[stub for offtopicness]

(ok you guys, we've taken 'open source' out of the title, let's talk about something more interesting now)