███╗   ███╗ ██╗   ██╗  ██████╗ ███████╗ ██╗
████╗ ████║ ╚██╗ ██╔╝ ██╔════╝ ██╔════╝ ██║
██╔████╔██║  ╚████╔╝  ██║      █████╗   ██║
██║╚██╔╝██║   ╚██╔╝   ██║      ██╔══╝   ██║
██║ ╚═╝ ██║    ██║    ╚██████╗ ███████╗ ███████╗
╚═╝     ╚═╝    ╚═╝     ╚═════╝ ╚══════╝ ╚══════╝
docs
Star

Concepts

Business OS & GTM

A wedge describes a task. It does not describe a business. The gap between the two is where most of the work actually sits: the connections that must exist, the schedule that makes the work arrive without anyone clicking, the knowledge a new customer has to supply before day one is possible.

A blueprint is that gap written down — the deployable unit of a business rather than of a task.

What is in one

{
  "blueprint": "invoice-chaser",
  "title": "Accounts-receivable chaser",
  "summary": "…",
  "sells_as": "AR recovery, 2–5% of recovered value or $300+/mo",
  "wedge": "invoice-chaser",
  "requires_connections": [
    { "name": "billing-email", "kind": "email" },
    { "name": "stripe", "kind": "composio",
      "config": { "toolkit": "stripe",
                  "read_tools": ["STRIPE_LIST_INVOICES", "STRIPE_LIST_CUSTOMERS"] } }
  ],
  "schedules": [ … ],
  "seed_knowledge": [ … ]
}

sells_as is not decoration. A blueprint that cannot state what it is sold as is a workflow with ambitions.

Provision, check, activate

GET  /v1/blueprints                      # what is available, and whether it is installed
POST /v1/blueprints/:slug/provision      # create connections, schedules, knowledge
GET  /v1/blueprints/:slug/readiness      # a checklist with the exact call for each gap
POST /v1/blueprints/:slug/activate       # 409 { error: "not ready", missing } if you skipped one

Three choices in there are worth copying if you build your own packaging:

  • Schedules are created disabled. A project with no credentials should not burn model spend on timers that were always going to fail.
  • Connections are created without secrets. A blueprint file contains no credentials, so it is safe to commit, share and read.
  • Provisioning is idempotent.Existing connections and schedules are reused by name; existing knowledge is skipped rather than overwritten, so re-provisioning cannot clobber a founder's edits.

The readiness checklist is designed to be rendered as onboarding. Each incomplete item comes with the exact call that fixes it — POST /v1/connections/:id/composio/connect for a brokered account, POST /v1/connections/:id/secret for a credential you hold.

Two ship in the repo: books-keeper (UK e-commerce monthly close) and invoice-chaser. They live in kernel/blueprints/, or wherever MYCEL_BLUEPRINTS_DIR points.

The shape of the whole thing

Business
  ├── AI workforce   wedges + sandboxed agents
  ├── Customer app   create-mycel-app, or your own
  ├── Operations     the portal: approvals, tasks, connections, knowledge
  ├── GTM            founder-gated outbound — the same engine
  ├── Knowledge      grounding that grows from corrections
  └── Analytics      GET /v1/analytics — runs, success rate, cost, approval wait

Internally that is a set of workers. Externally it is a company. The analytics endpoint is the part founders reach for soonest and build last: success rate, spend, median approval wait, per-wedge and per-day breakdowns. Median approval wait is the number to watch — it is the metric that tells you whether the gate is a feature or a bottleneck.

GTM is a wedge, not a separate product

Prospecting, qualification, outreach, follow-up and customer success are the same shape as fulfilment: grounded, gated, attributable. So they are wedges, running on the same kernel, with the same approval queue.

The gate is doing something specific here. Outbound that a human signs off is correspondence. Outbound that nothing signs off is spam, and it will cost you the domain you send your invoices from. Founder-gated is not a limitation of the GTM wedges; it is the reason they can exist at all.

The useful consequence is that you validate demand with the same machinery you are building the service on, while you build it — rather than finishing the product and then starting on distribution.

Open source and cloud

  • Open source — the kernel. Self-host it, extend it, own it. Trust and ecosystem live here, which is why the trust boundary and the contract are the parts held most rigidly.
  • Cloud — the experience. Describe the business; Mycel configures the wedge, runs the infrastructure and ships the customer app and portal. Commercial, and coming online.

Nothing on this page is required. You can run a business on POST /v1/tasks and an approvals screen. Blueprints exist for when you want to run the fifth instance of the same business without doing the setup by hand each time.

What to read next

HTTP contract — the full surface, including the case, record and schedule routes this page assumes.

TenancyHTTP contract