About Ferrule

An agent pilot rarely fails on capability any more. It reads the tracker, drafts the standup, opens the pull request, and after six weeks nobody in the room disputes that it works. It fails at the desk that has to buy it, on two questions: what this costs at forty people, and which region processes the content. Most products in this category answer neither in writing, and a platform lead at a European company of forty to two hundred and fifty people cannot carry an unpriced, unlocated system through procurement on a demo.

Ferrule is the boring half of an agent stack. An agent does not call a connected tool directly; it calls the gateway, and the gateway does four things to every call. It authorizes: it checks the calling agent against the per-agent and per-month ceilings a named human set, has a risk classifier score what the action is about to do, and refuses or escalates anything above a ceiling. It prices, quoting the action against the published rate card before it executes, so an agent can be told what it is about to spend. It executes, performing the call in the customer's own connected tool with the grant the customer gave us, and reporting what the third party actually returned. It logs, writing the call, its price, its authorizer, its result and a trace id. Nothing runs that was not quoted, and nothing is quoted that is not on the public rate card: 0.004 euro per executed action, 0.0028 above two million actions in a month, no charge for a refused, rate-limited or failed call, and no seat price at all.

Machine learning does two jobs in Ferrule, and both sit on the side of refusal. Inside Authorize, a risk classifier reads every action request before it is priced: the tool, the operation, the parameters and the agent that sent them, scored for risk and for whether the request matches what that agent is authorized to be doing. Above the risk ceiling the customer set, the action is refused or held for a named person. Over the Log, anomaly detection builds a baseline for each agent from its own 400-day record and flags behavior outside it: a tool the agent has never called, a volume it has never reached, a refusal rate that is climbing. Rules cannot do either job alone, because a routine action and a harmful one often hit the same endpoint with the same shape of parameters, and the difference is in what the parameters say. The mapping from an action to a third-party call stays deterministic. Neither model can raise a ceiling, choose a tool or call one, so a model that is talked into the wrong answer can at worst let through what a human's ceiling already allowed.

The decisions that matter are kept away from software on purpose. A named human decides which agents may act, up to what ceiling, and which classes of action need a human on the request; below a ceiling the gateway executes without review, and above it the action is refused until a named person raises the limit. What accrues from that is an authorization record: every call, the agent that made it, the human who authorized it, the tool, the risk score, the price, the result, and whether it was refused, held for 400 days inside one tenant and exported to the customer as JSONL or CSV whenever they ask for it. It is not a shared training corpus. Each agent's anomaly baseline is fitted on that tenant's log metadata and nothing else, a person's decision on an escalated action tunes that tenant's risk threshold and nobody else's, records are never pooled across customers for any purpose, and no action payload or response is used to train any model, ours or anyone else's.

The bill is a function of actions and retention, not of people. The gateway is a thin request path, under 40ms of overhead at the 95th percentile excluding the third-party call and the risk scoring, so the bill grows on two lines: a classifier call for every action, on Azure OpenAI, and S3 storage on AWS, which runs on three separate clocks. Action payloads and responses are held for 30 days by default, and as little as 24 hours if a customer sets them there. The action log is held for 400 days, which covers an annual audit cycle plus the month it takes to run one. Metering records are held for seven years, because they are the basis of an invoice under Swedish bookkeeping law. Volume follows the customer's agents rather than their headcount, and the rate card already carries a band that starts at two million actions in a month.

Residency is the other half of the same argument, and it is why the terms name the regions rather than leaving them to a sales answer. The gateway runs on AWS in eu-north-1, Stockholm: execution on EC2, and the credential store, the metering records and the action log in S3. The two models run on Microsoft Azure in Sweden Central: the risk classifier on Azure OpenAI under zero data retention, and anomaly detection on Azure Machine Learning, where we also evaluate and retrain them. No action payload leaves the EU, and no replica, backup or analytics copy leaves the European Economic Area. Our buyers are European companies whose own policies stop them sending tool content to a model provider outside the region, which is the second of the two questions that kills a pilot. The company is registered in Stockholm, in the same country as both regions, so the subprocessor answer names one jurisdiction rather than two.

Both halves grow with action volume. On AWS, the gateway switches to reserved EC2 capacity once customers pass two million actions a month, and S3 grows on the three retention clocks above. On Azure, a smaller classifier fine-tuned on Azure Machine Learning takes over most of the scoring during 2027. It learns from examples we write against the published schema catalog, never from a customer payload, and it makes each score faster and cheaper. We are a Swedish AB with three founders and no outside capital, the first 10,000 actions are free and take no card, and the rate card is short because the company is.