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.
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.
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.
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.
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.
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.