Learned routing
The Navigator discretizes tasks into centroid regions and learns, per region, which (agent, model) pilot actually produces the best-scored outcomes — routing drifts toward what works instead of staying a static guess.
The expert platform for self-improving orgs of AI agents.
Run agents. Learn what works. Get better with every run.
Oktomata runs your coding-agent jobs — Claude Code, Codex, pi, Antigravity — and learns from every outcome: which agent and model to route next, and what past runs already figured out. Give it a goal, and it can drive an agent to build the app and ship it too.
The problem
Teams increasingly ship code through coding agents. Picking which agent and which model to point at a given task is guesswork — and the system never grades that guess. The diff lands in Git, CI runs, a PR merges or gets reverted, but none of that real-world outcome feeds back into the next routing decision.
Every run starts cold, and the choice of pilot never improves.
Oktomata closes that loop with one signal: the job's outcome. It discretizes the task space and, per region, learns which (agent, model) choice produced the best-scored results — treating past outcomes as a contextual bandit over pilots. The choice that ships working code wins more of the next region's traffic.
The core idea: a self-improving loop
Oktomata's north star is an organization of AI agents that gets better with use. It closes two learning loops from the same runs: outcome to routing (the Navigator), and distill to recall (distilled knowledge).
Route
The job-gateway embeds the prompt to a centroid region and a bandit picks the best-observed (agent, model) pilot for that region.
Run
A worker runs the chosen agent in the project's own git repo and streams a normalized result back.
Reward
The broker folds the run's immediate verdict, then re-rewards the route when a durable outcome lands — CI passed, PR merged, or the change was reverted.
Distill
When a run succeeds, a per-project distiller agent turns what it did into a durable, versioned lesson.
Recall
The next run on that project starts with the latest, non-rejected lessons folded into its context — so it starts warm, not cold.
The reward folds back into Route — each cycle nudges routing toward what works.
Invariants
Promotion never regresses
A candidate routing or policy change goes live only if it beats or ties the incumbent — proven offline or via a live canary, then promoted with one signed pointer flip.
The worker policy floor is a hard limit
No learned routing or policy overlay can widen a job's power beyond what the worker has explicitly opted into.
Core capabilities
Two intelligences learn from every run, a queue turns that learning into action, and a control plane keeps it all safe and accountable.
Distilled knowledge
On every completed run, a per-project distiller agent writes a durable lesson. Future runs recall the latest, non-rejected lessons and start warm instead of cold.
Queued agent execution
A pull-model job queue runs coding-agent CLIs with at-least-once delivery, fenced double-finalize protection, admission control, and wire-envelope versioning — agent keys never leave the worker.
Self-building
Give it a goal: a coding agent builds the app, it's graded against a rubric, and only what builds and grades ship-ready gets deployed to its own namespace.
Goal-pursuit autopilot
Turns a human goal into a DAG of jobs, dispatches them, judges whether the result satisfies the goal, and re-plans until it does — every job still flowing through the Navigator and the reward fold.
Improvement KPIs
Success rate, cost per successful task, and reward/cost trend lines turn the stream of scored outcomes into proof the org is actually getting better with use.
Agent memory via git
Each named agent's state is snapshotted to its own git repo at job end and restored at job start, secrets scrubbed first — continuity and audit for free, with git as the durable transcript record.
Same-vendor LLM gateway
Sits inline between a coding-agent CLI and its LLM cloud, adding auth, bring-your-own keys, rate-limiting, circuit-breaking, and telemetry — without translating across vendor dialects.
Conversational interface
A first-party voice and text way to talk to Oktomata, with speech-to-text and text-to-speech chained through the LLM gateway — chats are N-party, mixing agents and humans round-table.
Policy overlays
Signed, content-addressed system-prompt overlays that only promote through a no-regression gate, and are re-verified on read so a tampered blob can never shape a run.
Identity, secrets & observability
A narrow control layer handles users, teams, sessions, KMS-backed secrets, usage/budget tracking, and a hash-chained signed audit log — and mints the credentials the routing plane consumes.
Right-to-erasure (DSAR)
A one-shot admin tool runs a scoped erasure against the learning store — a user's sessions and outcome data, or an entire project offboarded on request.
Architecture at a glance
Oktomata splits into isolated planes joined by the learning loop, so a control outage never stops in-flight jobs and a learning-service outage only defers the reward fold — never a failed submit or run.
| Plane | Role | Backing |
|---|---|---|
| Control | Identity, KMS-backed secrets, usage/budgets, signed audit log; mints per-agent git credentials | Postgres (app + audit schemas) |
| Routing / agents | Queued agent execution, Navigator routing, the outcome reward fold, the distill-recall knowledge loop | Redis (queue + Navigator map) + the learning schema of shared Postgres |
| Autonomy | Goal → agent-built app → graded → deployed to its own k8s namespace; goal → planned DAG of jobs → judged → iterated | job-gateway + Kubernetes |
| Conversation | Voice/text interface over the LLM gateway | Cloud STT/TTS providers (xAI / Gemini) over HTTPS |
Internal service-to-service calls run over a gRPC mesh with per-service signed auth, plus opt-in per-service mTLS; external upstreams — LLM vendors, secret managers — stay HTTP.
Tech stack
- Backend
- Rust across every service, the CLI, storage, and crypto primitives, on Axum (HTTP) and Tokio (async).
- Frontend
- A Dioxus/WASM web console.
- Data
- One shared PostgreSQL instance with a schema per component (control, learning, voice, job audit) and Redis backing the job queue and Navigator map.
- Service mesh
- gRPC (tonic) internally, with per-service signed auth and opt-in mTLS; HTTP(S) for external upstreams.
- Speech
- An external provider (xAI or Gemini) over HTTPS, behind a swappable seam.
- Observability
- Tracing, Prometheus, and OTLP, with the four golden signals plus a run-quality signal shipped as dashboards-as-code.
- Supply chain
- A CycloneDX SBOM per image in CI, fuzz targets on untrusted wire deserializers, and property tests on pure invariants.
- Deployment
- A single-host Docker Compose stack as the reference deployment, or a Kubernetes overlay running each service as its own deployment in one shared namespace — the tenant boundary.
v1 scope
Shipped in v1
- Queued agent execution with at-least-once delivery, fence tokens, admission control, and wire-envelope versioning
- The Navigator's learned (agent, model) routing with the outcome reward fold
- The distilled-knowledge loop: per-project distiller agent, decay-ranked lesson artifacts, recall into future runs, owner reject
- The learning-schema store-of-record on shared Postgres
- The control layer: identity, KMS, observability, usage/budgets, signed audit, per-agent git credentials
- The self-building autonomy layer: build+grade gates and namespaced deploy
- The goal-pursuit autopilot loop and improvement KPIs
- Signed policy overlays with never-regress promotion
- The same-vendor LLM gateway
- The N-party voice/text conversational interface with cloud STT/TTS
- A central secrets service
- DSAR erasure
- A gRPC service mesh between internal services
Out of scope for v1
- A transcript store-of-record — client capture, the signed raw-events chain, and device-key enrollment/attestation were retired
- Cross-vendor LLM routing
- Multi-tenancy on the wire (one stack per tenant)
- A multi-node learning service (single replica; routing runs independently of it)
- Model hosting