What Kentron is

Kentron is an AI-agent platform. Its product is Receipt: a co-worker you hand a goal to in plain language, which either answers you directly or plans, executes and reports back, with every step recorded as a receipt you can replay. The hosted application is app.kentron.ai; if you are not signed in, opening it takes you straight to the sign-up page.

​

A co-worker you give goals to

You talk to Receipt in the web app, in Slack, or in Microsoft Teams. Every message first goes through a router that does nothing but classify the turn. It returns one of three decisions:

• Answer directly. A second pass writes the response you see in the thread.
• Author an organization skill. Receipt drafts or saves a reusable set of instructions for your organization. This route runs in the web app only.
• Run a durable background objective. Receipt queues the work and posts the result when the run settles; the web app and Slack also stream progress into the thread.

Background work runs in Factory: the objective is planned into tasks, each task runs in a disposable sandboxed computer, and the outcome comes back to the thread with a Replay you can open. In the web app and in Slack, if the router cannot tell what access a request needs it stops rather than guessing: Receipt couldn't determine the access needed for this request. Please retry; no task was started. In the interface the assistant is called Beetle: chat status lines read Sending your message to Beetle..., the tasks page is titled Beetle Tasks, and the sidebar footer widget that counts sandbox capacity is Beetle runners. This documentation says Receipt, and quotes Beetle only where the screen shows it.

​

The gateways that govern models and tools

Two gateways sit between an agent and everything outside Receipt. The MCP Gateway holds your app connections. You connect an app once through Receipt Connect, an owner or admin decides per connection which operations agents may call, and Codex or any other MCP client uses those operations without ever holding a provider credential. Write operations are off until an owner or admin enables them; there is no per-action approval prompt in this release (tools and permissions). Provider credentials stay in Nango, so MCP client configs and sandboxes never contain them. The LLM Gateway is the checkpoint every model call Receipt itself makes passes through: which providers and models the organization allows, whose key pays for the call, and how much spend is pre-authorized. It is not a proxy; there is no external endpoint for other applications to send model traffic through.

​

Receipts as proof

Receipt records its work in receipt streams: tamper-evident, SHA-256 hash-chained records in Postgres. Every background run and every action called through the gateway’s /connect/call route writes receipts; the pages that show tasks, runs and sessions are built from those streams; the runtime verifies the hash chain whenever it replays a stream and refuses one that does not check out. Calls made through the MCP bridge are not yet recorded (aggregate server).

​

The seven components

​

Which component do I need?

​

How it fits together

Every edge is backed by code: web chat goes through the LLM Gateway for direct answers and hands background work to Factory; Slack and Teams reach the same runtime through its channel-neutral routes; the CLI and MCP clients talk to the MCP Gateway, which Factory workers also call for credentials at run time; Nango holds the provider credentials; Zero syncs the receipt projections back to your browser. Guard’s enforced controls sit on the model and gateway paths.

​

Get started

Next step: see what the co-worker can do.