agentkitchen.dev

The operator control plane for operating real multi-agent fleets.

Register agents, inspect liveness, dispatch work, broker A2A tasks, route memory, and keep a startup-sized agent society from becoming soup.

Demo

agentkitchen.dev is a dashboard and API surface for the part of agent systems that usually lives in scattered terminal tabs, notebooks, cron logs, local databases, and half-remembered shell scripts.

The Flow map gives operators a live topology of agents, infrastructure, memory, skills, and task paths.


Dispatch Send tasks to registered agents and inspect live delegation state.	Library Track knowledge files, memory health, freshness gaps, and collection growth.

APO review Approve self-learning proposals before they modify skills or agent instructions.	Ledger Watch memory, recall, audit, and operational signals from one place.

Want a video? A short demo recording is planned. Until then, the screenshots above are captured from the live local app and represent the intended operator experience.

Why Star This Repo

Star agentkitchen.dev if you are building agent systems that are moving from clever demos into daily operations.

You run more than one agent. Claude Code, Codex, OpenClaw, Hermes, Google ADK, LangGraph, CrewAI, AutoGen, custom HTTP workers: Kitchen gives them one roster.
You care where agents live. Local machine, VM, Tailscale host, Cloudflare tunnel, LAN box, cloud URL: the registry keeps location and reachability explicit.
You want standards without waiting for everyone. A2A is the preferred path; REST shims keep non-A2A agents useful today.
You need memory boundaries. Knowledge files, vector memory, graph memory, episodic memory, and audit logs are separated on purpose.
You want operator control. Registry writes, destructive actions, and self-learning proposals are gated instead of casually automated.
You believe agents need infrastructure. Not just prompts. Not just chat. A system of record.

What You Can Do In 5 Minutes

After setup, you can:

Open the Kitchen UI.
Register a local or remote agent.
See it appear in the canonical registry.
Send heartbeats, memory writes, or skill reports through REST.
Ingest an A2A agent card and dispatch a task.
Inspect memory and knowledge health from the Library.
Review APO proposals before they modify skills.

Release 0.1

v0.1.0 is the first public operator preview of agentkitchen.dev.

This release is intentionally focused on the control-plane foundation:

A Next.js operator console with the Flow, Registry, Dispatch, Library, Ledger, and Sous Vide surfaces.
A canonical SQLite-backed agent registry for REST, UI, and A2A-visible agents.
A2A card ingestion, task routes, streaming subscription endpoints, and Google ADK compatibility fixtures.
REST reporting endpoints for heartbeats, memory writes, skill reports, and tool outcomes.
Memory and knowledge visibility across configured file collections, mem0/Qdrant, graph memory, and Kitchen SQLite.
Human-gated Agent Lightning/APO approvals so self-learning proposals queue before they mutate agent instructions.

The aim is not to pretend this is a polished SaaS. It is a useful, inspectable, hackable starting point for people operating multiple agents across real machines.

What Kitchen Does

Canonical agent registry: SQLite-backed roster for local, REST, UI, and A2A agents.
A2A broker: Agent card discovery, JSON-RPC endpoints, task lifecycle routes, SSE task updates, and outbound A2A delegation.
REST shim: Framework-agnostic endpoints for agents that do not speak A2A yet.
Dispatch: Send work to registered agents and inspect live delegation history.
Flow map: Visual system topology for agents, memory, skills, dispatch, and infrastructure.
Knowledge Library: File counts, freshness alerts, collection maps, and growth trends for configured knowledge folders.
Memory routing: Vector memory through mem0/Qdrant, graph memory through Neo4j, and episodic/audit memory in Kitchen SQLite.
Progressive capability discovery: Tool-attention keeps optional systems such as GitNexus and Agent Lightning discoverable without loading every tool into every agent session.
APO review: Approve self-learning skill improvement proposals before they are applied.
Operator security: Operator-gated registry writes plus per-agent bearer keys for write/reporting endpoints.

What Kitchen Is Not

Not a replacement for Claude Code, Codex, OpenClaw, Hermes, Google ADK, LangGraph, CrewAI, or AutoGen.
Not a hosted SaaS control plane.
Not an excuse to expose your agents directly to the public internet.
Not finished. It is useful, hackable, and moving fast.

Kitchen is the operating layer between frameworks.

