Self-hosted · Grok · Claude · OpenAI · Apache-2.0

Your data. Your agents. Any model.

OperationKit is an agent-powered board that runs on your server. Your data stays on your disk. Your agents and skill files are plain markdown you keep. Works natively with Grok, Claude, and OpenAI. Point at any model, any time.

Read the setup guide Star on GitHub
own your data own agent + skill files Grok · Claude · OpenAI teams + workspaces mobile objectives board

The heart of it

Agents you build, bring, and own.

Every agent is a plain file. Write your own in a guided flow, bring one you already have, and run it on whatever model you choose. Nothing is trapped in a vendor's format.

Build an agent in a guided flow.

Describe what you want an agent to do, and a guided builder turns it into a persona: its role, its rules, the skills and tools it can reach. The result is a markdown file you read, edit, and version like any other.

A guided interview, not a config form. You answer questions, it writes the agent.
Every agent is markdown you own and can change at any time.
Roadmap  Record your screen doing a task, and the builder drafts an agent that can run it.
~/ai-workspace/agents/researcher.md
# a persona is just a file you own name: Research Analyst skills: web-search, deep-research, kb model: claude-opus-4-8 # swappable # edit it, version it, branch it. # no locked schema, no vendor UI

Bring agents you already have.

Build an agent and it is a file. Bring one from somewhere else and it is a file too. Because every persona is plain markdown, your agents move between tools instead of locking you into one.

Agents are portable markdown, not bound to one vendor's format.
Roadmap  One-click import that converts a Claude Code or Codex agent into OperationKit's format.
Roadmap  A shared library of community agents you pull from by file. Open, not a walled store.
bring-an-agent
# agents are files. bring your own. $ cp ~/.claude/agents/reviewer.md \ ~/ai-workspace/agents/ ✓ reviewer ready to run # roadmap: one-click import + convert # roadmap: pull from a shared library

Future-proof

Run on any model, now and next.

Claude, OpenAI, and Grok work natively out of the box. Point at Gemini, Ollama, or any other provider via LiteLLM with no rewrite, no migration. Your agents and knowledge load from your own files first, so they behave the same regardless of what's running underneath.

Pick the model. Keep your context.

Run a task on Claude or OpenAI, and switch between them mid-flight with one click. Whichever model runs the job, your personas and your knowledge base load from your own files first. Your context travels with the work instead of living in a vendor's platform.

Choose the model per task, and hot-swap engines without losing the thread.
Personas and second-brain context load the same way across every model.
No lock-in. Your agents and knowledge are markdown you own, not a provider feature.
objective · engine
# switch the engine mid-task model: claude-opus-4-8 ⇄ gpt-5.5 ✓ persona loaded from your files ✓ knowledge second-brain, either way ✓ auth your own subscription

A review gate that runs your app.

Work an agent produces goes to a second, fresh-context agent that grades it against acceptance criteria locked before the work began. It auto-iterates on failures and tracks its own false-pass rate, so the gate's accuracy is something you can measure. It is how features like Loops ship without a human re-reading every line.

Fresh-context, adversarial review against criteria locked before work starts.
Auto-iterates up to three times, then escalates to a human when it cannot.
Tracks its own false-pass rate, so you know whether the validator actually validates.
In active development  Expanding to run every change in a live, fresh-seeded preview.
harness · review
# fresh context · criteria locked up front PASS renders-clean PASS data-persists FAIL empty-state-edge → rework false-pass rate: tracked # is it real?

Run it anywhere

From your phone, or on its own.

It runs on your server, but you do not have to sit at one. Drive it from your pocket, or set it to run without you.

From your phone

The whole system is built for a phone screen. Spawn work, watch a live session, and run your operation from anywhere.

Web terminal

A real shell into the box, from your laptop or your phone. It is your server, with nothing hidden behind a vendor console.

Autonomous jobs

Schedule an agent to run on its own. Set a job on a cron, and it runs, files its results, and reports back without you.

Messaging Roadmap

Drive it from the apps you already live in. Two-way control over Telegram and WhatsApp is on the roadmap.

Portable by design

Your knowledge comes with you.

Everything OperationKit knows is plain markdown on your disk. Read it, grep it, back it up, and take it to the next machine or the next model.

Second brain

A markdown knowledge base your agents search and ground every answer in. Your decisions, playbooks, and notes stay plain files, not rows in a vector database you cannot read.

auto-read into every agent session

Files & docs

Browse and edit the same files your agents read and write, from a built-in editor. Markdown on disk, scoped per workspace so teams and clients never cross.

the filesystem your agents work in

Built-in context intelligence

Agents that remember what matters.

Most agent systems dump everything into the context window and hope for the best. OperationKit assembles context deliberately — the right knowledge, in the right order, every session.

A four-tier instruction stack.

Each session loads context from the outside in — global rules, then the agent's persona, then your workspace's business context, then the specific user's preferences. High-confidence signal arrives first, so a late-loaded KB snippet can never override a stable rule.

