The idea — managed intelligence

In plain language

Most small businesses should be using AI to do real work by now. The hard part is not the model. It is everything around it: knowing what is worth automating, wiring it into the tools a business already uses, keeping it running when something changes, and being able to say afterwards exactly what happened and what it cost.

Managed intelligence is Matter & Gas's answer: a Solution is designed, built and operated by Matter & Gas on a platform that makes those hard parts structural. The client gets a working system reachable from a private dashboard or our API. Matter & Gas gets a platform where every Solution runs on the same foundation, so the second, tenth and thousandth Solution are built by composition rather than from scratch.

The three-layer stack

MagWorks is three layers, each a separate repository with its own version line, continuous integration and release cadence. Dependencies flow strictly downward and the direction is enforced by lint, not by convention.

Layer 1  magpie             the AI-runtime substrate         34 packages, @magpie/*, one lockstep version
   │   consumed as published packages (private registry)
   ▼
Layer 2  mag-composition    components and capabilities      5 packages, @mag/*, own version line
   │   consumed as published packages (private registry)
   ▼
Layer 3  matterandgas-com   the product, Studio and our API  the deployed AWS application
   │   consumed over HTTPS (the published v1 contract)
   ▼
Clients     the Matter & Gas Front Door   ·   client dashboards   ·   client software

Why three layers. Each layer answers a different question and changes at a different speed. The substrate (Magpie) answers what stays the same across every multi-tenant, audit-first AI system — events, ledger, tenancy, execution, knowledge, release governance. The composition layer answers what a reusable component is and how it binds to the substrate. The product answers what a client can buy and how they reach it. Keeping them in separate repositories with published-artifact boundaries means no layer can reach into the internals of the one below it; each sees only what the layer below has published.

Why published artifacts and not shared source. Every boundary is a distribution boundary — a private package registry between Layers 1→2→3, and HTTPS between Layer 3 and its consumers. Upward and cross-layer imports fail continuous integration inside each repo. A layer therefore consumes the one below it exactly as an outside party would, which is what makes the layering true rather than nominal.

Magpie executes workflows; Matter & Gas executes Capabilities

The boundary between the substrate and the product is a stable architectural commitment, not a layering convenience:

Magpie executes workflows. Matter & Gas executes Capabilities. A Capability is bound to exactly one workflow at any given Version.

Magpie does not know what a Capability, a Solution or a client is. The product injects those identities into the substrate's execution model as opaque parameters, and the substrate records them faithfully on every run, cost record and ledger row. This is constitutional (invariants I-30 and I-31): the substrate is consumed, never modified.

One contract for every client of our API

The platform's central claim is that our API is the product, with the dashboards and the public site built on top of it — not a bespoke application with an endpoint bolted on. The Matter & Gas Front Door, the public intake on matterandgas.com, is itself a client of our API: it calls the same published v1 contract that a client's own software calls, from its own server, and renders what comes back. Nothing the Front Door can do is reserved to it; every Solution is reachable the same way.

One contract serving the first-party product and every client's software is the difference between a platform and a single app that happens to have an endpoint.

Sources

magpie/docs/ecosystem-overview.md — the canonical map of the three layers and their consumers.
matterandgas-com/docs/architecture/architectural-truths-v1.md §1 (platform mission) and invariants I-30, I-31.
mag-composition/docs/adr/0001-stack-and-governance.md — why Layer 2 is a separate repository with its own version line.
magpie/docs/adr/0008-magpie-publishing-model.md — why the substrate is distributed as published packages.
matterandgas-com/docs/architecture/runtime-specification.md (RUN-1…5) — the published contract of our API.