Architecture

Kitchen is intentionally thin at the boundary and durable at the center.

flowchart TB
  subgraph Fleet["Agent Fleet"]
    Claude["Claude Code"]
    Codex["Codex CLI"]
    ADK["Google ADK"]
    OpenClaw["OpenClaw"]
    Hermes["Hermes"]
    Custom["Custom HTTP agents"]
  end

  subgraph Kitchen["agentkitchen.dev"]
    UI["Operator UI"]
    Registry[("SQLite Registry")]
    A2A["A2A Broker"]
    REST["REST Shim"]
    Dispatch["Dispatch + Delegations"]
    Audit["Audit + Outcomes"]
  end

  subgraph Memory["Memory + Knowledge"]
    Vector["mem0 + Qdrant"]
    Graph["Neo4j Graph Memory"]
    Episodic[("SQLite Episodic Memory")]
    Library["Knowledge File Collections"]
  end

  subgraph Routing["Durable Coordination"]
    LangGraph["LangGraph Service"]
    Checkpoints[("Checkpoints")]
    HIL["Human Approval"]
  end

  Claude --> A2A
  Codex --> REST
  ADK --> A2A
  OpenClaw --> REST
  Hermes --> REST
  Custom --> REST

  A2A --> Registry
  REST --> Registry
  UI --> Registry
  UI --> Dispatch
  Dispatch --> A2A
  Dispatch --> REST
  REST --> Audit
  A2A --> Audit

  REST --> Vector
  REST --> Graph
  REST --> Episodic
  UI --> Library
  UI --> Memory

  Dispatch --> LangGraph
  LangGraph --> Checkpoints
  LangGraph --> HIL
  HIL --> UI

Data Flow

sequenceDiagram
  participant Agent
  participant Kitchen
  participant Registry
  participant Memory
  participant Operator
  participant Orchestrator

  Agent->>Kitchen: Register or present A2A card
  Kitchen->>Registry: Store identity, protocol, capabilities
  Agent->>Kitchen: Heartbeat / skill report / memory write
  Kitchen->>Registry: Update liveness and metadata
  Kitchen->>Memory: Route memory to vector, graph, or SQLite tier
  Operator->>Kitchen: Dispatch task
  Kitchen->>Registry: Resolve target agent
  alt Direct agent task
    Kitchen->>Agent: REST or A2A task request
  else Complex routed task
    Kitchen->>Orchestrator: Delegate with correlation id
    Orchestrator->>Operator: Human approval when needed
  end

Quickstart

Prerequisites

Node.js and npm
Python 3
Docker with Docker Compose
Optional: Qdrant Cloud URL and API key for vector memory
Optional: Tailscale for multi-machine private networking

git clone https://github.com/lac5q/agentkitchen.dev.git
cd agentkitchen.dev
npm install
./setup.sh --wizard
./setup.sh

Previously shared GitHub links to https://github.com/lac5q/agent-kitchen should continue to resolve through GitHub's repository rename redirect. Use the new agentkitchen.dev URL for fresh links so this project is not confused with similarly named repositories.

Open Kitchen:

http://localhost:3000

For a local production-style server:

npm --prefix apps/kitchen run build
KITCHEN_PUBLIC_BASE_URL=http://localhost:3002 \
KITCHEN_A2A_ENDPOINT_BASE_URL=http://localhost:3002 \
npm --prefix apps/kitchen run start -- --port 3002

Recommended Deployment

Kitchen is designed to start private and become public only when you mean it.

flowchart LR
  Founder["Founder laptop"] <--> Tailnet["Tailscale / private LAN"]
  Server["Kitchen server"] <--> Tailnet
  Agents["Agent machines"] <--> Tailnet
  Tailnet --> Auth["Operator key + per-agent bearer keys"]
  Auth --> Kitchen["agentkitchen.dev"]

Operating profiles:

local-dev: one developer machine; loopback registry writes can work without an operator key.
single-host: all services on one server or VM; operator key required.
private-network: recommended startup deployment for multiple machines on Tailscale or LAN.
cloud-https: internet-reachable deployment behind HTTPS reverse proxy or tunnel.
custom: operator-defined topology with explicit environment values.

See Install profiles.

Agent Registry

Kitchen has one canonical registry. The /agents page shows this DB-backed roster, not ad hoc files.

