Open source · Apache 2.0 · self-hostable

Self-hosted AI agents you can check.

Penstock is a self-hosted AI agent harness: it runs agents on your own servers or in CI, on Ollama, Copilot, Anthropic or OpenAI. Cistern is a data pod with an MCP server: an AI agent must ask before it reads your data, and every request gets a receipt. Both open source, Apache 2.0.

AI agents now write code, read documents and call tools for you. That raises two questions: what did the agent do, and what was it allowed to see? We build open-source answers to both. Penstock is the agent side: a self-hosted agent harness with tools, memory you can switch on and, with database storage, an audit log of every model call and tool call. Cistern is the data side: a self-hostable pod that AI agents reach over MCP, where every read is checked against your rules and receipted. Use either on its own, run them together as Headworks, or have us run them.

Explore Cistern → Read the source →

Shipping now

Cistern: v0.3.1 · GHCR
Penstock: v0.5.3 · GHCR
Culvert: PyPI · Maven
Licence: Apache 2.0

HeadworksTogether

Headworks: Penstock and Cistern running together.

An AI assistant that works on your data, remembers what you have taught it, sees only what you have shared, and keeps a receipt for everything. Headworks is the name for the open-source parts below when they run together. Each ships on its own release.

Works on your data: Penstock runs the agents: self-hosted, on models you choose v0.5.3
Remembers: Penstock's record: facts, decisions and refusals as plain files you own. With memory turned on and a root split into projects, each project loads its own section and never another project's in Penstock v0.5.3
Sees only what you share: Cistern holds your data and enforces your grants on every request; revoke one and the very next request is refused v0.3.1
Keeps a receipt: Cistern receipts every allow and deny, queryable by the owner. Penstock writes every model call and tool call to its audit log when database storage is on
Learns how you work: The persona: a companion that speaks from your record (penstock#93) planned

Explore Headworks →

What we build01

What we build: two AI products and two developer frameworks.

Cistern controls which of your data an AI assistant or app may read, and keeps a receipt of every allow and deny. Penstock runs agents and, with database storage, logs every model call and tool call. Culvert (data pipelines) and enrich-test-api (cloud tests) are frameworks with no AI in them.

01 The data side v0.3.1 · live

Cistern

the gateway between AI agents and your data · open & self-hostable · Java · Apache 2.0

Cistern is a self-hostable data server built on the Solid specifications. Apps and AI assistants have to ask permission instead of taking copies. The owner writes the rule (this assistant, this folder) and Cistern enforces it on every request, revokes it on the very next one, and leaves a receipt of every allow and deny. Built in the open on open specifications: Solid for the data and its access rules, and an MCP front door so any assistant that speaks it reaches the pod through the same enforcement as everything else.

What you can run today

+docker pull ghcr.io/enrichmeai/cistern:0.3.1 is live on GHCR. It runs enforcing with three environment variables
+Held to a stranger test: pull, run, grant, refuse, revoke, receipt, from the published artifacts alone, with 2,465 tests passing behind it and 1 skipped
+Every decision gets a receipt: who read what, under which rule, when, queryable by the owner
+Apache 2.0 · built against the official Solid conformance suite, score public and only moving forward · limitations stated plainly in the release notes

Explore Cistern → Release v0.3.1 → Source →

02 The agent side v0.5.3

Penstock

a self-hosted agent harness that logs what it did, and reads from a Cistern pod only what you granted · Java · Spring Boot

Penstock runs your agents on your data, with receipts: a self-hosted agent harness for the work that happens where no editor is open (CI hooks, chat commands, scheduled triage) against your own internal systems, on models you choose. With database storage (SQLite in the shipped Compose file, or Postgres), every model call and every tool invocation is written to an audit log the owner reads back.

Its pod tool asks a Cistern pod for a file over plain HTTPS with its own credential. It gets only what was granted and is refused the rest, and what it read is receipted on the owner's side.

v0.5.3 is live: a jar, a bill of materials, a multi-architecture image, the Agent Client Protocol mode for editors, and a local MCP server that gives Claude Code and Claude Desktop the memory it keeps. v0.5.3 went through a stranger test on 17 October 2026: it installed and ran from the published jar and docs alone, with nothing blocking. Two documentation faults it found are being fixed (penstock#171) and the image was not part of the test, so it has not cleared the test the way Cistern has. Run it on your own machine for now, not on a network.

Where it stands

Todaythree surfaces (web, REST, streaming), pluggable models including a local one, and, with database storage, an audit log of every model and tool call, attributed to the authenticated user and readable in the app
Nowthe pod tool has shipped: Penstock asks a Cistern pod for a file over plain HTTPS as its own principal, is refused outside its grant, and what it read is receipted on the owner's side
Since v0.3.0it speaks the Agent Client Protocol, so it runs as a selectable agent inside an editor that speaks ACP: read-only tools unprompted, every mutating tool behind the editor's own permission prompt
Since v0.4.0it remembers. With memory switched on it recalls the facts, recent episodes and patterns for the project from a memory root you own before each model call; since v0.5.0 it gives Claude Code and Claude Desktop the same memory over MCP; and since v0.5.2 the model is asked to cite the card behind each decision and to propose what it learned, never to write a fact
Nextclearing the stranger test: the two documentation fixes; the image is still untested. Each release's image is scanned and the report attached: from v0.1.0 to v0.5.3 the high and critical total went from 138 to 17. Three distinct criticals remain, all in Spring Framework 6.2 with a fix listed only in Spring Framework 7: one is not reachable and guarded by a test, two are being checked. Every scan report is attached to its release

Explore Penstock → The record it keeps → Source →

03 A separate line data infrastructure

Culvert

cloud-agnostic data-pipeline framework · Java + Python · Apache 2.0

Data pipelines defined once against a language-neutral contract set, then run on any cloud by swapping adapters instead of rewriting logic. Shipped on PyPI and Maven Central, after a real deploy caught eight bugs that 1,145 green tests never saw.

Explore Culvert → Source →

04 Tooling v0.3.0-alpha2 · alpha

enrich-test-api

Java integration tests for cloud code, on local emulators · Java 17 · Apache 2.0

A Java test asks for a bucket or a queue and gets one, backed by a container the library started. The capability interfaces carry no cloud SDK, so a test compiled against them has no compile-time knowledge of a provider, and the AWS SDK is found at runtime through Java’s own ServiceLoader.

Tests run against a local emulator instead of a mock or a real cloud account, so no account is needed.

This one is earlier than the rest of these products and its page says so throughout. It is on Maven Central as an alpha: four capabilities against AWS on LocalStack, and a way to point your own Spring Boot or Quarkus application at the same emulator. Coverage meets its own target in both modules, and the floors the build enforces are the measured values.

Where it stands

Todayfour capabilities against AWS in emulator mode: object storage, queue, publish/subscribe and a NoSQL table. A plain verify on JDK 17 runs 85 tests, including 29 integration tests and seven Cucumber scenarios against LocalStack, with formatting, style, dependency convergence and coverage floors all enforced. The multi-test-class case it is aimed at, which used to misbehave, now cleans up after every class
Honestlyone provider, so the portability claim is a design intention rather than a demonstrated property. Emulator only. An alpha on Maven Central, so the API can still change. Coverage in the adapter stops short of the provider-error paths the emulator does not produce on demand
Latera second adapter, which is the only thing that can prove the seam holds, and a live mode that needs a credential story before it means anything

Explore enrich-test-api → Source →

Where this goes02 · direction, not release

Community pods: data held by the people it is about.

Nothing here has shipped. It is written down so you can see what the released work is for.

A pod per person is the easy half. The harder and more useful case is a pod a community runs for itself: a union, a patient group, a co-operative, a neighbourhood. There the data is about many people at once, and the rules over it are decided by them rather than for them.

That needs three things underneath: an owner who can be more than one person, rules that survive a change of membership, and a record every member can read. Cistern already enforces and receipts; what a community adds is who gets to write the rule in the first place.

It is the direction the released work is pointed at. Nothing of it is built, and this page says so rather than dating itself against a release.

How you run it03

Three ways to run it

Embed

Add the frameworks to your build as ordinary libraries. No agents, no server, nothing phoning home.

Self-host

docker compose up runs Cistern on your own hardware with your own keys. Everything it does is inspectable, down to the audit trail.

Run by us

We deploy, operate, and upgrade it, in your cloud or ours, with the maintainers on the other end of the line. Today that's an engagement, not a sign-up form: talk to us.

How we build04

How we build

Each project has a stable contract, a conformance suite every implementation must pass, release notes that say what does not work, and versioned published artifacts. We build them with AI agents, held to the same contracts and checks.