# Manifold: an experimental Go platform for long-horizon AI agent workflows

> Manifold is an MIT-licensed Go server that gives teams of AI specialists a workspace, a visual workflow editor and scheduled tasks. It is explicitly experimental, and the README says so before anything else.

**intelligencedev/manifold** — Manifold is an experimental platform for enabling long horizon workflow automation using teams of AI assistants.

- Repository: https://github.com/intelligencedev/manifold
- Website: https://intelligence.dev
- Stars: 501 · Forks: 31
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/intelligencedev-manifold

## What problem Manifold is aimed at

Most LLM tooling is built around a single request and a single response. Manifold targets the opposite shape of work: objectives that take many turns, involve several distinct roles, and may run for hours. The README describes it as a platform for "long-horizon workflow automation with teams of AI assistants" and states that it is designed to take advantage of the long-horizon capabilities of frontier models.

The intended user is not someone who wants a chat wrapper. It is someone who wants to define specialists with distinct configurations, give each of them tools, and let them collaborate across turns on a shared objective. The README frames the workspace as one where "specialists, tools, projects, and workflows can work together on multi-step objectives over extended periods".

That framing also sets the audience boundary. A team that needs a single reliable completion endpoint will find more machinery here than it needs. A team that wants to experiment with agent orchestration, prompt versioning and tool exposure has a reason to look.

## Specialists, projects and the skills folders

The unit of work in Manifold is the specialist: an AI agent you define and configure, assembled into a team. The README calls this the specialist registry. Specialists are not just prompt strings; they can be configured to render visualizations in addition to text responses, which is why the chat screenshots in the repository show more than a message list.

Projects are the isolation boundary. Each project is confined to its own root path, and agents load project skills from that project's `skills/` folder. There is also a shared layer: agents can discover universal read-only skills from `$HOME/.manifold/skills` and `$HOME/.agents/skills` through dedicated skill tools. The read-only qualifier matters. It means the shared directories are a distribution channel for skills, not a place where an agent writes back.

The practical consequence is that a project's behaviour is partly determined by files on disk, not only by configuration in the UI. If you move a project root, you move its skills with it.

## Workflows as tools, and tools as workflow nodes

The workflow editor is the part of Manifold with the most unusual design. The README states that MCP tools are exposed as nodes automatically, and that saved workflows become tools which specialists can invoke or which can be inserted as nodes into other workflows. The README's own summary of this is "It's workflows all the way down".

That is a real architectural decision, not a slogan. It means the same artifact can be consumed at two levels: as a graph a human edits, and as a callable capability an agent uses. It also means composition is unbounded, and unbounded composition is where debugging gets hard. The repository acknowledges this pressure by shipping a stricter execution mode. Standard builds use the Forge backend, and the README points to `docs/forge_harness.md` for guarded harness modes covering workflow enforcement, tool-error recovery, and control-flow-safe compaction, with deterministic scenario tests. Those modes are controlled by runtime configuration, not by the build alone.

If you plan to build nested workflows, read that document before you build anything deep.

## Running Manifold with Docker Compose

The README's recommended first-run path is Docker-based and explicitly does not require a local Go, Node or `pnpm` toolchain. The prerequisites it lists are Docker with Compose support, an LLM API key or a reachable OpenAI-compatible endpoint, and a writable host directory to use as `WORKDIR`.

The fast path copies the example environment and configuration, then starts the manifold service:

```bash
cp example.env .env
cp config.yaml.example config.yaml

docker compose up -d manifold
```

Before running that, edit `.env` and set at minimum `OPENAI_API_KEY` and `WORKDIR` to an absolute path. The compose file mounts `${WORKDIR}:${WORKDIR}` into the container, so a relative path here will not do what you want. The README then says to open <http://localhost:32180>, which matches the `32180:32180` port mapping in `docker-compose.yml`.

The compose file also defines a `pg-manifold` Postgres service on host port 5433 and an optional ClickHouse service on 8123 and 9000. Those are not required for a basic local deployment.

## A self-contained host run on SQLite

Manifold can run without external database or telemetry services when you build the `manifold` binary locally. SQLite is the default durable backend and Postgres is optional. The README gives this configuration shape:

```yaml
databases:
  backend: sqlite
  defaultDSN: ""
  sqlite:
    path: "~/.manifold/manifold.db"

obs:
  otlp: ""
  local:
    enabled: true
  clickhouse:
    dsn: ""
```

With that configuration, durable state lives in SQLite with FTS5 and Vec1 enabled, and metrics, logs and traces come from bounded process-local telemetry. You still need an LLM provider, either a remote API key or a local OpenAI-compatible endpoint.

The README gives one preflight command for local storage:

```bash
./dist/manifold storage doctor --json
```

Run it before startup. It is the cheapest way to find out that your database path is wrong before the server is running. The README also lists `QUICKSTART.md` and `docs/deployment.md` for the full walkthrough.

## Where Manifold is the wrong tool

The README opens with a warning block: Manifold is an experimental frontier AI platform, and it says not to deploy it in production environments that require strong stability guarantees unless the README explicitly states otherwise. It does not state otherwise. Treat that as the governing constraint on every adoption decision.

