engomez

Yes makes sense, the database site of it is the primary point we don't support yet. We want to do it in the way we think is best and will keep in mind how to make the experience good for existing Obsidian users.

Will take a look, appreciate it.

Ack ! We made the shorthand for e.g. the CLI and .ok/ configuration folders. Shouldn't show up in the UX strings, we'll clean that up.

Biased but great name of course haha.

OKF timing was coincidence, we'd started I take it around the same time they'd started internally.

What's good is that everything is pretty open formats/source and complimentary.

What we did to go "beyond" is build in skills and an MCP server into the app, and auto-install those into e.g. Claude, Codex, and Cursor formats. Also added a web viewer so that e.g. Claude Desktop can open up the editor directly within it's embedded web viewer.

are you linux or windows? if linux, which distro? Electron support for distros varies so input is appreciated.

Agree same. We'll look into explicit guides and integrations with Zed // OpenCode as a starting point, they let you choose your model.

Sweet, let me know the experience, we're actively thinking about how to make OKF KBs editing a good experience. E.g. a linter or other conformant mode.

Right now you'd simply prompt it. Working on more direct integration. Turns out they don't make event based back and forth easy.

Two bits:

1. Name collison happenstance. We'd locked in the npm package and domains prior to their announcement.

2. Our templates are Open Knowledge Format compliant and we have an explicit quickstart around making an OKF knowledge base. You can think of OKF as a format/standard for the content, and OpenKnowledge (our app) as an IDE/editor for any type of markdown based content.

Got it. MCP Server and CLI is agent-agnostic, so should work with local models/harnesses, but we'll look into more explicit docs around this.

What IDE or harness do you use? We'll take a look.

CLI + Web viewer are available for Linux and Windows. We tested it and works pretty well.

tl;dr: Slite supports import/export Markdown files, so not a native "interop".

Links: https://slite.slite.page/p/5XOO7_tII0D87T/Importing-Files, https://slite.slite.page/p/PxKfPvLrLHj07O/Exporting-Your-Doc...

Recommend trying it for some personal notes/specs/etc. -- can be used independently.

Since Obsidian is just markdown, you can just open an Obsidian vault with OpenKnowledge. We made it so that most Obsidian syntax is supported, like wikilinks.

For Notion, we don't have a migration tool, but you can try the export to markdown approach.

Recommend trying it to get a feel, and if are looking to migrate and facing friction let me know details.

Looking into Slite now to check. With OpenKnowledge, the content is just markdown files on-disk, so there shouldn't be anything exclusionary about it. Not sure how/if Slite handles markdown files. Will take a look.

They are arguably "fun", it's kind of like functional programming but in NLP. We found multi-agent systems to work well for workflows where there's lots of unstructured inputs. E.g. a "content writer" that takes resolved support tickets and turns them into an update against documentation if there's something novel to update. We tried that with a structured workflow and it didn't work very well/reliably, while a multi-agent approach worked well. For more traditional mostly deterministic workflows, I agree, there's no need.

The ids are stable in the dashboard -- users can't modify those.

But generally, for merge conflicts, the current recommendation is to do an `inkeep pull`into a separate 'scratch' project. We're working on more utils to make that case cleaner.

Apppreciate it and will add to tracked request. You should be able to use OpenRouter or the the Vercel AI Gateway.

Yeah I think so. With LangChain, LangFlow took off because it was the "no-code" n8n style version that was layered on top of LangChain. To me it was always frustrating that it wasn't one ecosystem // fully interoperable. We're looking to make sure there's a good solution that works in either modality for agents.

will add to the queue !

We're working on Inkeep Cloud which will have an accessible generous tier that's based on usage. You can get notified here: https://inkeep.com/cloud-waitlist. Our goal is to make Inkeep accessible to everyone.

We aim to be transparent with the fair-code approach by detailing that in the post, docs, readme. Our goal is to allow for broad usage for folks using it for building assistants, copilots, workflows, etc. while ensuring it can be economically viable for us long term.

We aim to be upfront with the fair-code approach by detailing that in the post, docs, etc. Our goal is to allow for broad usage for folks using it for building assistants, copilots, workflows, etc., while protecting against direct competitive use of the platform. This helps us guarantee we can continue to innovate.

For now -- more linear. n-player simultaneous edits with instant versioning for any edit is something we're working on.

You can always "pull" a project to a staging folder so you can resolve conflicts in code manually if someone made changes in visual while you made changes in code.

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

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.

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.

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.

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.

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.