CodiakAn orchestration platform for any kind of work
Work in.
Verified results out.
Codiak orchestrates work from any source on workers you place and accepts nothing on trust. Its first use today: coding agents turn your tickets into changes. A contract of failing tests comes first, your project’s checks and an independent review decide, and every job carries its measured cost.
Everything is a plugin
The core is small on purpose: it orchestrates. What runs in the nodes, and how, is modular. Bring anything you want: a plugin can take work from any source, process anything you can think of, and have the result checked, while the core queues, isolates, limits and records it.
The core
- Master and worker nodesA Kubernetes-like shape. A master queues the work; nodes pull it and run every job in its own container.
- A proxy for rightsEach job gets a mandate. It reaches trackers, repositories and models only through the proxy, within the rights and cost limits that mandate names.
- A mirror into monitoringModel calls, tokens and cost are mirrored into monitoring, so what a job did is always on the record.
Plugins: the rest
- A written contractEvery plugin implements the contract of its kind: a tracker, a code host, a model provider, an executor.
- Tested against itThe contract comes with a test suite. A plugin that passes is a drop-in replacement.
- Declared dependenciesA plugin names what it needs and is handed only that. A missing dependency stops the start-up by name.
So swapping Jira for another tracker means swapping one plugin. The master’s configuration names the plugins in use, and the nodes mirror it.
Default plugins
What comes with Codiak. Swap any of them or add your own.
Manage
Operate Codiak, your way.
- CLIA Kubernetes-style command line. Everything goes through the API.
- Web UIA graphical front end to the same API: whatever the UI can do, the CLI can do too.
- MCPLets your own agents operate Codiak through that same API.
Connect
Reach the systems you already use.
- JiraTickets in; comments, links and transitions out.
- GitBranches and merges, guarded by what the repository server enforces.
- AI proxyModel access with the limits of each job’s mandate.
Run
Do the work, in parallel and isolated.
- Ticket pipelineContract, implement, gates, review, merge, retrospective.
- DispatcherPriority queue, balancing over the nodes, a mandate per job.
- Container executorEvery job in its own isolated container on a worker node.
- ScheduleRecurring jobs without anyone starting them.
Oversee
Keep it honest and on the record.
- RolesWorker and manager charters, enforced mechanically, not by prompt.
- OversightReads the state regularly and reports anomalies with their evidence.
Agents
What actually works a ticket inside a job.
- Agent runtimeThe harness around the model: its loop, tools and guardrails. Works with any model that offers tool calls.
Features
Contract before code
The first commit is a set of failing tests with named use cases. Implementation starts after that contract is reviewed, so what done means is settled before any code is written.
Gates, not trust
A delivery is measured in a fresh container against your project’s own requirements. A failure returns to the agent with the exact lines, not a vague try again.
Cost and outcome, measured
Every run records its tokens, time and cost; every ticket records its rounds and how it ended. You can ask what a merged ticket cost and where the money went.
Budgets that hold
A daily budget and a per-ticket envelope stop spending that outruns the value. When a ticket has used its rounds it stops and asks a person instead of looping.
Lessons carried forward
Every run ends with a retrospective. What it learned is recorded and fed back, so the next job starts better informed instead of repeating the same mistake.
Workers you can place
Tickets join one priority queue. Work runs on separate worker nodes that ask the master for jobs and report back, each job in its own container. A node is a machine with Docker.
Checkpoints with rollback
Progress is saved at checkpoints, so a run can return to an earlier one or roll back a step instead of starting over from the beginning.
Asks a person when stuck
When a ticket reaches a situation it cannot resolve, it asks a person through your ticket system and then continues from that answer, not from scratch.
A watchdog on the system
An agent watches Codiak around the clock. If it detects a problem with the system, such as a loop or a failing job or node, it can stop the ticket's run.
Where it runs
Early access is arranged case by case. We start with the set-up that fits your constraints.
| Set-up | Who runs what | Status |
|---|---|---|
| Managed | We run the master and the workers. Pay as you go, by CPU, tokens and total Codiak runtime*. | planned |
| Your workers | We run the master; you run workers next to your code and use your own AI provider (BYOK). You pay only for Codiak runtime*. | in active development |
| Self-run | You run all of it. Free demo*, then either a one-time buyout or pay for Codiak runtime. | running |
* Installation and customization are paid extra.
Early access
Bring a repository
A repository with tests and a tracker board. We start with one narrow kind of ticket.
We run it and report
On your tickets we measure what matters: how many pass first time, how often a person must step in, and what a merged ticket costs.
Then you decide
With those numbers in hand you decide whether it earns a place. No commitment before that.