Inkeep Agents: a visual builder and TypeScript SDK with two-way sync

What Inkeep Agents is for, and who ends up using it

Most agent frameworks force a choice at the start. Either the agent lives in code, and every prompt tweak becomes a pull request, or it lives in a hosted builder, and the definition never enters your repository. Inkeep Agents is built around the claim that you do not have to pick. The README describes a No-Code Visual Builder and a TypeScript Agents SDK that are "fully interoperable", with the agents-cli providing `inkeep push` and `inkeep pull` to move definitions between the two.

The intended audience is a mixed team. The README names customer experience agents for help centers and technical docs, internal copilots for support, sales, marketing and ops, and workflow automation such as updating knowledge bases or triaging helpdesk tickets. In each of those, the person who knows the content is rarely the person who writes the deployment code. That is the gap the two-way sync is meant to close, and it is the only reason to accept the operational weight described further down.

The service split: agents-api, manage-ui, sdk, cli, ui

The repository is a pnpm and turbo monorepo, and the README breaks the platform into five named pieces. agents-api is the center of the system: a REST API that handles configuration of Agents, Sub Agents, MCP Servers, Credentials and Projects, exposes agent execution and evaluation, tracks conversation state, and emits OpenTelemetry traces. agents-manage-ui is the Visual Builder web interface, and it writes to agents-api. agents-sdk is the TypeScript package `@inkeep/agents-sdk`, which also writes to agents-api rather than to a local file. agents-cli holds the sync utilities. agents-ui is a chat component library for embedding the result in a web app.

That arrangement explains the sync. The API is the source of truth, so the canvas and the SDK are two clients of the same store, not two formats being converted. It also explains a dependency you should notice before you start: an agent defined in TypeScript is not usable until it has been pushed to a running agents-api. The SDK is a declarative client, not an offline runtime.

Underneath, the README states the framework uses the Vercel AI SDK for interfacing with LLM providers, so it is compatible with Vercel's `useChat` hook. Agents can be triggered via MCP, A2A and Vercel SDK APIs.

Installing the self-hosted stack and pushing a first agent

The README points to the docs and a 1-minute quick start rather than inline install steps, so treat what follows as the shape of the setup rather than a complete walkthrough. The repository ships a root `docker-compose.yml` that defines the two main services with pinned images, plus `.env.example` as the configuration template. The compose file expects `ANTHROPIC_API_KEY`, `OPENAI_API_KEY` and other provider keys to be present in the environment, and it wires the management UI to the API over an internal URL.

Start by copying the environment template and filling in at least one provider key, since agent execution requires one.

cp .env.example .env
# then edit .env and set ANTHROPIC_API_KEY or OPENAI_API_KEY

The compose file exposes the management UI on port 3000 and the API on port 3002, so the defaults in `.env.example` line up with `INKEEP_AGENTS_API_URL=http://localhost:3002`.

docker compose up

After that, `http://localhost:3000` is where the Visual Builder runs. The README's SDK example is the smallest useful agent definition, and it shows the two pieces you will write most often: a sub-agent with a prompt, and a parent agent that lists it.

import { agent, subAgent } from "@inkeep/agents-sdk";
import { consoleMcp } from "./mcp";

const helloAgent = subAgent({
  id: "hello-agent",
  name: "Hello Agent",
  description: "Says hello",
  canUse: () => [consoleMcp],
  prompt: `Reply to the user and console log "hello world"`,
});

export const basicAgent = agent({
  id: "basic-agent",
  name: "Basic Agent",
  description: "A basic agent",
  defaultSubAgent: helloAgent,
  subAgents: () => [helloAgent],
});

Note that `canUse` and `subAgents` are functions returning arrays, not plain arrays. To get that definition into the running API, the README names the CLI command `inkeep push`, with `inkeep pull` as its counterpart. After a push, the agent should appear in the Visual Builder at the same id, which is the practical test that the sync is working.

The dependency footprint is the real adoption cost

The compose stack is not a single container. Reading `docker-compose.yml` and `.env.example` together, the API talks to a Doltgres database for management data at port 5432 and a separate PostgreSQL database for run data at 5433, and it points at a SpiceDB instance for authorization. The management UI additionally expects Nango for credential management and SigNoz for traces, both configurable through environment variables such as `NANGO_SERVER_URL` and `PUBLIC_SIGNOZ_URL`.

That is a deliberate design: versioned agent configuration, separate conversation state, relationship-based permissions and OpenTelemetry traces are all things a team deploying agents in production eventually wants. But it is a lot of moving parts for someone who wants to try a prompt. The repository does include alternative compose files, including `docker-compose.visual.yml` and `docker-compose.isolated.yml`, which suggests the maintainers are aware that not every setup needs the full set. The README does not document what each variant omits, so you will be reading the files to find out.

