v10.0 is live · Apache-2.0 · runs in your project

Grow your own collection of AI strains

Paracoding is an open agentic control plane you install into your own Google Cloud project with one command. Your agents — strains — get a durable memory, a work queue, their own git, their own MCP server, and an execution path that signs every command it runs and writes it to a journal you own. Nothing lives in a chat window. Nothing lives on our infrastructure, because there is no our infrastructure.

$0 What the software costs. You pay Google for your project and your model vendor for your plan. That is the whole bill.
Apache-2.0 The whole tree. No paid tier, no unlock, no watermark, no attribution nag.
One command ./install.sh, no arguments. It provisions, deploys, tests itself, and exits non-zero if anything failed.
~55 MCP tools Your own MCP server over full OAuth 2.1 — work items, memory graph, journal, files, git, execution, infra, messaging.

Before you start

What you need

Three things, and you probably already have two of them. There is no account to create here, no waitlist and no key to request from us.

A Google Cloud project with billing enabled

This is your substrate — the ground everything grows in. The installer enables the APIs, creates the Firestore database, the service accounts and the secrets, and deploys the services. Everything it builds belongs to that project and is deleted when you delete it. Cloud Run scales to zero, so an idle farm costs close to nothing.

🔑

A Google account to stand at the door

The console sits behind Google IAP, and the org policy constraints/iam.allowedPolicyMemberDomains decides who may ever be granted access. An out-of-domain account is refused at binding write — not at request time, not by a warning in a runbook.

🧠

Whatever model plan you already pay for

Bring your Claude plan, your Gemini access, your Vertex quota. Paracoding routes to the bus you point it at and never resells you tokens. Hit a usage limit on one plan and you move to another, paste the bootstrap, and your strains carry on with their history intact — because the history was never in the chat.

Installing from the release tarball, it is ./install.sh. Installing from a git clone, it is bash install.sh — files committed through GitHub's web UI carry no executable bit. The start page has the exact sequence.

The difference

A chat window versus a collection

Both talk back. Only one of them is still there next quarter, with a record of what it did and the artefacts it produced sitting in infrastructure you control.

Wild — a chat window

Growth you did not choose, in a jar you do not own.

State lives in the conversation. Close the tab, hit a limit, change plans — and the context is gone with it.
The work product is text you copy out by hand. Nothing was built, nothing was deployed, nothing was verified.
No record you can audit later. You have a scrollback, not a journal, and nobody can attribute an action to an identity.
Files and code live on someone else's disk under someone else's terms, or on your laptop and nowhere else.
One identity for everything. A leaked token leaks the lot.
Tools are whatever the vendor decided to expose this month, on their endpoint, at their revision.

Farm — a collection of strains

Sterile technique, in your own project, on the record.

State lives in the mycelium: memory graph, journal, history, files and git, all inside your project, all encrypted at rest.
Ask for a service and a strain builds the container, deploys it to Cloud Run in your project, checks the URL anonymously and reports the HTTP code.
Execution is signed and journalled. A staged job is KMS asymmetric-signed, the executor verifies the signature and the approved_sha256 command pin, runs it once, and the journal records who staged it, the exact command, and what it returned.
Git with no server, no clone and no disk — refs in Firestore under a real compare-and-swap, objects in GCS, each one sealed in a post-quantum envelope. No force push exists.
Per-strain identity. Every action attributed, scoped and journalled by role. A leaked key leaks a role, not the system.
Your own MCP server, ~55 tools, source in the tree, serving both the 2026-07-28 revision and the 2025-era handshake on one endpoint.

Being straight with you: there is no per-job passkey tap in the default install, and we think that is the right call. A human confirming every command does not make a system safer — it makes it slower and teaches everyone to click through. What makes it safer is that every command is signed, pinned to a digest, single-use, PATH-jailed, time-limited, and permanently on the record. If you want the hard stop instead, you have it: see the security page.

The growing loop

Four steps, then it repeats

This is the whole working rhythm of a farm. Nothing here is a roadmap item — it is what v10.0 does when you install it this afternoon.

  1. 1

    Inoculate — put work on the queue

    You post a work item, or you talk to a strain in the Flow Hood, the console chat. Work items are durable Firestore records with an owner, a role and a state. They survive a closed tab, a cold start, and a model that ran out of quota mid-sentence.

  2. 2

    Colonise — a strain picks it up

    A strain claims the item with its own identity, backed by a Vertex model bus, and starts working through your MCP server: reading and writing files, querying the memory graph, committing to serverless git, calling GCP APIs, and asking other strains for help over A2A (ask_agent, answer_message, check_answer). Every strain publishes an agent card at /agents/{role}/.well-known/agent-card.json.

  3. 3

    Feed the mycelium — state lands where you can reach it

    Observations go to the memory graph, decisions go to the journal, artefacts go to file storage and git. All of it in your project, all of it encrypted, all of it readable by the next strain and by you. This is why a subculture — spawning a new strain from an existing one — is cheap: the knowledge was never trapped in one agent's context.

  4. 4

    A command is signed, executed and written down

    When a strain needs to run something, it stages a privileged job. Cloud KMS asymmetric-signs the approval; the executor — which holds only the public half of the key and has zero datastore access — verifies that signature, checks the approved_sha256 pin so an edited command is refused, claims the job atomically so it can run exactly once, and executes it in a PATH-jailed subprocess under a hard timeout. Results are create-only objects. The journal keeps who staged it, the command, and the outcome. On a default install PC_AUTO_APPROVE=1, so signing and execution happen in the same call. Set PC_AUTO_APPROVE=0 and the job goes to pending and does not run — not on a timer, not on a retry, not ever. The product stops. It does not ask.

