Agentic Schematics — Buildable specs for AI agents

What is an agentic schematic?

In Daniel Suarez's Daemon, the Darknet spreads through shared schematics: publish the spec, and independent teams build the network — no central authority, no coordination. Agentic schematics apply the same pattern to software capabilities. The schematic replaces the author: no meetings, no shared history, no access to the original conversation. If a fact matters, it lives in the package — or it doesn't exist.

In plain words: an agentic schematic is like a complete set of assembly instructions — the kind that come in a flat-pack box, except the box is a folder and the builder is an AI assistant. The instructions list every part, every step, and every check to confirm the result works. They're written so that anyone — you, a teammate, an AI on another continent — can build the exact same thing from the instructions alone, without ever asking the author a question. No meetings, no "just ask me", no missing piece that only the author knows.

Self-contained

Every requirement, parameter, dependency, phase, and test lives inside the package. No "see the original repo", no "ask the author".

Vendor-agnostic

Plain Markdown and portable shell. Any LLM with a shell and a text editor can execute it.

Idempotent

Every phase is safe to re-run. Verification gives the same verdict every time.

Modular

Every separable concern is a module with an explicit contract. No hidden coupling.

Parameterized

Every environment-specific value is a named parameter with a discovery method. Behavior differences are configuration, never code edits.

Pluggable

Clean seams with a stated removal procedure. Detach the capability and the host keeps working.

How it works

01

Author or reverse-engineer

Write a schematic from an idea, or distill one from a working implementation. Install the schematics plugin and its create-schematic skill walks any agent through it.

02

Publish once

One Markdown file is the entire coordination. Push it to a repo, paste it into a session, hand it to a stranger — the package carries everything.

03

Anyone builds, independently

Any LLM in any runtime follows the phases, discovers local parameters, and proves the result against the acceptance tests. The author is never consulted. Or build one from any GitHub repo: build <name>@<user>/<repo>.

SCHEMATIC.md (skeleton)

---
name: my-schematic
version: 0.1.0
status: draft
description: One-line summary copied to the marketplace
---

# Schematic: <Capability>

## Applicable Context
- **Must discover locally:** <commands>
- **May assume:** <with risk>
- **Must not change:** <host constraints>

## Requirements       → R-1, R-2, ... (testable)
## Dependencies       → D-1, D-2, ... (with failure behavior)
## Parameters         → P-1, P-2, ... (with discovery methods)
## Modules            → one contract per module
## Implementation     → idempotent phases with verification
## Acceptance         → A-1, A-2, ... (one per requirement)
## Removal            → stated, safe uninstall procedure

Getting started

Four steps from this page to a hardened Docker host, and a fifth once you have built it. Everything runs on your machine; the schematic is just Markdown.

01

Install the plugin

Add the schematics marketplace and install the authoring plugin — it gives your agent the build-schematic and create-schematic skills:

terminal

# oh-my-pi (omp)
omp plugin marketplace add cameri/schematics
omp plugin install schematics@cameri-schematics

# claude
claude plugin marketplace add cameri/schematics
claude plugin install schematics@cameri-schematics

# cursor, opencode, codex, and everything else
# no marketplace needed - point the agent at the spec URL and say "build this":
build https://schemaformat.ai/schematics/improve-docker-security/SCHEMATIC.md

02

Pick a schematic

Start with improve-docker-security — a composition that wires three sibling schematics: a deny-by-default Docker API proxy, OPA authorization on the daemon, and per-service encrypted secrets.

03

Build it with your agent

Tell your agent: build improve-docker-security. It reads the spec, discovers your host's parameters (Docker socket path, existing containers, secrets layout), and executes the phases — each phase verifies before the next starts.

04

Verify against acceptance

The schematic's acceptance tests are the contract: the socket is no longer reachable raw, unauthorized daemon requests are denied, and docker inspect shows secrets encrypted at rest. If a check fails, the phase loops — not your Saturday.

05

Report how it went

You are now the only person who knows what the spec is like on a host that is not the author's. File a build report — what you ran and what it printed, acceptance row by row. A build that stopped early is as welcome as one that finished, and a report is reported, never verified: it is your account, not a claim we check.

Schematics vs skills and plugins

Skill

Teaches one agent a procedure in that agent's own format. Tied to the harness that loads it; its instructions assume the agent's tools and context.

Plugin

