Manifold: a self-hosted workspace for multi-agent workflows that run for hours

The gap Manifold targets: work that outlives a single prompt

Most agent tooling assumes one request, one response, one context window. Manifold is built for the opposite case. The README describes it as a platform for "long-horizon workflow automation with teams of AI assistants", and the agent chat section claims specialists "can work on complex objectives for hours". That framing sets the audience: engineers who already have an LLM API key and a workflow that spans many steps, not people looking for a chat wrapper around a single model.

The unit of work is a project. Each project is isolated to its own root path, and agents load skills from that project's skills/ folder. Two global read-only locations, $HOME/.manifold/skills and $HOME/.agents/skills, are reachable through dedicated skill tools. That split matters: shared conventions live once in your home directory, while project-specific instructions stay inside the project boundary. If your team already keeps prompts and procedures in a repository, the mapping is direct.

Specialists, workflows and MCP tools as one graph

The architecture visible in the README is a composition model rather than a single agent loop. A specialist registry lets you define and configure AI agents, and those specialists can be assigned objectives through chat. A visual workflow editor lets you design agent workflows as flows, and the README states that MCP tools are exposed as nodes automatically. The consequence is recursive: a saved workflow becomes a tool that specialists can invoke, or a node inside another workflow. The README's own phrasing is "It's workflows all the way down."

Tool context is managed explicitly. Manifold supports multiple MCP servers, and you enable tools individually to control context size. That is a deliberate trade: finer control over what enters the prompt, at the cost of configuring each tool rather than accepting a server's full surface. Built-in tools cover common agent operations, and image generation runs through OpenAI and Google models or a custom ComfyUI MCP client for local generation.

Scheduling sits on top as Pulse, which runs tasks at intervals, daily, or once at a defined date and time. Results can be sent to external services, with Matrix natively supported and other channels reachable through Skills or MCP servers. The data flow is therefore: a scheduled or manual trigger starts a specialist, the specialist calls workflows and MCP tools, and output either returns to chat or leaves through a configured channel.

Deploying a fresh clone without a Go toolchain

The recommended first-run path is Docker and does not require local Go, Node or pnpm. You need Docker with Compose support, an LLM API key or a reachable OpenAI-compatible endpoint, and a writable host directory for WORKDIR. The README gives this sequence:

cp example.env .env cp config.yaml.example config.yaml docker compose up -d manifold

Before starting, edit .env and set at minimum OPENAI_API_KEY and WORKDIR as an absolute path. The UI then listens on http://localhost:32180.

If you prefer a host build over containers, Manifold can run without external database or telemetry services. SQLite is the default durable backend and Postgres is optional. The configuration keys in the README are databases.backend, databases.defaultDSN, databases.sqlite.path, obs.otlp, obs.local.enabled and obs.clickhouse.dsn. With SQLite selected, durable state is stored with FTS5 and Vec1 enabled, and metrics, logs and traces are served from bounded process-local telemetry. You still need an LLM provider, either a remote key or a local OpenAI-compatible endpoint such as llama.cpp or vLLM.

One command is worth running before startup: ./dist/manifold storage doctor --json checks local storage. That is the closest thing to a preflight check the README documents.

For development builds, make build-manifold produces dist/manifold with the Forge backend, embedded frontend and stable UI gate. make build-manifold-beta, or make build-manifold FEATURE_GATE=beta, enables beta UI links, and the gate is passed to Vite as VITE_MANIFOLD_FEATURE_GATE. Note the README's caveat that stable builds still render undocumented frontend features that are in active development.

The Forge harness and what guarded modes actually control

Standard builds use the Forge backend, but the stricter guarded harness modes are not on by default. According to the README, workflow enforcement, tool-error recovery and control-flow-safe compaction are controlled by runtime configuration, with modes, rollout guidance and deterministic scenario tests documented in docs/forge_harness.md.

This is the most consequential detail for anyone evaluating reliability. The features that keep a long-running agent on track (enforcing workflow steps, recovering from tool errors, compacting context without breaking control flow) exist, but they are opt-in. A default deployment gets the Forge backend without those guarantees. If you are running multi-hour objectives, the difference between the standard and guarded modes is likely the difference between a workflow that finishes and one that drifts. The README does not state which modes are appropriate for which workloads beyond pointing at that document, so the document is the thing to read, not the feature list.

