Intelligo

An AI product is two halves. One is the agent: the prompts, the tools, the model calls — the part that is different in every product. The other half is the same every time: who is signed in, which workspace they belong to, whether their plan allows this request, what it cost, who to bill, and what to tell an auditor later.

Intelligo is the second half, finished. It ships sign-up and workspaces, plans and credits, per-run cost, an append-only audit log, a job queue, and an admin console, as a set of @intelligo-dev/* packages plus pages that install into your repository as source.

It is deliberately not an AI framework. It has no agent abstraction, so it cannot lock you into one.

pnpm dlx @intelligo-dev/cli@beta create my-app
cd my-app

pnpm db:migrate
pnpm dev

The agent is bracketed, never wrapped.

const run = await executions.begin({ workspaceId, userId, capability, model });
if (!run.allowed) return refuse(run.reason);

const result = await yourAgent.generate(messages); // your framework, unmodified

await run.complete({ usage: result.usage }); // or, in catch: run.fail({ error })

Three phases, each with one job:

Model ids are registry keys with per-token prices. An id with no price is refused at admission and fails an architecture test — a missing price is a build error, never a silent mis-bill.

Pages are source. Billing settings, team invitations, the usage dashboard, the admin console — they ship through a shadcn registry and land in your application as files you edit.

pnpm exec shadcn add @intelligo/billing-settings

The engine is packages. Quota arithmetic, settlement, the audit trigger, the job queue: these are versioned npm packages, because nobody wants to hand-merge a fix to credit accounting.

Three rules keep the two halves from bleeding into each other: installed components are used as they are, with variance in config; copy is translation, not code; and business rules live behind the pages, never in them.

The rules that usually live in a wiki live in tests/architecture/ and break the build:

• Dependency direction. auth never imports billing; core imports nothing; only the next adapter may import next/*.
• Tenant scoping. Data access is checked for workspace scope, so a missing filter is a failing test rather than a leak found later.
• One composition root. Registries are filled explicitly from one place. Registration by import side effect is banned.
• Money is micros with a currency attached. A deployment declares the one currency it bills in.

The money path is additionally covered by Stryker mutation testing. That score is held above 97% on its scope — nine pricing, money and prompt modules, not the whole codebase — and CI fails below it.

Everything runs on one PostgreSQL database, pgvector included. The job queue claims work with SKIP LOCKED and the audit table has a trigger that refuses every update and delete, so there is no Redis and no separate vector store to operate.