A distribution wrapper: packages skills, commands, and agents for one harness's marketplace and installer.

Schematic

None of these. A vendor-agnostic build specification — plain Markdown and portable shell. It doesn't extend an agent; it instructs how to build a capability, and any builder can execute it with zero coordination with the author.

The relationship is complementary: this repo ships the authoring skills as a plugin because that is a convenient way to distribute them, but the schematics those skills produce depend on nothing but a shell and a text editor. Skills and plugins are how one agent gets an ability; schematics are how everyone gets the ability rebuilt, anywhere.

Hard questions, answered plainly

Why rebuild from a spec when you could fork the code?

Most of the time you shouldn't — code is copy-once, and forking is the right default. A schematic wins where forking loses: the source can't be shared, the target environment diverges enough that adaptation costs more than a parameterized rebuild, or you don't want to run a stranger's artifact and prefer that your agent builds from something fully readable. If none of those apply, fork.

Isn't a malicious schematic just prompt injection with shell steps?

It would be, if implementation were automatic. It isn't: building only places files, and the hard gate requires a human to review the spec — including every shell command the phases will run — before any implementation starts. Threat model, plainly: safer than pulling an opaque image (every line is readable), weaker than writing the capability yourself.

Isn't this just a README with a numbering scheme?

A README rarely answers "could an agent that never spoke to the author succeed?" That is the test a schematic is written to pass, and the numbering is what makes it auditable: every acceptance test maps to a requirement, so verification is checkable rather than vibes. The convention does cost more than a README; we think the audit trail is the part worth paying for.

Don't Terraform, Helm, and Ansible already do this?

For infrastructure with a runtime, yes — use them. A schematic is what you reach for when no runtime expresses the work: cross-domain capabilities that mix config, policy, certificates, and procedure, executed by an agent with a shell and a text editor instead of a toolchain.

Isn't this just a well-written prompt?

A prompt is advice to one model in one session; a schematic is a contract about the world. The difference is enforceable structure: requirements map to acceptance tests you can run, parameters declare how each is discovered on YOUR host, dependencies pin exact commits with content hashes, and removal is a stated, safe procedure. A great prompt describes the outcome and hopes; a schematic makes every claim checkable by a builder who never talks to the author — and fails loudly when a check doesn't hold.

Won't better models make this obsolete?

Parts of it, and we trim those parts as they do. What ages well: verification literals, parameter discovery, explicit failure behavior. What ages badly: hand-holding. The format is maintained as a living spec precisely so the dumb-builder scaffolding can be cut as builders get smarter.

Who has actually built anything from one?

The format is new and independent adoption is the honest gap. The first schematic was reverse-engineered from a production fleet and re-implemented from the spec; the next milestone is an independent build by someone with no connection to the author, logged publicly.

Featured schematics

Published build specifications. Copy a build command and paste it into any agent session — Claude Code, Cursor, Pi, OpenCode, Codex: build <name>@cameri/schematics. The agent fetches the spec itself; no plugin required to build. Where your harness has a marketplace, the authoring plugin adds the create-schematic / build-schematic skills. Live from .agent-schematics/marketplace.json.

Showing the 5 featured of 24 published schematics — the full list.

The plugin

Not a schematic — a harness plugin that installs the authoring skills (create-schematic, build-schematic) into coding agents that support plugins. The schematics above don't need it; it just makes writing and building them easier.

The spec

The ten binding principles

Vendor-agnostic — no agent-specific tools or formats
Portable — no absolute paths or machine-specific literals
Self-contained — the package is the complete world
Predictable — identical layout, sections in the same order
Idempotent — re-runnable without damage
Parameterized — every tunable in one table; behavior differences are config, never code edits
Dependencies called out — with discovery and failure behavior
Composable — a schematic may depend on another schematic; a composition owns no services, only the contracts between them
Applicable context stated — discover vs assume vs don't-change
Pluggable — clean seams and a stated removal procedure

File formats, self-describing

Whatever file types a schematic uses, the package must explain them. Any file format a builder can't be assumed to know ships with its own schema companion documenting the syntax, so an agent with zero prior knowledge of it can still work with the file:

<name>.<ext> + <name>.<ext>.schema

The convention is format-agnostic: config files, policy files, manifests, whatever the capability needs. If a reader would have to look the syntax up elsewhere, the package carries the syntax.

Publish a schematic.Anyone builds it. No coordination.