Your data stays with the people who own it.

ERPit is built for total self-ownership. No vendor cloud sits between people and their own data, and no outside AI service reads it.

1. Data · owned and hosted byHow

2. Business records

   Books, inventory, orders, costs

   The business

   The company runs ERPit on its own node, on hardware it controls. Every record is a signed event in the company's own log.

3. Customer personal data

   Names, addresses, credentials

   The customer

   The customer keeps it on their own node and grants a vendor specific fields, for a stated purpose, until a stated time. The vendor's books record a cryptographic identity, not a name.

4. Agent work

   Prompts, answers, proposals

   The business

   Agents run on open-weight models on the company's own hardware. ERPit needs no outside AI service.

ERPit runs on Urbit, a peer-to-peer network of personal servers. Each company, employee, customer, and agent has its own node and cryptographic identity. The company's ERPit host rejects messages from unregistered nodes before it reads them. Why Urbit fits an ERP.

No vendor can raise the rent, retire the version, or hold the data.

Urbit is a personal server: an operating system and network that each person or company runs for itself. Its design matches what an ERP needs, so ERPit gets these properties from the platform instead of building them on top of a database.

• Every app is an event log. An Urbit app changes state only by processing events, one at a time, in order. ERP data works the same way: stock moves, orders, invoices, and payments, each with rules for what can happen next.
• Every event is atomic. An event either happens completely or not at all. A crash in the middle of a write cannot leave half an invoice in the books.
• Identity is built in. Every node has an Urbit ID: a name, a network address, and a key in one. Each ERPit event carries the signature of the identity that made it. Who did this is a cryptographic fact, not a log line that an administrator can edit.
• The org chart maps to the network. Urbit IDs form a hierarchy. An ERPit agent runs on a moon, which is a child identity under its supervisor's node. The network itself records who answers for each agent.
• Nodes talk directly. Traffic between nodes is peer-to-peer and encrypted end to end. A vendor's node asks the customer's node for a field when it needs it, so customer data does not have to sit in the vendor's database.
• It runs on hardware you own. Urbit runs on almost any Unix computer, from a home server to a rented machine. Self-hosting is the normal case, not an option.

The trade-off: Urbit is young. Its hosting tools trail mainstream cloud tools, and few developers know it yet. ERPit accepts that cost for the properties above.

An AI agent in ERPit is a registered user with its own cryptographic identity. It connects through the Model Context Protocol (MCP). Through MCP, it can read and propose any action that a person can do from the screen. Signing-key ceremonies are the exception. They stay with people by design.

1. A person asks in plain language: Order 500,000 copper cores from Generic Metals.
2. The agent writes the request as a proposed event and submits it to the company's host.
3. The host checks the proposal against the agent's permissions. An agent can never have more reach than its supervisor.
4. The proposal waits in the approval inbox as a readable table. A person approves or denies it. Nobody can approve their own proposal.
5. On approval, the event commits. The record shows the agent as the actor and the person who approved it.

When the host refuses an action, it gives the reason by name. The agent reports the reason word for word to its supervisor:

no-capability: capped by supervisor ~sampel-palnet (no grant on %po-create)

Safety comes from permissions that the host enforces, not from the prompt. A weak model can fail a task. It cannot get past the host.

An ERP holds the most sensitive data a company has: customers, costs, margins, and suppliers. A cloud AI service sees every prompt that an agent sends to it.

ERPit is built for open-weight models on the company's own hardware. The agent's prompts, the model's answers, and the business data in them stay in-house. Any model that speaks MCP can connect, so the company chooses the model and can change it.

Built so a local model can do the work

• The interface speaks human. The agent types dates and amounts the way a person writes them. The host makes the ids and converts the units.
• Refusals teach. A refused command names the field and shows the expected form, for example a decimal string like "420.00".
• The instructions ship with the software. The agent reads its task guide from the ERPit host as MCP resources, so the guide always matches the installed version.

A local open-weight model, Qwen3.6-35B-A3B, worked as the agent. It has 3 billion active parameters. It failed its task again and again. It sent malformed ids and called the wrong tools. It did not change the books once, because the host refused every bad command by name. A larger model then finished the same task under the same rules.

The local agent model today is Qwen3.8-27B, a 27-billion-parameter open-weight model under the Apache 2.0 license. It runs on our own hardware.

Model quality decides whether the task gets done. It does not decide what the agent can do. A July 2026 run found places where a small local model still needed a person to translate. The fixes for those findings are in the code. A live re-test is the next scheduled ERPit task.

vouch is ERPit's companion protocol, under the same license. A customer keeps their name, address, and credentials on their own node. They give a vendor a signed grant for specific fields, for a specific purpose, until a specific time.

The vendor's books record who did what, with signatures. They do not record the customer's personal details. The customer's node logs each read. When a customer revokes a grant, the next read fails.

A vendor can also forget a customer's name. ERPit deletes the name it held, and a test measures the stored data to prove the deletion.

What the business gains

• Less to protect. A business cannot leak data that it does not hold. ERPit's permanent records contain no customer names or addresses.
• A smaller breach. If a vendor's node is ever compromised, there are fewer customer records to expose and fewer customers to notify.
• Less risk to insure. Less stored personal data can reduce the cyber-liability coverage that a business needs. Ask your insurer how this applies to you.

The limits, stated plainly: a vendor still holds a field that it fetches, for example a shipping address for an order. Some laws make a business keep certain customer records. vouch shows that retention in the customer's consent ledger. It never hides it.

We also contribute to urgit, which turns an Urbit node into a Git host and code-review site. Standard Git clients clone from it and push to it. Repositories, permissions, forks, and pull requests stay on the owner's node. We use urgit on our own node every day.

Our contributions

• Fixes that let stock git clients work with urgit without HTTP errors
• Faster packing: three steps in the pack path changed from quadratic to linear time
• Large repositories served in chunks, with visible transfer progress
• Per-repository access control and pull requests that target a branch
• Repository access granted through membership in an Urbit group
• A measured profile of node-to-node transfers: urgit's own code takes about 0.1% of the time, and the rest is in the network layer

In progress: native continuous integration. The urgit node schedules each build, and an outside runner executes it in a fresh virtual machine that is discarded afterward. The design is open for review upstream.

11 merged pull requests as of October 2026.