Observability is labelled work in progress, and the screenshot is captioned as such. Metrics, logs and traces exist through the local telemetry path, but the UI for inspecting them is not presented as finished.

Where Manifold is the wrong choice

The README carries its own warning: Manifold is an experimental frontier AI platform, and it should not be deployed in production environments that require strong stability guarantees unless the README explicitly states otherwise. It does not state otherwise anywhere in the supplied material. That is not a hedge to skim past; it is the project's own classification of its maturity.

Practical consequences follow. Observability is incomplete, so diagnosing a failed multi-hour run depends on the telemetry backend you configured rather than a finished interface. The guarded harness modes that would make long runs more predictable are configuration-gated, so the default path is the less protected one. The release artifacts are zip files containing the manifold binary plus config.yaml.example, specialists.yaml.example, mcp.yaml.example, example.env and THIRD_PARTY_NOTICES.txt, which means upgrades are a binary swap plus a config diff, and there is no documented migration tooling in the material provided.

If your need is a single model answering a single question with a stable API, Manifold is heavier than the problem. You would be configuring MCP servers, projects and specialists to reach a result that a direct API call returns.

How it differs from LangGraph and similar agent frameworks

LangGraph is the closest comparison by shape: both let you express agent behaviour as a graph. The difference is where the graph lives. LangGraph graphs are code, defined in Python or JavaScript and versioned in your repository. Manifold's workflow editor is visual, and MCP tools become nodes without you writing node definitions. Saved workflows then become tools callable by specialists or embeddable as nodes in other workflows, which keeps composition inside the running platform rather than inside source files.

That trade cuts both ways. A visual graph is faster to sketch and easier for a non-programmer to inspect, but it is harder to review in a pull request and harder to diff across releases. A code-defined graph is the opposite. Manifold also bundles what LangGraph leaves to you: a specialist registry, project isolation with skills folders, Pulse scheduling, a prompt and dataset playground for running experiments, and Matrix output. If you already have those pieces, Manifold duplicates them. If you do not, it saves assembling them. The comparison is not which is more capable; it is whether you want the orchestration layer to be a self-hosted application or a library inside your own codebase.

Maintenance cost, licensing and what to check first

Manifold is MIT licensed, which permits commercial use and modification, and the release packages include THIRD_PARTY_NOTICES.txt for the bundled dependencies. The MIT grant covers the Manifold source; it does not extend to the models you connect, the MCP servers you install, or the ComfyUI workflows you run. Those carry their own terms, and the README does not enumerate them. Nothing here is legal advice; if you redistribute Manifold inside a product, read THIRD_PARTY_NOTICES.txt and the licences of your chosen providers.

The maintenance picture from the repository metadata is a steady release cadence: 2026.05.6.2, 2026.05.8 and 2026.05.14 within eight days of each other, with the last push to the develop branch in September 2026. Frequent versioned releases on a develop default branch suggest active work, and also suggest you should pin a version rather than track the branch. There is no long-term support branch mentioned in the material.

Upgrade cost is dominated by configuration drift. Because a release ships config.yaml.example and specialists.yaml.example alongside the binary, each upgrade asks you to reconcile your edited files against new examples. The README does not describe a migration command for the SQLite or Postgres schema, so back up the database before swapping binaries. Two things to verify before you commit: run ./dist/manifold storage doctor --json against your actual path or DSN, and read docs/forge_harness.md to determine whether the guarded modes for workflow enforcement, tool-error recovery and control-flow-safe compaction are needed for the objectives you intend to run. If they are, budget for configuring them before your first long run rather than after it fails.

Editorial conclusion

Adopt Manifold if you want a self-hosted workspace where named specialists, visual workflows and MCP tools share one project root, and you are comfortable running experimental software against your own API keys. Do not adopt it if you need stability guarantees, because the README warns against production deployment and labels observability work in progress. Before committing, run ./dist/manifold storage doctor --json against your chosen SQLite path or Postgres DSN, and read docs/forge_harness.md to decide whether the guarded harness modes are required for your workflows.

Official sources

1. intelligencedev/manifold on GitHub
2. License: MIT
3. Project website
4. README
5. Releases