There are narrower limits too. Observability is labelled "work in progress" in the feature list, so the telemetry pipeline exists but should not be treated as finished. The `agent` one-shot CLI and the `openapi` generator are described as developer tools that are not required for the server, UI or API runtime, which means they are not a supported scripting surface for operators.

There is also a mismatch between what stable builds show and what they contain. The README says `make build-manifold` is the standard host build and that stable builds do render frontend undocumented features still in active development. If you need a UI that only exposes finished surfaces, the stable gate does not give you that. Beta UI links are enabled with `make build-manifold-beta` or `make build-manifold FEATURE_GATE=beta`, so the gate is a visibility switch, not a completeness switch.

Finally, the repository's own search footprint is a warning about naming. Most people searching "manifold" mean a pipe, a car part, a gauge set or a mathematical object. If you are looking for a self-hosted agent platform, you have to search for it deliberately.

## How it differs from a single-agent framework

The closest comparison in the same problem space is a single-agent framework such as LangChain or a comparable orchestration library. The difference is not the model support; both route to OpenAI, Google, Anthropic and OpenAI-compatible endpoints. The difference is where the structure lives.

In a code-first framework, the orchestration graph is source code. You version it in Git, review it in a pull request, and debug it with a stack trace. In Manifold, the orchestration graph is an artifact you edit visually, and the README states that saved workflows become tools. That is a genuine trade-off. You gain a lower barrier for non-Go contributors and a uniform way to expose a graph as a capability. You lose the diff readability of a workflow defined in code, and you take on the debugging cost of nested composition.

The second difference is the workspace. Manifold ships projects with per-project root paths and skill folders, a specialist registry, scheduled tasks, and a prompts and datasets playground for running experiments against prompt versions. A general-purpose framework leaves all of that to you. Whether that is a benefit depends on whether you want the platform to make those choices.

## Licence, releases and the cost of keeping up

Manifold is MIT licensed, and the repository ships a `THIRD_PARTY_NOTICES.txt` in its release artifacts alongside the `manifold` binary and the example configuration files. MIT is permissive, but the dependency list in `go.mod` is long and includes OpenTelemetry, ClickHouse, Postgres, Qdrant, Chromium automation and the MCP Go SDK. Those dependencies carry their own licences, which is what the notices file is for. Reviewing it is a reasonable step before distributing a build; this is a description of what the repository contains, not legal advice.

On maintenance: the last push to the repository was on 2026-09-10, and the most recent release is 2026.05.14 from 2026-05-14. The default branch is `develop`, which is worth noting if you clone without checking out a tag. The release cadence visible in the repository is three releases in May 2026, then a gap to the most recent one. Upgrade cost is dominated by the configuration surface: `config.yaml`, `specialists.yaml`, `mcp.yaml` and `.env` are all files you own and must reconcile against the examples after an upgrade. The release artifacts include `config.yaml.example`, `specialists.yaml.example`, `mcp.yaml.example` and `example.env` precisely so you can diff them.

## Conclusion

Adopt Manifold if you want to run multi-specialist agent workflows on your own hardware, you are comfortable with the README's own warning that it is experimental, and you can pin the 2026.05.14 release rather than tracking the develop branch. Do not adopt it if you need a stability guarantee, because the README tells you not to deploy it in production environments that require strong stability guarantees. Before committing, verify that Docker Compose starts the manifold service on port 32180, that your WORKDIR is an absolute writable host path, and that ./dist/manifold storage doctor --json reports the SQLite backend as healthy.

## FAQ

### What is Manifold from intelligencedev?

It is an experimental platform for long-horizon workflow automation using teams of AI assistants, written in Go and licensed under MIT. It provides agent chat, a specialist registry, a visual workflow editor, scheduled tasks and a prompts and datasets playground.

### How do I install Manifold?

The README's recommended first-run path is Docker-based and does not require a local Go, Node or pnpm toolchain. You copy example.env to .env and config.yaml.example to config.yaml, set OPENAI_API_KEY and an absolute WORKDIR, then run docker compose up -d manifold and open http://localhost:32180.

### Can Manifold run without Postgres or ClickHouse?

Yes. The README states that Manifold can run without external database or telemetry services when you build the manifold binary locally, with SQLite as the default durable backend and Postgres optional. The same configuration disables the OTLP and ClickHouse exporters and enables bounded process-local telemetry.

### Which LLM providers does Manifold support?

The README states that it supports OpenAI, Google and Anthropic models, along with OpenAI-compatible APIs for self-hosted open-weight models served through llama.cpp or vLLM. Image generation is supported with OpenAI and Google models, plus local generation through a custom ComfyUI MCP client.

### Is Manifold ready for production?

The README carries a warning that Manifold is an experimental frontier AI platform and says not to deploy it in production environments that require strong stability guarantees unless the README explicitly states otherwise. It does not state otherwise.

## Sources

- [intelligencedev/manifold on GitHub](https://github.com/intelligencedev/manifold)
- [License: MIT](https://github.com/intelligencedev/manifold/blob/develop/LICENSE)
- [Project website](https://intelligence.dev)
- [README](https://github.com/intelligencedev/manifold/blob/develop/README.md)
- [Releases](https://github.com/intelligencedev/manifold/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/intelligencedev-manifold