The phone rings out. The caller gets a text from your number inside a minute.

Depending on the action, the work happens on Cloudflare’s servers (always on), on your Mac, on your iPhone, in a web browser signed in to your accounts, or on Android phones rented in a data centre for apps that only run on a phone.

A website or app with no way to connect to it can be recorded once — the steps a person clicks — and saved as a new action in the Directory that can be run again at any time. The browser uses your own signed-in sessions, not fake accounts.

Executors: Cloudflare Workers and containers, a Mac bridge program, iPhone Shortcuts and App Intents, persistent browser profiles, cloud Android phones and Mac virtual machines. Recording steps and compiling them turns any website into a Directory row callable through dispatch.

Dispatch is a single web address. You, your staff, a spreadsheet, an iPhone Shortcut or an AI model send it the name of an action and its inputs. It finds the action in the Directory, checks your permissions, runs it on the right computer, sends back the result, and writes an entry in the Ledger.

Because every request goes through the same address, the same permissions apply whether a request comes from a text message, a link, a spreadsheet cell, a Shortcut, the command line or an AI model, and every request is recorded the same way. One action can be switched off in one place.

Every action is invoked as an HTTP POST of {"key": "<action name>", "args": {…}}. REST, MCP, spreadsheet formulas, text tags and webhooks are different ways of making that same request. Actions run on Cloudflare servers, a Mac, an iPhone, a browser, a virtual machine or a phone.

The webhook is one way in. A text, a spreadsheet cell and an AI model’s tool call are others; each becomes the same request:

{ key, args }

The Directory is a table. Each row is one thing the system can do for your business: send a text from your number, book a slot in your calendar, create an ad, read a web page, take a screenshot of your Mac. If an action is not in the table, the system cannot do it.

Each row stores everything needed to run that action: where it runs, what inputs it needs, what it returns, and every way to call it. Changing a setting is typing in a cell. Files added to the system’s folder are added to the table automatically.

One row per action. Each row has one column per way of calling it, and each of those cells holds the complete request (method, address, headers and body) that runs it, followed by the full response from the last run.

A reply that would quote a price you never approved, book an hour you never opened, or answer someone you never listed is refused, and the refusal is written to the Ledger.

The limits for this job: read Messages on this number only; approved prices only; book only into open hours. Anything outside them is refused and recorded in the Ledger.

The action runs with a permission issued for this one task: this number, these hours, this price list. It expires when the task is done. Without a permission nothing runs, and the refusal is recorded like any other Ledger entry.

It is sent from a device we run for you, signed in to your number’s iMessage account. It appears in the conversation the caller already has with you. Your own phone is not touched.

iPhones receive it as iMessage (blue bubbles); other phones receive RCS or SMS. The Ledger entry records which one was used.

One action, one request. The same request can be sent from a link, a spreadsheet cell or an AI model’s tool call, and it writes the same Ledger entry:

{ "key": "IMSG_SEND",
  "args": ["the caller’s number", "Hi, thanks for calling…", "auto"] }

Booking is another action in the same Directory, run through the same web address. The calendar accepts only hours you marked as open.

Reading the reply, offering times, writing the calendar entry and sending the confirmation are separate actions. Each one is checked against the permissions and each one is recorded.

Each is its own { key, args } request through the same dispatch address. The calendar write carries its limit: open hours only.

The Ledger is a record of everything the system does: every message sent and received, every action run, every change, every AI model’s answer, and every request that was refused. Nothing in it is overwritten. To find out what happened, you read it.

Each entry stores the full request and the full response. Each entry also stores a fingerprint of the entry before it, so if anyone changes an entry later, the change shows up. Refused requests are recorded the same way as completed ones.

Every payload in or out is a Ledger row. Each action appends one row containing a SHA-256 hash of the previous row; nothing is updated in place. An action counts as working only when the declared surface itself ran and five things are stored for that run: why it ran, the exact request written before it ran, the confirmation, the exact response, and the record.

Nobody types into the report. It is a row in a spreadsheet you own, updated from the Ledger.

Reports are spreadsheet cells, one row per day, not screenshots. The spreadsheet is yours; if you stop using the system, it stays with you.

Each day’s row is recalculated from that day’s Ledger entries. The spreadsheet is one more way to read the same records; nothing in it is typed by hand.

The Console app runs on iPhone, iPad and Mac. It shows the Directory, the Ledger and your AI agents, and lets you message the agents.

The Ledger opens in tabs: conversations, sessions, changes, events, tasks, traffic, AI models, actions and analysis. Every entry opens to its full content.

The app is a view of the same data: the Directory, the Ledger, the connected agents and the terminals. It reads the system; it does not keep a separate copy.