// The story
Your agent solved this last week. It doesn't remember.
Oktomata is a shared memory system for teams running coding agents. The agents you already use get smarter on each project because every run leaves a lesson the next one picks up.
curl -fsSL https://oktomata.com/install | sh // Try it
Try it
> terminal
curl -fsSL https://oktomata.com/install | sh okto start
You can uninstall anytime by running okto uninstall.
Needs: Docker, ~4 GB free, your own provider key.
// What you get
What you get
> Runs write the memory.
With a plain coding agent your project memory is a file you hand-write and maintain yourself, a CLAUDE.md you have to keep current. With Oktomata the runs write it for you: each finished job distills a lesson, the next run recalls it, and advice that stops holding up quietly fades. Nobody maintains it. The work does.
> Your team's memory, not one laptop.
Those lessons live on your infrastructure, not one person's terminal history. Everyone on the team runs against the same accumulated memory, so what one engineer's agent learns on Monday is what everyone's agent knows by Tuesday.
> It survives the tool.
Switch from Claude Code to Codex to whatever comes next and the memory comes with you. It isn't scoped to one CLI. The lesson stays attached to the project, not to whichever agent happened to learn it.
// Build it yourself?
Build it yourself?
"Isn't this just Claude Code?"
Claude Code and Codex are one agent, one session, on one machine.
The gap isn't a longer feature list. It's memory: Claude Code and Codex each keep a CLAUDE.md you hand-write and maintain yourself, tied to whichever machine you're sitting at. Oktomata's project memory is shared across the whole team and survives switching tools — a lesson one engineer's run learns today is what everyone's agent, on any tool, knows tomorrow.
Could you wire this together yourself?
A job queue, a router, a memory store, graded deploys, isolation, a signed log. Yes, you could. That integrated loop is the product. Oktomata is what you'd end up building, already built and already hardened.
// Who it's for
Who it's for
Agencies and dev shops
shipping client work with agents, many projects, tight margins, and conventions that have to carry from one job to the next, each client's memory kept to itself.
Platform and DevEx teams
standardizing how an engineering org uses agents, who want one view of cost and quality, and routing that improves instead of staying a guess.
Security- and compliance-bound teams
who can't send code or data to someone else's cloud. It all runs on your own infrastructure, with your keys.
It comes up on one box and scales to your own cluster unchanged. Scale changes the size of the box, not how any of this works.
// How it works
How it works
You give it a goal. It remembers what worked before, then runs, checks, and ships accordingly. Here's the loop underneath that.
↻ it learned this from past runs
// Two rules keep the learning safe
Two rules keep the learning safe
It never gets worse on purpose.
A new routing strategy only goes live after it proves it's at least as good as the current one, on a test it has never seen, or in a small live trial first.
Learning can't grant new powers.
Each worker's owner decides what jobs on that machine are allowed to do. Anything not explicitly turned on stays off. Learning changes which agent runs, never what it's allowed to touch.
// Security & trust
Security & trust
-
It runs on your infrastructure, with your keys.
Your data never passes through a cloud of ours; model calls go straight to your provider with your keys.
-
Your keys never leave your machines.
Model keys and agent tools live only on your worker machines. Even a compromised server can't steal them.
-
A signed, tamper-proof history. Erase it with one command.
Tamper-proof, signed logs on both the control room and job execution. One command wipes the learning data, all of it or scoped to a single project, with nothing keyed to individual people to erase; the store is de-identified by design.
// FAQ
FAQ
What agents does it run?
Coding-agent CLIs, Claude Code, Codex, Antigravity, and Goose, through one adapter layer. The agents are external tools; Oktomata launches, routes, and learns from them.
How does it grade a run?
On what actually happened: the job's real pass or fail, did it build, did it clear review, did the durable outcome hold up, weighed against what the run cost. Grades come from your own results, not a benchmark we picked.
What does it take to run?
One machine and one command, or your own cluster, unchanged. Worker machines join the pool by connecting outward, so nothing needs an inbound port. There's no platform team to hire: the deploy, isolation, secrets, and backups are handled by default.
Does Oktomata host or resell models?
No. It uses your own provider keys and passes calls straight through to your provider, unchanged. It never sits in the middle as its own model vendor.
Can learning make an agent do something dangerous?
No. Each worker enforces a hard limit on what jobs there can do. Swapping the agent, passing extra arguments, reaching the environment, auto-approving actions are each off unless that machine's owner turns them on. Nothing the system learns can widen that.
> Let's talk