The second constraint is architectural. Because agents-api is the source of truth, there is no supported path in the README for running a defined agent without it. If your deployment model is a serverless function that imports a config object, this is the wrong shape.

Elastic License 2.0 and the supplemental terms

The README states the framework is licensed under the Elastic License 2.0, subject to Inkeep's Supplemental Terms in `SUPPLEMENTAL_TERMS.md`, and calls it fair-code and source-available. The root `package.json` sets `"license": "SEE LICENSE IN LICENSE.md"`, and the repository root also carries a `LICENSE_MANAGEMENT.md` file, so the licence text is not a single line you can skim.

For an evaluator the practical distinction is that ELv2 is not an OSI-approved open source licence. It permits broad use while restricting certain competitive uses, in Inkeep's words. The supplemental terms are the part that could matter to a company building a product on top of this, because they can narrow what the base licence allows. I am not going to characterise what they permit; read `SUPPLEMENTAL_TERMS.md` and, if the answer affects revenue, have counsel read it. What is clear from the repository is that self-hosting your own agents on your own infrastructure is the stated intent, and the README explicitly says the project is designed to be extensible, to work with the LLM provider of your choice, and to be deployed and self-hosted in your own infra.

Where Inkeep Agents is the wrong tool

The two-way sync is the feature that justifies the platform, and it is also where the sharpest risk sits. A definition edited on the canvas and a definition edited in TypeScript are the same record, which means a `inkeep pull` can overwrite local code and a `inkeep push` can overwrite canvas edits. The README does not document conflict resolution, a merge strategy, or a rollback for a sync that goes the wrong way. Teams that treat the SDK files as reviewed source of truth should decide before adopting whether an uncommitted canvas edit landing in their repository is acceptable, and should check what `inkeep pull` does to a locally modified file.

The second mismatch is scale. If your need is a single retrieval-augmented chatbot over one documentation site, the multi-agent architecture, the credential broker and the traces backend are overhead. The README's own use cases are plural by design: teams of agents, multi-agent workflows, several knowledge sources. A one-agent deployment gets little from the platform layer.

The third is provider and runtime lock-in at the edges. The README states the framework uses the Vercel AI SDK under the hood. That is a real dependency on another project's abstractions and release cadence, even though it buys compatibility with `useChat` and other AI primitives.

How it differs from n8n and from a bare SDK

People searching for this kind of tool often arrive from n8n, so the comparison is worth making concrete. n8n is a general workflow automation tool: you wire nodes together, and the unit of work is a step in a process that may have nothing to do with language models. Inkeep Agents is narrower and deeper. The unit is an agent with a prompt, a set of MCP tools it is allowed to use through `canUse`, and a place in a sub-agent hierarchy. The canvas exists to edit that agent, not to draw an arbitrary process, and the same definition is expressible in TypeScript. If your task is moving data between SaaS systems with an LLM call in the middle, n8n's model fits better. If your task is a support assistant that several people need to tune, Inkeep's model fits better.

The other comparison is against using the Vercel AI SDK directly. That gives you full control over prompts and no platform to run, at the cost of building credential storage, tracing, a chat UI and an editing surface yourself. Inkeep Agents packages those, and charges for them in services to operate and in licence terms.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-09, which is recent. The most recent tagged releases listed are v0.68.4, v0.68.3 and v0.68.2, all dated 2026-04-15, so tags lag the main branch by roughly five months. The project is still on 0.x versions, which usually means the API surface can move without a major-version signal.

The compose file pins container images at a specific version, `inkeep/agents-manage-ui:0.80.4` and `inkeep/agents-api:0.80.4`, which is higher than the newest tag in the release list. That gap is worth checking before you plan an upgrade: if you deploy from the pinned images, your running version and the repository's tagged releases are not the same thing. The monorepo also carries changesets configuration and a `patches/` directory, so upgrades may involve dependency patches you inherit.

Upgrade cost is dominated by the databases rather than the application code. Doltgres and PostgreSQL hold management and run state respectively, and SpiceDB holds authorization relationships. A schema change in agents-api can require coordinated migration across them, and the README does not describe a migration or downgrade procedure. Plan for the stack, not just the container.

Editorial conclusion

Adopt Inkeep Agents if you want one agent definition that a support lead can edit on a canvas and an engineer can edit in TypeScript, and you are willing to run the Docker stack yourself. Skip it if you need a permissive OSI licence, or if a single prompt-driven chatbot already covers your case. Before committing, read SUPPLEMENTAL_TERMS.md against your own product plans, and confirm that the Visual Builder and SDK round-trip cleanly on your own agent definitions, since the README describes full 2-way sync but does not document a rollback path for a bad sync.

Frequently asked questions

Official sources

1. inkeep/agents on GitHub
2. Issues
3. Project website
4. README
5. Releases