where it runs

Where AI you own runs

The same software, at three scales: one person's machine, a company's own hardware, and the racks a large organization already controls. The vision behind it is on the north star; this page is about deployment.

The design rule is that customers control the machines and can inspect the software, run it without Caletta, and leave with it. Each connection has separate policies for what it sends and accepts. The Exchange Dial names five levels: nothing; metrics about task quality; weight updates; derived examples with identifying details removed; and raw work. Weight updates omit the raw record but can still reveal information about it. Across all three deployments, the planned learning loop uses a consented, encrypted record of frontier interactions to train a smaller model on the customer's hardware.

One person

Private: your own machine

This is what runs today. Capable AI models run on a Mac you own, and the software that sits between you and the rented AI runs beside them. Your questions, your drafts, and your record stay on your machine. Nothing about your work is visible to Caletta, and nothing requires a Caletta account or service to keep working.

Over time, the record of your own work teaches a model that belongs to you. The typical setting here: the work itself goes only to the rented teacher you chose, and nothing goes anywhere else. The measure of success is simple: unplug from the big AI companies, and see what share of your real work your own machine still handles.

A team

Commercial: a business's own hardware

A business would run the loop on its workstations or an office server. Its agents may need access to code, files, customer records, and browser sessions. With a hosted model, the material sent for processing is handled under the provider's terms. A local boundary gives the business a place to control that traffic and retain its own records. Vendor retention controls and private modes can be useful too; the customer-side boundary is something the business can operate itself. Two needs become especially important:

• The record becomes an audit trail. Every call the AI and its agents made, what they saw, and what they did is written down on the company's side of the line. When a client, an auditor, or a regulator asks what the AI touched, there's an answer that doesn't depend on a vendor's word.
• The model learns the business. The record of the team's real work (their contracts, their code, their support tickets) teaches a model that stays theirs. A vendor can't take it away in a price change, and a departing vendor relationship doesn't take the capability with it.

The typical settings for a company: full exchange outbound to the rented teacher, machines inside the company sharing what their models learned with each other, and nothing else leaving. This is where Caletta's first revenue is planned: a customer pays to run AI on their own hardware, with a record of everything it did. That deployment is next, after the loop is proven end to end on one everyday task first.

An organization

Enterprise: racks you control

A larger organization would run the same software on capacity it controls outright: on-premise racks, or servers it rents by the month and administers itself. This deployment is the plan, further out than the ones above; the pieces that matter most at this scale are the ones built for people whose security teams read code.

• Policy and credentials stay inside (running today). Caletta's security tools wrap rules, credentials, and audit around AI agents on the organization's side of the line, so an agent can act on internal systems without those systems' keys ever leaving.
• Sensitive work never travels (the goal). Departments whose data can't leave the building (legal, health, finance, government) get capable AI without a single prompt crossing to a third party's computers. The per-connection settings are what make this workable: a locked-down department sits at "nothing leaves" while the rest of the organization learns from traffic it is allowed to send, and the department receives that learned capability inward. It never loses the teacher; it just never talks to the teacher directly. What arrives is gated too: incoming contributions get checked before they're merged, because the way into a system like this is through what it accepts, not what it sends. That checking has a first measured result and is in build, tracked on the same public ledger.
• A guard at the door (in build). For the traffic that does go out to a rented AI, a model running on the organization's own hardware screens it first and flags protected health information, credentials, and privileged material before it leaves: "maybe you don't want to send that." The check has to run locally; routing your data through a cloud service to ask whether it's too sensitive for the cloud would be the leak itself. It helps people catch mistakes before they leave the building; it is a screen, not a compliance guarantee.
• Machines can learn together. The goal is for the machines an organization enrolls to pool what they learn without pooling the underlying work. The first measured step exists: two machines, on a real network, trained separately, traded what they learned, and ended with byte-for-byte identical results three rounds running. A whole group learning together is what's being built next, and it won't be claimed until it runs. A public page tracks which claims are measured and which are still pending.

The one-person runtime and proxy run today. The learning loop is in build; business and enterprise deployments are planned, in that order. Larger deployments need their own evidence. At every scale, owning the machines reduces some dependencies but does not remove every way an operator could be watched or cut off. Results will be published even when the numbers are poor.

If you run a team that fits one of these settings, especially the regulated kind, I'd like to hear what it would take for you to deploy it. That conversation shapes what gets built next: travis@tmc.dev.