For engineering leaders

Agents your engineers run, on infrastructure you own.

Manifold is a self-hosted workspace for running AI coding agents across many repositories, open source under Vipps MobilePay. This page covers what exists today, how the automation server works, and where your team can extend it.

The shape of it

What exists.

runtimes     Claude Code · Codex · Copilot · Gemini CLI
             plus both against a local Ollama model
isolation    one agent, one git worktree, one branch
scale        many repositories in one working set, one agent across all
loop         prompt → evaluate → commit on improvement, revert on regression
memory       prompts, responses and observations in per-project SQLite
plugins      sandboxed host process, capability-gated
server       labelled issue → pull request, unattended  (beta, unpublished)
licence      MIT for the app  ·  168 releases since March

It runs entirely on infrastructure you control, with your own model credentials, and it never merges anything. Agents open pull requests, and your existing CI and branch protection decide what lands. The security page documents the data flow, credential handling and the gaps.

Manifold Server Beta

Work that happens without anyone watching.

Label a GitHub issue and a server you run takes it to a pull request, unattended.

Not released yet. It's in beta and isn't published. You can't deploy it today and there is no date. The desktop app above ships independently and never depends on it. This is here so you can judge where Manifold is heading before you commit to it. 

  trigger      an issue gets your trigger label
  claim        label swap: a durable claim, so two runners
               never take the same issue
  sandbox      per-issue clone on branch manifold/issue-<n>
  agent        runs unattended, with a per-run time limit
  verify       your command: compile, unit, contract
  outcome      pull request that closes the issue
               or needs-human + a comment explaining why
Where does it run?
As a container in your own Kubernetes cluster. That is the point: the pod and namespace are the sandbox. You define the service account, the security context, the resource limits and the network policy, so the agent is confined by the same controls you already run every other workload under. It also gets a per-issue clone rather than a developer's whole disk.
What stops it spending without limit?
Concurrency is capped, because concurrency is spend. Each agent invocation has a time limit, and a run that changes nothing is escalated rather than retried indefinitely.
What stops it shipping something broken?
You supply a verify command. It runs offline in the same locked-down sandbox as the agent, so a green result means compile-and-unit sound, not integration-proven. A non-zero exit blocks the pull request and escalates instead of opening it.
Who decides what merges?
You do, unchanged. It opens pull requests under a bot identity; your CI and branch protection are the gate, exactly as for a human contributor. It never merges.
How many repositories?
As many as you register. Repositories are added and removed through its own API without a redeploy, and each environment can use its own trigger label so a staging instance never claims production issues.

Plugins

Your team extends it. We ship the privileged parts.

Manifold's own features are plugins. The automated Loop is one of them, so the extension model is the one we build on ourselves. 

  yours to write    storage · workspace:read · configuration
                  views, trees, panels
                  drop it in ~/.manifold/plugins and it loads

  ours to ship      agent:control · agent:spawn · lm
                  workspace:manage · transcription:read
                  built-in only, whatever a manifest claims

Every plugin runs in a sandboxed host process, not in the app's main process and not in the UI, and declares the capabilities it needs in its manifest. The host enforces that list, and an unrecognised capability rejects the whole manifest rather than being quietly ignored, so a typo can't widen a plugin's reach. There is also a VS Code compatibility shim, so a subset of extensions your team already uses runs unmodified.

A plugin that reads the workspace or contributes a view, you can build and deploy yourself. One that drives an agent needs to be built in, so that one we do together.

How that works. Bring the use case. If it needs privileged reach, we review the design with you, and what ships lands as a built-in under the same MIT licence as the rest of the app: yours to run, fork or walk away from. No fee, no contract, and no exclusivity in either direction.

Division of responsibility

What you own. What we provide.

Yours

  • The machines, and the cluster if you run the server
  • The model contract and every credential
  • The repositories, the branches, the merge decision
  • All session data, on your own disk
  • Any plugin your team writes

Ours

  • The app, MIT licensed, source included
  • The plugin API and its capability boundary
  • Privileged plugins, built with you and shipped built-in
  • Releases, 168 of them since March
  • A maintainer who answers

Not in either column. There is no SLA, no support contract, no account manager, and no managed configuration yet. Settings are per-user, so a platform team can't centrally pin defaults or push a standard plugin set. If any of those is a hard requirement for your organisation, it is worth establishing before a pilot rather than after.

Next step

Start with one thing you'd automate.

The most useful first conversation isn't a demo. It's the specific job you would hand to an agent, and whether Manifold can already do it.

Get in touch Or open a thread in Discussions

Manifold is open source under Vipps MobilePay and free under the MIT licence. There is nothing to buy, and no one will follow up with a quote.