If the Foundation is the playground's safety system, the Console is the maintenance shed. Where you keep the bolts that hold rides in place, the keys to the supply cabinets, and the operator's clipboard. Every cartridge plugs into the Console; the Console is what makes them all look and behave the same.
The Console has four jobs. None of them are exciting in isolation. Together they're the difference between "ten apps that feel the same" and "ten apps that each have their own weird login flow."
The home page. Every user sees the cartridges they have access to as tiles. Click a tile, the cartridge opens. Behind the tile, the Console has handed off the user's identity wristband so the cartridge already knows who's using it.
AWS: CloudFront + S3-hosted SPA + Cognito federationEvery cartridge needs to do the same things: verify a user's identity, look up Salesforce credentials, log a structured "I did a thing" line, talk to the database without leaking keys. We give them a shared toolbox so each cartridge author writes "what makes this cartridge special" and reuses everything else.
SDK atconsole/sdk/v1/ + zero-npm Lambda helpers at shared/modules/
One operator-facing screen where outside-system connections live. Today: Salesforce. Tomorrow: GitHub, GitBook, Monday. When a user clicks "Connect Salesforce" the Console handles the OAuth dance, stores the token in the encrypted vault, and refreshes it on schedule. Cartridges never see the OAuth complexity.
OAuth flow Lambda + SSM provider manifests + Secrets Manager (KMS-encrypted)One screen for the platform operator that says, per cartridge: is it healthy, how much did it cost this month, who used it, when did its scheduled jobs last run, are any of its OAuth connections broken. Cartridges don't have to build any of this. They emit one structured log line per AI call; the Console assembles the dashboard from those lines.
Observability cartridge reading CloudWatch Logs + Cost Explorer + DynamoDBThe Console is the standard. A new cartridge can land any time, but it has to be built on the standard shape:
| What every cartridge does | Why the Console makes it easy |
|---|---|
| Verifies the user before serving any request | JWT verifier ships in the shared modules. Cartridge calls one function. |
| Confirms the request came through CloudFront, not a direct hit on the API endpoint | X-Origin-Secret helper ships in the shared modules. Cartridge calls one function. |
| Logs every AI call with user, model, tokens, duration | logComplete helper ships in the shared modules. Cartridge calls one function. |
| Reads Salesforce credentials when it needs to call Salesforce | getOAuthClient shared helper returns a typed Salesforce adapter. Cartridge calls one method per Salesforce operation. |
| Reports cost per user back to the operator | Cartridge emits a *-complete log line; observability cartridge slices it. |
Every one of those lines starts with "the cartridge calls one function." That's the point of the Console. The cartridge author writes one or two hundred lines and the platform handles the rest.
What's already live in the AI sandbox account:
What's specced and coming next:
Competitors who build "ten AI apps" without first building the Console end up with ten different auth systems, ten different cost dashboards, ten different OAuth implementations. Each new app gets slower to ship and harder to operate. We're betting that getting the Console right first means every cartridge after the first one ships in days.
Console engineering depth lives in Step 6 (parent doctrine), Step 6.d (repo structure), Step 6.g (Console v0 build), Step 6.h (implementation reference), Step 6.i (cartridge metadata), Step 6.n (OAuth abstraction).