Inkeep Agents: A TypeScript SDK and Visual Builder Sharing One Agent Definition
Create AI Agents in a No-Code Visual Builder or TypeScript SDK with full 2-way sync. For shipping AI assistants and multi-agent AI workflows.
At a glance
- What is it?
- Inkeep Agents is a TypeScript framework plus a drag-and-drop canvas that write to the same agents-api over a two-way sync. It fits teams that want code-first agent definitions without locking non-engineers out of editing them.
- Who is it for?
- Adopt Inkeep Agents if you want agent definitions in TypeScript and a non-engineer teammate editing the same agents on a canvas, and you accept a source-available licence with supplemental terms. Do not adopt it if you need a permissive OSI licence or a framework that runs entirely offline from a single binary.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The split between who writes the agent and who edits it
Agent definitions usually live in one of two places. In code, where an engineer can review the diff, run it through CI, and keep it in version control. Or in a hosted builder, where a support lead can change a prompt without opening a pull request. Choosing one means the other group waits.
Inkeep Agents targets that split directly. The README states that agents can be edited in either the Visual Builder or the TypeScript SDK with full two-way sync, so technical and non-technical teams can create and manage agents in one platform. The stated audience is teams shipping AI chat assistants (a customer experience agent for a help center, an internal copilot for support or sales) and teams automating workflows (updating knowledge bases, triaging helpdesk tickets, updating CRMs).
The claim worth scrutinising is the word full. Two-way sync between a typed source file and a database-backed canvas is a hard problem, and the README does not describe how conflicts are resolved. More on that below.
agents-api is the single writer, and everything else is a client
The architecture section lists five pieces. agents-api handles configuration of Agents, Sub Agents, MCP Servers, Credentials, and Projects over a REST API, and also exposes agent execution and evaluation. It tracks conversation state and emits OTEL traces. agents-manage-ui is the Visual Builder and writes to agents-api. agents-sdk is the TypeScript package and also writes to agents-api. agents-cli holds utilities including inkeep push and inkeep pull, which sync SDK code with the Visual Builder. agents-ui is a chat component library for embedding the result in a web app.
That is the whole design in one line: the API is the source of truth at runtime, and both the canvas and the SDK are front ends onto it. The sync is therefore not peer-to-peer between a file and a database. It is a pull and push against a REST service, which is a simpler shape than the phrase two-way sync suggests.
Underneath, the framework uses the Vercel AI SDK to talk to LLM providers. The README notes this makes it compatible with Vercel's useChat hook. That is a real constraint as well as a feature: your provider options are whatever the Vercel AI SDK supports, not a bespoke list Inkeep maintains.
What an agent looks like in the SDK
The README's example is short enough to read in full. It imports agent and subAgent from @inkeep/agents-sdk and consoleMcp from a local ./mcp file, then declares a subAgent with id, name, description, a canUse callback returning the MCP tool list, and a prompt. The top-level agent declares a defaultSubAgent and a subAgents callback returning the same sub-agent.
Two things stand out. First, subAgents and canUse are functions, not arrays. They are evaluated lazily, which is what lets one sub-agent reference another without a circular import blowing up at module load. Second, the multi-agent story is built into the primitive: an agent has a default sub-agent and a set of sub-agents, so routing between them is a first-class concept rather than something you assemble from tool calls.
MCP is the tool interface. The README lists MCP Tools with credential management as a platform feature, and the same MCP surface is exposed outward: agents can be triggered via MCP, A2A, and Vercel SDK APIs. Credentials are managed in agents-api alongside the agent configuration, which is why they appear in the API's list of managed resources.
Getting a project running: the commands the material actually names
The README points at a quick start under docs.inkeep.com/get-started/quick-start and does not inline the install steps, so the only commands I can state with confidence are the two the architecture section names: inkeep push and inkeep pull, both from agents-cli, which move SDK code to the Visual Builder and back.
What is confirmable about setup: the SDK package is @inkeep/agents-sdk, imported in TypeScript. The API is a REST service that stores agents, sub-agents, MCP servers, credentials, and projects, so a running instance has to exist before push or pull means anything. Deployment is described as easy via Vercel or Docker, and self-hosting in your own infrastructure is an explicit goal. The manage UI writes to the same API.
Everything past that (environment variable names, the Docker image tag, how credentials are supplied to the API) is not in the supplied material. Treat the quick start page as required reading rather than optional; the repository layout tells you the pieces exist but not how they are wired for a local run.
The two-way sync is the feature and the risk
Here is the case where Inkeep Agents is the wrong tool. If your agent prompts are part of a regulated change process, or if you need every prompt change to arrive as a reviewed pull request, a canvas that writes directly to agents-api routes around that process. The sync runs in both directions by design. A non-engineer editing a prompt in the builder changes state that the next inkeep pull will bring into your working tree, and the README does not describe a review gate, a diff preview, or a conflict policy.
Consider the concrete sequence: an engineer edits a prompt in TypeScript and pushes. Before that push lands, a colleague edits the same prompt in the Visual Builder. The README's claim of full two-way sync does not say which side wins, whether the loser is recoverable, or whether the CLI refuses the operation. Until you test that round trip yourself, treat the builder as an editing surface for agents whose prompts are not under strict change control, and keep the ones that are in code only.
The second limitation is the licence. The README states the framework is under the Elastic License 2.0 subject to Inkeep's Supplemental Terms, described as fair-code and source-available, allowing broad usage while protecting against certain competitive uses. That is not an OSI-approved open source licence, and the repository's licence field reads NOASSERTION. If your organisation has a policy against source-available licences, or if you intend to offer a competing hosted agent platform, read SUPPLEMENTAL_TERMS.md before writing any code. I am not giving legal advice; the point is that the terms file, not the README summary, is the document that governs you.
How this differs from LangGraph or a plain Vercel AI SDK app
The nearest comparison for the code side is LangGraph, which also models multi-agent workflows as a graph in code. The difference is where the definition lives. A LangGraph graph is a Python or TypeScript program and nothing else edits it; there is no second surface. Inkeep Agents puts a REST API between the definition and both editors, which is what makes the canvas possible and also what makes the sync question unavoidable. If your team is all engineers and you never want a non-engineer touching a prompt, that API layer buys you nothing and costs you a service to run.
The other comparison is a plain app built directly on the Vercel AI SDK. Inkeep Agents uses that SDK underneath, so you are not choosing a different model layer, you are choosing whether to take the configuration API, the manage UI, the CLI sync, the traces UI, and the chat component library along with it. A team of two engineers with one agent and no non-technical collaborators gets more from the raw SDK. The Inkeep layer starts paying for itself when the number of agents, the number of people editing them, or the number of MCP tools crosses the point where hand-maintained configuration stops being readable.
Upgrade and maintenance surface
The release history shows a fast cadence: three patch releases on 2026-04-15 alone, at v0.68.2, v0.68.3, and v0.68.4, with the most recent push to main dated 2026-09-09. A 0.x version line with same-day patches tells you the API is still moving. Pin your @inkeep/agents-sdk version and read the release notes before bumping, because the SDK is the surface you write against and the agents-api is the surface it talks to; a version skew between them is the failure mode to watch for.
Self-hosting shifts the operational cost onto you. You are running agents-api, the manage UI, and whatever backs conversation state. The API emits OTEL traces, so if you already have an OpenTelemetry collector the observability path is shorter than standing up a new one. If you do not, the Traces UI is the alternative, and the README does not say whether it requires a separate service.
On licence cost: ELv2 with supplemental terms is free to use under those terms, and the README points to Inkeep Cloud and Inkeep Enterprise for teams that would rather not self-host. The decision is not price, it is whether the supplemental terms fit your intended use. Read them.
Editorial conclusion
Adopt Inkeep Agents if you want agent definitions in TypeScript and a non-engineer teammate editing the same agents on a canvas, and you accept a source-available licence with supplemental terms. Do not adopt it if you need a permissive OSI licence or a framework that runs entirely offline from a single binary. Before committing, read SUPPLEMENTAL_TERMS.md in full, confirm which LLM providers you need and whether the Vercel AI SDK path covers them, and run one round trip with inkeep push and inkeep pull on a throwaway project to see how the sync resolves a conflict between a code edit and a canvas edit.
Community notes