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 22 October 2026, at commit 5d72509. 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 245 server operations — the functions behind the buttons in the product. Each one carries an explicit line recording whether the assistant may reach it: 217 are blocked, 13 are exempt — sign-in, sessions and multi-factor, flows that are never an AI surface in any tier — and 15 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 15. Seven of those fifteen are reachable only as proposals that a person approves on a card: the six 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 adding components to a style's parts list, which rebuilds the style's cost. 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 56 tools: forty-one read-only, eight reversible internal writes, and seven that need a person's approval — six that touch money or stock, and one that adds components to a style's parts list and rebuilds its cost. 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 seven approval 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 model calls per workspace per day and stops when the day's budget is spent, so a runaway loop is capped at one day's usage.
Every workspace gets a daily fair-use token ceiling, and a tighter one during the free trial on Karatry's own AI key — trial AI is never billed, so its downside is bounded separately. On Karatry's key, prompt-cache tokens count toward the ceiling at their price relative to an ordinary input token. The ceiling is a brake, not your plan's allowance: the Karatry AI each seat includes is a monthly amount, set out on the pricing page. Embeddings, the background indexing that lets search understand what you meant rather than what you typed, run against their own separate daily counter, 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.
Three of the gates that apply to our key don't apply to yours. The tighter trial ceiling, the stop that comes with a read-only workspace, and the monthly pause an annual plan reaches once its included Karatry AI is used all check whether you have a key of your own, and skip if you do — bringing your own key is free of any Karatry charge on every plan, including a workspace whose trial has ended and gone read-only, and it never counts against the Karatry AI your seats include. 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 →