· The Copilotz team
Why Copilotz: one app, for people and for AI
Your customers are starting to act through ChatGPT, Claude and WhatsApp. Why we built a runtime where you write the app once, and people, your agents and their assistants all use it under the same rules.
- runtime
- mcp
- agents
A salon takes bookings on its website. Last year, that was the whole story. This year, some of its customers ask ChatGPT to book for them. Some write on WhatsApp. The salon wants its own assistant on the site, too. Each of those is a new caller of the same app, and none of them clicks a button.
Four apps for one business
The usual way to handle this is to build each one separately. The web app has its endpoints and its permission checks. The WhatsApp bot gets a webhook server, a session store and the booking logic again. The MCP server for ChatGPT and Claude gets its own tools. The site's assistant gets a framework with its own idea of tools and memory.
That's four codebases with four ideas of who is asking and what they may touch. When a rule changes (say, no bookings less than two hours ahead), it changes in four places. When something goes wrong, there are four logs, and none of them says whether a booking was made by Ana herself or by an assistant working for her.
Write the app once
Copilotz is a runtime for apps that people and AI use alike. You write the app once, as plugins made of six primitives: collections for data, Actions for what can be done, Processors for what happens after, Views for how things show, Resources for settings, and Adapters for the outside world.
The salon's booking is one Action, booking.make. It says what it takes and who may call it:
"booking.make": defineAction({
input: booking,
allow: peopleOrContacts,
run: (ctx, input) => ctx.db.collection("booking").insertOne(input),
}),The web page's button calls it. The salon's own agent calls it through a tool, a thin caller of the same Action. ChatGPT and Claude call that tool over MCP. A customer on WhatsApp is answered by the same agent, with the same tool. There is one booking, written once.
The rules live at the data
Every call in Copilotz carries an actor: who is acting, for whom, and where. A person. A contact from outside, like a WhatsApp customer or an MCP conversation. Or an agent working for one of them.
The rules are checked at the data, not inside each handler. Reads come back filtered by what the actor can reach, and writes are checked, whichever way the call came in. An agent reaches what its person reaches, and allow is asked of the agent and of the person it works for, so an agent never does what its person couldn't. What only a person should decide, like inviting someone or making a key, says inPerson, and then no agent can do it at all.
This is the part we care about most. When you open your app to AI, the question isn't whether a model can call your API. It can. The question is whether it can only do what the person it works for is allowed to do. In Copilotz, that answer comes from one place.
One record
Every write records an event in the same commit, and every event names its actor. So "who booked Tuesday at ten, and for whom?" always has an answer. Ana, herself, on the web page. Or the concierge, for Ana, on WhatsApp. Or a contact, over MCP, at the front desk.
That record is what you read when a customer says "I never booked that." It's also what you test against.
Tests without a model
A model in a test is slow, costs money and answers differently every time. Copilotz tests run with a scripted model: you write its moves (call this tool, then say this), and the test checks what the model was shown, what was written, and who the record says did it. No API key, no network. In chapter 6 of the guide, one test drives the page, the agent and an assistant over MCP, and checks that the rules held at each.
Where it stands
Copilotz is open source under the MIT license, written in TypeScript, and runs on Node, Deno and Bun. It's a release candidate: 1.0 isn't out yet, and the community is small. Other tools have more integrations and longer track records; we've written honest comparisons with Mastra, the Vercel AI SDK and LangChain.js.
To see it work, the Getting Started guide builds the salon in ten chapters: one booking, then who sees what, its own web page, its own agent, ChatGPT and Claude over MCP, a chat on its site, and WhatsApp.
We built Copilotz because more of what people do will go through assistants, and the apps those assistants reach should know who's asking. Write the app once. Let everyone use it, under the same rules.