Archstone compiles business capabilities into tools an AI agent can call. Once those tools are live, someone has to answer for what the agent actually did — which capability ran, for which caller, with what result. That’s what the Console is for.
One console, two deployments, no branching
The Console ships as a self-hosted single-tenant deployment and a multi-tenant SaaS — same code either way. Tenancy is always enforced, cardinality one in self-hosted. Capabilities are discovered at runtime from the operator’s own API; there is no if (isSaaS) anywhere in the codebase, by design.
It’s built to be portable by construction: a static SPA and a Node container, no server-side rendering, no edge-runtime coupling — because self-hosted buyers deploy to Docker, on-prem, occasionally air-gapped, and a runtime-specific dependency would quietly close that market off.
The dependency runs one way
The Console depends on the open-source Archstone core, installed from npm exactly as any other user would install it. The core never depends on the Console. If something here needs a change to the core, that change gets justified on the core’s own terms — never smuggled in as a side effect of the commercial product.
Operator identity and caller identity are also kept strictly separate: who’s looking at the console is never confused with who invoked a capability. The Console accepts an opaque caller principal it never parses, decodes, or verifies — it isn’t allowed to become a second source of truth about a customer’s own users.
What’s open, what’s not
| Path | License |
|---|---|
| The collector — runs inside the customer’s own process boundary | Apache-2.0, published to npm with source |
| The control plane and console UI | Proprietary |
The rule behind the split is one line: whatever runs on the customer’s machine is open.
Status
The core pipeline — collector, API, console, PostgreSQL-backed store — runs end to end via a single pnpm start. Actively built alongside the open-source core it sits on top of.