Global → agent → workspace → user. Each tier narrows the frame without conflicting with the tier above it.
Position matters. Research shows relevant information buried in the middle of a long context degrades model performance. We front-load the signal.
Every tier is a file you own. Edit, version, and audit exactly what goes into every session — no black box.
context assembled at session spawn
── tier 1: global ────────────────────────── ~/.claude/CLAUDE.md # routing ── tier 2: agent persona ──────────────────── agents/cto.md # role + skills ── tier 3: workspace overlay ──────────────── workspaces/acme/context.md # biz context ── tier 4: user profile ───────────────────── users/sarah/profile.md # tone + prefs ── dynamic ────────────────────────────────── ↳ objective memory # this task's history ↳ vault KB hits # relevant decisions ↳ failure modes # what went wrong before

Working memory. Long-term memory. Both.

Human memory isn't one thing — there's what you're thinking about right now, and what you know from experience. Agent memory shouldn't be one thing either. OperationKit keeps them separate and connects them deliberately.

Objective memory persists a scratchpad across every session on the same task — surviving restarts, account rotations, and model switches.
The vault is your long-term knowledge base — decisions, research, playbooks — queryable by every agent session, linked back to the board task that produced them.
Skills are procedural memory — how to do things, not what to do. An agent loads skills, doesn't infer them from a similarity search.
Read the full architecture →
memory types
working memory objective-memory/<id>/NOTES.md # persists across every session on # this task. survives restarts. long-term memory second-brain/workspaces/acme/ # decisions, research, playbooks. # every doc links back to the board. procedural memory skills/domain-management/SKILL.md # declared, validated, graph-checked. # not inferred. not stale.

And it's yours

Own the whole stack, end to end.

Your knowledge, your agents, your infrastructure. OperationKit runs on hardware you control, and every part of it is yours to read, audit, and take with you.

Plain files, not a black box. Every agent's memory is markdown you can open, grep, and back up. If you ever leave, your data walks out with you.

Your infrastructure, your keys. Nothing routes through a third-party orchestration cloud, and nothing trains on your work.

Any model, so the system outlasts whichever one you use today. The context is yours; the engine is a choice you can change.

An honest note on security.

The core runs many agents executing shell on a shared host. That is a real blast radius, and we say so plainly. Today's isolation is per-session git worktrees plus a pre-write guard hook. It stops the common cross-session mistake. It is not a security sandbox.

Per-agent container isolation is on the roadmap, not shipped. Until then, run OperationKit on a dedicated, disposable host with only the credentials it needs. We document the sharp edges instead of hiding them.

The heart of the operation

The objectives board.

Every piece of work is an objective on the board: planning, working, review, done. Status comes from the live agent process, not the agent's word for it. Spawn one objective or a hundred; each runs in its own isolated session.

Kanban for agent work

Cards move through planning → working → review → done. Each card is a live session with a terminal you can watch in real time, from your laptop or your phone.

live status from the process, not the agent's claim

Teams and workspaces

Create a workspace per team or client. Users, objectives, files, and credentials stay scoped to their workspace. Nothing crosses. Invite teammates; each gets their own board view.

multi-tenant from day one

Delegator mode

One objective fans out into up to five worker sub-agents, each isolated in its own git worktree and reviewed before it merges back.

Loops

Track the open threads of your work: who you owe, who you're waiting on. Pulled from meetings onto a board with a daily nudge.

Autonomous jobs

Schedule an agent to run on its own. Set a cron, and it runs, files its results, and reports back without you.

Guided, documented, flexible

See the whole thing work.

The setup is guided, the docs are real, and the system bends to how you work instead of boxing you in. That is the part most open-source agent platforms skip. The self-hosting guide takes you from an empty server to a running system.

Read the setup guide Star on GitHub

Why not just use a hosted product?

Hosted coding agents are excellent. Use one if it fits. OperationKit exists for what a vendor cloud cannot serve:

Your work and your data never leave your infrastructure. Everything runs on a host you control. Nothing is sent to a third-party orchestration cloud.

One system, not ten tabs. Your knowledge, loops, contacts, files, and agents share the same context, instead of scattering across a vendor's separate products.

Your infrastructure, your rules. Your own hardware, your own billing, your own data-residency and compliance posture.

If a vendor cloud covers everything you need, use it. OperationKit is for keeping the whole operation in-house.

From zero to running

Stand it up with one compose file.

One host, one compose file, then run everything from your laptop or your phone. The snippet is illustrative. The real steps live in the setup guide.

1

Bring a host.

Any server you control. Add your own model keys or org seats.

2

Compose up.

Copy .env.example, fill your keys, then docker compose up. The web app and the agent runtime come up together.

3

Open it anywhere.

Create a workspace, spawn objectives, and watch each live session in an embedded terminal from your phone.

Apache-2.0

The core is free and open under Apache-2.0, and it stays that way.

Keep it in-house

Run your operation on infrastructure you own.

Stand it up on your own server. Your data stays on your disk. Your agents and knowledge come with you wherever you go.

Read the setup guide Star on GitHub