Register a REST agent

curl -X POST http://localhost:3000/api/agents/register \
  -H 'Content-Type: application/json' \
  -H 'x-kitchen-operator-key: <operator-key>' \
  -d '{
    "id": "worker-1",
    "name": "Worker 1",
    "role": "Research and implementation agent",
    "platform": "codex",
    "protocol": "rest",
    "location": "tailscale",
    "host": "agent.tailnet",
    "port": 8787,
    "healthEndpoint": "/health"
  }'

Register an A2A agent by card URL

curl -X POST http://localhost:3000/api/a2a/agents/register \
  -H 'Content-Type: application/json' \
  -H 'x-kitchen-operator-key: <operator-key>' \
  -d '{
    "cardUrl": "http://agent.tailnet:8000/.well-known/agent-card.json",
    "source": "a2a"
  }'

The response may include an API key unless issueApiKey is false. Store it securely. Kitchen never displays stored bearer tokens after creation.

One-command agent onboarding

For agents that can run shell commands, create a short-lived invite and hand the returned command to the agent. The invite registers the agent, mints its per-agent API key, and returns an agentkitchen.dev MCP config.

curl -X POST http://localhost:3000/api/onboarding/invite \
  -H 'Content-Type: application/json' \
  -H 'x-kitchen-operator-key: <operator-key>' \
  -d '{
    "agentId": "maria",
    "name": "Maria",
    "role": "Research and implementation partner",
    "platform": "openclaw",
    "ttlMinutes": 15
  }'

Give the command from the response to the agent. The command looks like:

curl -fsSL 'https://kitchen.example/api/onboarding/script?token=...' | bash -s -- --id 'maria' --name 'Maria' --role 'Research and implementation partner' --platform 'openclaw' --mcp-target 'auto'

The default --mcp-target auto selects the right installer from the platform: hermes, openclaw, claude, gemini, qwen, codex, or stdout for chatgpt. The bootstrap prefers each runtime's own MCP command when available and falls back to narrow config writes, so newer runtime installers can keep working without changing the invite command. Use --mcp-target file:/path/to/mcp.json, --mcp-target stdout, or AGENT_KITCHEN_MCP_TARGET=... to override. ChatGPT cannot run the shell command directly; for ChatGPT, use the returned mcpUrl as the custom connector URL in ChatGPT Apps & Connectors.

Add Agent Kitchen to ChatGPT

ChatGPT uses remote MCP over HTTP. Start the Agent Kitchen MCP facade and expose it through a trusted HTTPS URL such as Tailscale Funnel, Cloudflare Tunnel, or your own private gateway:

cd /path/to/agentkitchen.dev
KITCHEN_MCP_PUBLIC_BASE_URL=https://kitchen.example npm run install:mcp:chatgpt

The connector URL is:

https://kitchen.example/mcp

In ChatGPT, open Settings -> Connectors -> Advanced -> Developer mode, add a remote MCP server, name it Agent Kitchen, and use the /mcp URL above. The MCP facade exposes ChatGPT-compatible search and fetch tools, plus the richer Agent Kitchen tools for knowledge, memory, and progressive tool discovery when Developer mode allows arbitrary MCP tools.

The installer enables bearer-token auth by default and stores the token in ~/.agent-kitchen/com.agentkitchen.chatgpt-mcp.env. That is useful for Tailscale clients, API clients, and private testing. ChatGPT web custom connectors generally need OAuth or no-auth remote MCP, so do not put this on a public hostname unless an OAuth-capable proxy such as Cloudflare Access is enforcing access in front of it, or the exposed MCP profile is reduced to read-only public-safe search/fetch.

For a manual foreground server instead of the macOS LaunchAgent installer:

KITCHEN_MCP_PUBLIC_BASE_URL=https://kitchen.example \
KITCHEN_MCP_BEARER_TOKEN=<strong-random-token> \
./scripts/agentkitchen-mcp.sh --http --host 0.0.0.0 --port 8765

Add Agent Kitchen to Claude Desktop

Claude Desktop can run Agent Kitchen locally over stdio. Edit:

~/Library/Application Support/Claude/claude_desktop_config.json

Add or merge this server entry:

