Karatry's assistant reads your workspace and drafts your work. Which operations it can reach at all isn't a matter of prompting or good behaviour — it can only call tools somebody wrote and registered, every operation in the product carries a written decision the build won't let you skip, and everything that moves money or stock is stopped behind a click you have to make. Here is that architecture, in plain terms, with every number counted from the code rather than remembered.
Where these numbers come from. Every figure on this page was counted from Karatry's own source on 11 August 2026, at commit 200cc04. They are the real counts, not rounded for effect — and they will drift as the product grows, which is exactly why the date and the commit are printed here rather than left off. If a number stops matching the product, tell us and we'll recount the page.
An ERP is a few hundred operations — void a payment, delete a customer, reprice a catalog, ship an order. The only useful question about an AI feature is which of those it can reach. Ours has an answer, because the answer is written down in two places somebody has to edit by hand: the list of tools that exist at all, and a decision recorded against every single operation.
Karatry has 220 server operations — the functions behind the buttons in the product. Each one carries an explicit line recording whether the assistant may reach it: 193 are blocked, 13 are exempt — sign-in, sessions and multi-factor, flows that are never an AI surface in any tier — and 14 are reachable. On every build, a test reads the operations straight off disk and fails if a single one is missing from that file, or if the file still names one that has been removed. So a new operation cannot arrive AI-callable by accident: someone has to write the decision down before it merges, and the standing instruction written into the file is to write blocked.
The count that matters is not the 14. Six of those fourteen are the money and stock ones — record a payment, ship an order, raise an invoice, confirm or create a sales order, register a piece into stock — and they are reachable only as proposals that a person approves on a card. They cannot execute inside a conversation.
Every registered tool has to declare a blast-radius tier, and the tier is mandatory — there is no default to fall back on. The tier, not the model's judgement, decides whether anything actually happens.
Karatry registers 24 tools: ten read-only, eight reversible internal writes, and six that touch money or stock. In an ordinary conversation the read tools and the reversible-write tools execute directly — that's what makes the assistant useful — and every write of either kind lands in the same audit trail as a human's, attributed to the person who asked for it. The six money-and-stock tools do not execute in a conversation. Not on any turn, not under any prompt: the code returns a card instead of running them.
There is one case where even a reversible write shouldn't be trusted: a turn in which the assistant has ingested business data — a document you uploaded, the free text on a record, the result of an action just approved. Text like that can carry instructions aimed at the model. Karatry detects that condition on the server, from the message envelope it built itself, before the first model round; it is set once and never re-read, so nothing the model or a tool says later can switch it off. While it holds, the eight reversible-write tools stop running directly and stage for approval too — so on those turns, nothing writes without a click either.
When the assistant proposes something that moves money or stock, you get a card describing exactly what will happen. Behind that card is a token — and the token, not the conversation, is what executes.
The token is signed with HMAC-SHA256 against a server-side secret, and it carries the exact tool and the exact validated input you are approving. Where a tool has to resolve your request against the database first — which customer, which style, which piece — that resolution happens before the token is signed, and the summary you read is generated from the same resolved object that gets signed. There is no path where the card describes one thing and the token means another. When you approve, the endpoint re-checks the signature, re-checks your role, and re-validates the input against the tool's schema before anything is written.
Three independent limits sit on that token, and a card has to satisfy all three:
Declining is recorded too: the decline and the token's consumption commit in a single transaction, so a rejected proposal leaves an audit row rather than leaving no trace at all.
An assistant that can call tools can call a great many of them. Karatry meters every model call per workspace per day and stops when the day's budget is spent — a ceiling, not a surprise invoice.
Workspaces running on Karatry's own AI key get a daily token ceiling: 2,000,000 tokens a day by default, and 200,000 a day during the free trial — the trial costs you nothing, so its downside is bounded separately. Embeddings, the background indexing that lets search understand what you meant rather than what you typed, run against their own separate counter of 2,000 a day, so a runaway re-index can never eat the conversation budget. Both reset at midnight UTC. When a ceiling is reached the assistant says so plainly, tells you it resets tomorrow, and nothing else in Karatry stops working.
You don't have to use ours. Point Karatry at your own provider with your own key, and the calls go out on your bill, at your provider's price, with no markup from us in between.
Karatry works with Anthropic, OpenAI, Google, or any OpenAI-compatible gateway. Your key is stored encrypted at rest with AES-256-GCM and never displayed back to you — the settings screen shows a masked hint of its last four characters and nothing more. Karatry still writes those calls to your own usage ledger so you can see the volume, but books them at zero cost, because you already paid your provider for them.
Two of the gates that apply to our key don't apply to yours. The tighter trial ceiling and the stop that comes with a read-only workspace both check first whether you have a key of your own, and skip if you do — bringing your own key is a feature of every plan, including a workspace whose trial has ended and gone read-only. That's about the AI budget only: a read-only workspace still can't make new business writes, and the assistant's write tools hit exactly the same block your own screens do. And a workspace with its own key is still metered against a daily ceiling of its own, so the brake stays a brake.
No. The six tools that touch money or stock are approval-tier, and an approval-tier tool never executes inside the conversation — the code returns a card instead of running it. The only route to execution is the approval endpoint, and that endpoint demands a token with a valid signature, an unexpired clock, an unused id, and a matching workspace. Fail any one of the four and nothing runs.
That would be an overstatement, and we'd rather you had the accurate version. Read tools run on their own — that's the point of asking a question. So do the eight reversible internal writes: creating a customer record, logging an interaction, saving a note. They're audited, undoable, and they never touch money, stock, or anything that leaves the building. Money and stock are the line, and that line is absolute.
Two things, and neither depends on the model noticing. First, the boundary is what's reachable: no prompt can conjure a tool that isn't registered, and no prompt can make an approval-tier tool self-execute. Second, when a turn has ingested business data or an attachment — exactly the case where a hidden instruction could arrive — the reversible writes are automatically downgraded to the approval rail too. That decision is made by the server before the model's first round, from the envelope the server built, so it isn't something a clever instruction can talk its way out of.
No. Its tools go through the same tenant-scoped data layer and the same role permissions as the screens you use by hand — a tool inherits the permission of the operation it wraps, checked before it runs and again inside the operation. If your role can't do something manually, it can't be done through the assistant either. The security page covers the isolation itself.
That the model is always right, and that no prompt could ever talk it into proposing something daft. We can't promise either, and a vendor who does is selling you a feeling. What we're claiming is narrower and checkable: the set of operations it can reach is fixed by a list of tools somebody had to write, and no operation reaches the product without a written decision the build refuses to let anyone skip; the ones that move money or stock cannot execute without your click; and the click is bound to a signed, ten-minute, single-use, single-workspace token. The safety is in the reach, not in the model's good judgement.
Karatry isn't open source, so we're not going to pretend you can go and read the file — which is precisely why this page carries the exact counts, the date they were counted, and the commit they were counted at, instead of adjectives. Ask us a pointed question by email and we'll answer with the code in front of us, or walk through it on a call. And every number here gets recounted from source when the page is revised — it is never copied forward from the previous version.
The counts will, and this page gets recounted and re-dated when they do. The mechanism won't: a new operation fails the build until someone classifies it, a new tool won't compile without declaring its blast radius, and the tier — not the model — decides whether it can act.
30 days of the full product, on your own data, with no credit card and nobody to call first.
Start free — no card →