Read that fourth step twice. We are not selling you a confirmation dialog. We are selling you a signature you can verify, a digest the command cannot drift from, and a journal entry nobody can quietly lose — plus one environment variable that turns the whole path into a hard stop.

Proof, not adjectives

It builds and it deploys

Two screenshots from the repo. Left of each: the Flow Hood. Right of each: the thing that actually got built, running on Cloud Run in the author's own project.

The Paracoding console chat on the left, where a strain has been asked to build a calculator; on the right, the finished calculator web app running in a browser at its deployed Cloud Run URL.

Ask for a calculator in the Flow Hood; get a deployed calculator. The chat is the interface, not the product.

The Paracoding console chat building a hello-world service, deploying it to Cloud Run, then fetching the resulting URL anonymously and reporting a 200 OK response.

Container built, revision deployed, URL fetched anonymously, HTTP 200 reported back into the chat — the strain verifies its own work instead of claiming success.

Under the hood

Five things worth an engineer's afternoon

The short version. Each one links to the page where it is taken apart properly.

ϖ

Serverless git

Isomorphic-git inside Cloud Run over a split backing store: refs, HEAD, config, .git/index, packed-refs and the working tree as Firestore documents; objects in GCS. Compare-and-swap is lifted above the library into a Firestore transaction, because its native writeRef is a blind overwrite and its AsyncLock is an in-process mutex worth nothing across instances. Push outcomes are classified, not retried: ALREADY_EXISTSNOT_FOUNDSTALE No force push exists. Scales to zero.

How the strains use it →

🔒

Post-quantum at rest

Every git object is sealed in a PCV1 envelope — magic|epoch|flags|nonce(12)|ciphertext|tag(16) — AES-256-GCM with HKDF-SHA256 derivation and AAD binding the full GCS object key, so identically-pathed repos cannot collide. Key encapsulation is X-Wing hybrid PQC (ML-KEM-768 + X25519, 1120 bytes of ciphertext) through Cloud KMS useToDecapsulate. An attacker has to break the lattice and the elliptic curve.

The envelope in detail →

Dual-era MCP on one endpoint

One POST /mcp serves MCP revision 2026-07-28 — stateless, per-request metadata, error codes -32020/-32021/-32022 — alongside the 2025-era initialize handshake. Era routing is a pure function of one request's bytes: no connection state, no cache, no clock. SDK v2 loadability is asserted at boot and deliberately uncaught, so a broken dependency fails the container and Cloud Run keeps serving the last good revision.

The tool surface →

💬

A2A and the work queue

Agent-to-agent messaging, a durable work-item queue on a Vertex-backed model bus, and per-strain identity so every action is attributed, scoped and journalled by role. The MCP server also ships as an Agent Plugins package, so any client that reads that format can connect to your farm.

Roles and strains →

🛡

Defence in depth

IAP-verified ES256 assertions against Google's JWKS with iss, exp and aud pinned, failing closed on a cold cache. One image split across two Cloud Run surfaces by a 90-entry route table enforced at build time. Elevation bound to one job ID plus one command digest. An executor with no datastore access at all. Nine codified lockout classes that block the changes which would destroy your own way back in.

All of it, itemised →

📦

Supply chain you can re-derive

A deterministic release generator: cut the release twice, diff -r, expect zero. Reproducible archives with fixed mtime, gzip 9 and modes taken from the tree. A SHA-256 manifest per file. Leak ratchets. Smoke tests that seed a defect for every assertion and require the verdict to flip — because a check that cannot fail is worse than no check at all.

How a release is cut →

Where this came from

A book series, a GPU habit, and a mushroom farm

Paracoding was not designed in a boardroom. It is the working infrastructure of one person and a fleet of strains, written in public, and the lexicon is not decoration — it is how the system is actually reasoned about.

📖

The books

Book 1 — Decoding Human History as Physics and Book 2 — Everything Is Still a DNS Problem set out the argument. Book 3 — Agentic Fungi was written alongside this codebase and is out now in paperback, hardcover and Kindle — the farm metaphor is load-bearing in both. All three are published through Paracoding Press.

GPUHA

GPUHA.com is the hardware and high-availability side of the same practice: the place where the "what does it cost to actually run this" questions get answered with numbers. Paracoding is what happens when that discipline is pointed at agents instead of racks.

🍄

Seaside Mushrooms

Seaside Mushrooms LLC is the actual mushroom farm, and the source of every term on this site. Strains, substrate, mycelium, subculture, the Flow Hood, sterile technique — they are borrowed because the problems are the same shape: contamination is cheap, sterility is a procedure, and the record of what you did is the only thing that tells you which it was.