{
  "mcpServers": {
    "agentkitchen": {
      "command": "/bin/bash",
      "args": [
        "-lc",
        "exec \"${AGENT_KITCHEN_ROOT:-$HOME/github/agentkitchen.dev}/scripts/agentkitchen-mcp.sh\""
      ]
    }
  }
}

Fully quit and reopen Claude Desktop after saving the file. If your local clone is somewhere else, either set AGENT_KITCHEN_ROOT or replace $HOME/github/agentkitchen.dev with the absolute path to this repo.

If /agents shows fewer agents than expected, check:

The agent has been registered into the canonical registry.
Its host and port are real, not placeholders such as 100.x.x.x.
A2A agents expose a valid card URL.
REST agents have a health endpoint if you want remote reachability.

Protocol Strategy

flowchart TD
  Start["New agent"] --> Card{"Can expose A2A card?"}
  Card -->|Yes| A2A["Register via /api/a2a/agents/register"]
  Card -->|No| Rest["Register via /api/agents/register"]
  A2A --> Tasks["Use task lifecycle, streaming, card metadata"]
  Rest --> Shim["Use heartbeat, memory, skills, outcomes"]
  Shim --> Later["Upgrade to A2A when framework supports it"]

Use A2A when the framework can expose or consume an agent card and task lifecycle. This is the preferred path for standards-compatible agents such as Google ADK services and future A2A-native runtimes.

Use REST shim when the framework does not speak A2A yet or when you only need reporting: heartbeat, memory writes, skill outcomes, and registry visibility.

Memory and Knowledge

Kitchen keeps knowledge files and conversation memory separate on purpose.

flowchart LR
  subgraph Knowledge["Knowledge files"]
    Skills["skills"]
    Projects["projects"]
    Emails["emails"]
    Meetings["gdrive/meet-recordings"]
    AppleCalls["apple-notes/call-recordings"]
    Runtime["skill-runtimes"]
  end

  subgraph Memory["Memory entries"]
    Vector["Vector memory"]
    Graph["Graph memory"]
    Episodic["SQLite episodic memory"]
  end

  Knowledge --> Library["Library UI"]
  Memory --> Ledger["Ledger + Memory Intelligence"]

The Library counts .md, .mdx, and .txt files from configured collections. A collection can combine multiple source folders; meet-recordings includes both Google Drive transcripts and exported Apple Notes call recordings. Memory entries live in separate memory services and SQLite tables, so a collection file count is not the same thing as total memories.

Progressive Capabilities

agentkitchen.dev treats specialized systems as optional progressive capabilities. They can be checked during setup, shown in tool-attention, and recommended from outcome history without becoming required dependencies for every install.

Enable the current optional bundle with:

KITCHEN_OPTIONAL_CAPABILITIES=gitnexus,agent-lightning

Current bundled capabilities:

GitNexus: Kept as a separate MCP server, exposed through .mcp.json as mcp-server:gitnexus. agentkitchen.dev does not proxy or replace GitNexus; it catalogs the capability, reports status, and helps agents decide when to load it for code intelligence, impact analysis, and index health.
Agent Lightning/APO: Exposed in tool-attention as capability:agent-lightning. Kitchen owns the operator UI/API approval queue, while the worker CLI applies approved proposals and archives them for audit history.

This separation keeps each system's lifecycle clear: GitNexus owns code graphs and indexes, Agent Lightning owns self-learning proposal workflows, and Kitchen owns discovery, operator control, memory routing, and outcome signals.

Agent Lightning Approvals

Sous Vide approvals are intentionally two-step:

The UI/API approval moves the proposal into a durable approved/ work queue.
The worker CLI applies queued approvals and archives the proposal for audit history.

Qwen is the default executor assignment for this queue:

npm --prefix apps/kitchen run apo:worker -- --executor qwen

Use APO_APPROVAL_CLI=qwen to keep that default for scheduled runs, or pass --executor codex / --executor claude when you explicitly want a different CLI to own the implementation pass.

Security Model

Kitchen is built for private-network production first.

Registry writes require KITCHEN_OPERATOR_API_KEY outside local loopback.
Agent write/reporting endpoints require per-agent bearer credentials minted by the registry.
Memory read endpoints require operator authorization because they can expose sensitive context.
Prefer Tailscale or a private LAN for multi-machine startup deployments.
Use HTTPS and explicit operator keys for public or tunnel exposure.
Treat agent cards as untrusted input. Kitchen validates URL policy, payload size, required fields, and registration authorization.

