What Kentron Core provides

Core is the platform the other six sections run on. Your account, the organization that owns your data, the workspaces that scope connections, the database that holds every receipt, the runtime that carries out background work, and the sync layer that keeps the browser current all live here. Come to this tab to set up an account or an organization, to understand how a run is actually executed, or to configure, deploy and operate Receipt yourself. New to Kentron? Start with What Kentron is.

​

How to read this tab

The groups follow the order you meet them: get an account and an organization, then the architecture behind a run, then the interfaces you can build against, then everything you need to configure, host and operate a deployment. Each card opens the first page of its group. The rest of the tab follows from there:

• Accounts and organizations — organizations and workspaces tells the two tenancy layers apart; members and roles covers invitations, seats and what each role may do; billing and plans covers the three things a plan actually changes.
• Architecture — receipts and streams is the hash-chained record every table is rebuilt from; jobs and durable execution is how background work survives a worker dying; the Factory engine is how an objective becomes a task graph running inside a disposable computer.
• APIs and SDK — the TypeScript SDK is the action contract a receipt-native agent is written against; authoring an agent scaffolds, runs and traces one from a checkout.
• Run it yourself — local development troubleshooting for a change that did not take effect; self-hosting for the build-time switch that changes identity, billing and telemetry; Postgres, migrations and the sync publication for the store itself; running the integration provider for the service Receipt Connect cannot work without; deploying for the two topologies and the release guards; health and observability for the probes, logs and traces.

​

The shared services

Each row is one service Core provides and the parts of the product that depend on it. When something in another tab behaves in a way you did not expect, this table usually points at the Core page that explains it.

​

How it fits

Every surface enters Core somewhere. The web app resolves your session and organization before it does anything else. Slack and Teams resolve a Receipt user through an install claim link, then call the runtime’s channel-neutral routes, which are served on the private runtime network and carry the resolved user and organization in the request body rather than a bearer token. The CLI and other MCP clients hold nothing but a Connect token. Factory workers ask the gateway for what a call needs at the moment of the call: provider credentials stay in Nango, and MCP client configs and sandboxes never contain them. Everything those paths do lands back in one place. Chat turns, gateway actions, Factory runs, and policy, skill and Agent Registry changes all append receipts, and the sync layer carries the resulting projections back to your browser — which is why a task list, a run’s progress and a replay are views of one stream rather than separate records. One gap is worth knowing before you rely on that trail: calls made through the MCP bridge are not yet recorded. Receipts and audit accounts for what does and does not write one. Next step: create your account and sign in.