Local URLs

Dashboard: http://localhost:3000
Production-style local server: http://localhost:3002
Registry UI: /agents
Dispatch UI: /dispatch
Flow UI: /flow
Library UI: /library
A2A card: /.well-known/agent-card.json

Development

npm run dev
npm run test
npm run lint
npm run build
npm run profiles:check
npm run first-run:check

Project Structure

agentkitchen.dev/
├── apps/kitchen/              # Next.js UI and API routes
├── services/orchestration/    # Python LangGraph orchestration service
├── services/memory/           # mem0 service wrapper
├── services/knowledge-mcp/    # Knowledge/tool-attention MCP facade
├── services/voice-server/     # Optional voice service
├── config/                    # Operating profiles
├── docker/                    # Service Dockerfiles
├── docs/                      # User and architecture docs
├── scripts/                   # Setup and validation scripts
└── data/                      # Local SQLite state, gitignored

Docs

Upcoming Features

Near-term focus after v0.1.0:

More A2A compatibility fixtures and interop tests.
Cleaner first-run onboarding for non-localhost deployments.
Better demo recording and hosted screenshot gallery.
More adapters for popular agent runtimes.
Hardened production profile examples for Tailscale, Docker, and HTTPS reverse proxies.

ClaudeClaw-inspired operator surfaces:

Chat tab: A dedicated command/chat workspace for speaking with CLIs, Paperclip project agents, runtime subagents, and the Kitchen system without burying chat inside the Flow page.
Memory search: First-class search across episodic SQLite recall, mem0/vector memory, graph memory, and knowledge files, with filters for agent, project, source, date, and memory tier.
Schedules and routines: A visible routines console for cron jobs, recurring agent checks, standing delegations, maintenance tasks, and approval-required automations.
Hivemind Obsidian view: An Obsidian-inspired graph/canvas view of agents, memories, tasks, proposals, skills, and backlinks so operators can browse the agent society as a living knowledge map.
Design-system completion: Finish the Paperclip-style visual migration across drawers, sheets, modals, detail panels, empty states, and error states so no screen falls back to the older dark dashboard shell.
Flow canvas redesign: Bring the React Flow topology, minimap, controls, node cards, edge styling, and node detail panels into the new Paperclip-style system while preserving graph readability.

Contributing

This project is early, but useful contributions are very welcome.

Good first contribution areas:

Add an adapter for an agent framework you use.
Improve setup docs for your deployment shape.
Add screenshots or recordings from a real multi-machine setup.
Add A2A compatibility fixtures.
Improve security tests around registry writes and memory reads.

If agentkitchen.dev helps you run more than one agent without losing the plot, please star the repo. It helps the project find the people building the same weird, useful future.

License

MIT. See LICENSE.

Name		Name	Last commit message	Last commit date
Latest commit History 498 Commits
.cursor		.cursor
.githooks		.githooks
.github/workflows		.github/workflows
.planning		.planning
apps/kitchen		apps/kitchen
config		config
docker		docker
docs		docs
examples		examples
scripts		scripts
services		services
.env.example		.env.example
.gitignore		.gitignore
.mcp.json		.mcp.json
AGENTS.md		AGENTS.md
CLAUDE.md		CLAUDE.md
LICENSE		LICENSE
README.md		README.md
agents.config.json		agents.config.json
collections.config.json		collections.config.json
docker-compose.yml		docker-compose.yml
package-lock.json		package-lock.json
package.json		package.json
setup.sh		setup.sh
start.sh		start.sh

Folders and files

Latest commit

History

Repository files navigation

agentkitchen.dev

Demo

Why Star This Repo

What You Can Do In 5 Minutes

Release 0.1

What Kitchen Does

What Kitchen Is Not

Architecture

Data Flow

Quickstart

Prerequisites

Recommended Deployment

Agent Registry

Register a REST agent

Register an A2A agent by card URL

One-command agent onboarding

Add Agent Kitchen to ChatGPT

Add Agent Kitchen to Claude Desktop

Protocol Strategy

Memory and Knowledge

Progressive Capabilities

Agent Lightning Approvals

Security Model

Local URLs

Development

Project Structure

Docs

Upcoming Features

Contributing

License

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages