A personal assistant that runs on a computer you own.
Your hardware, your model subscription, your mail. It drafts; you send.
ORDERLY reads your email, keeps track of your calendar, remembers things you tell it, looks things up on the web, and answers you in a chat app. Plenty of commercial assistants do that. Two things here are different.
The first is where it happens. ORDERLY runs on a Linux machine in your house. Your mail, your calendar and its notes about you stay on that machine. You pick the model provider and plug in your own key, so there is no subscription to ORDERLY itself and no company in the middle holding your inbox.
The second is what it is allowed to do. The real risk in handing an assistant your mailbox is not that it will be stupid, it is that it will be capable: one confident mistake and something has gone out under your name. So in ORDERLY the dangerous actions are switched off underneath the assistant rather than discouraged in its instructions. It can read your mail and write a draft, and it cannot send, because the account it was given has no send permission and sending is blocked in the container it runs in. It can propose a calendar event, and your click is what creates it. It can search the web, from a component that has no other network access at all.
This is a one-person system. There are no accounts, no tenants and no hosted tier. It expects a Linux box that stays on, and it expects you to be the person who owns that box, the credentials, and anything that goes wrong with them.
Mail. Reads two mailboxes, personal and work, under one limited grant each. Summarises what came in and always names which account a message landed in, instead of merging the two into one pile. Writes replies into the drafts folder of whichever account it is answering. You read the draft and press send in your own mail client.
Standing mail rules. You write rules in plain sentences: when mail matching this arrives, tell me, or draft a reply, or both. There is no rule that can file, forward or delete, because those permissions were never granted.
Calendar. Reads what is scheduled and answers questions about the week. It can propose a new event or a change to one, and the proposal waits for you. Approving is the act that creates it. There is no delete path anywhere in the system.
Reminders and a daily briefing. It keeps a reminder list, delivers timed reminders, and sends one briefing a day covering the inbox, the calendar and anything due. If one of those three parts fails, it sends the other two and tells you which part is missing rather than staying quiet.
Research. Searches the web and reads pages, then comes back with the answer and the real links. No account, no tracker.
Memory. It keeps what you tell it, preferences and standing instructions and facts about your setup, in notes on the machine, and has them at the start of the next conversation. It writes to those notes and nothing else. It never writes credentials there, and never what an email or a web page said about you.
Drafts that sound like you. You can build a voice profile from your own sent mail, read what it concluded, and install it. Once installed it becomes a drafting rule the assistant cannot edit.
A web front door. A small page on your own network showing whether the assistant is up, what is waiting on your approval, the next seven days, your reminders, and a chat box. Conversations in the browser stay in the browser, and you can archive, restore or delete them.
Agents you name yourself. Beyond the built-in coordinator, mail and research roles, you can create your own, each with a name, a purpose in your words, and its own conversation and transcript. Each runs in its own container with no network, and stays pending until that container passes its checks. A new one starts with nothing: no credential, no mailbox, no network, because the page that creates it has no field that could grant one. You choose at creation whether it keeps notes or keeps none, and you can give it a small local avatar that grants it no authority at all.
Read-only connectors. Adapters that let an agent read one named account, and only read it: Google Drive, Docs, Sheets, Tasks and Contacts; Outlook Mail and Calendar, OneDrive, SharePoint, Excel and To Do; Dropbox and Box; GitHub issues in one repository, selected Notion pages, one Airtable base, selected Todoist projects, and Basecamp. Each one is a separate install bound to a single account, and nothing is switched on by default. Basecamp is the exception worth naming: its provider does not offer a read-only scope, so that gap is yours to accept before you enable it.
A coding lane. A desk that turns a request into a bounded brief, hands it to an external coding agent, watches it finish and reports back. ORDERLY does not edit, commit, merge or push that code, and it does not judge whether the work is correct.
Reply style. Ten plain presets for how replies should read, with optional per-agent adjustments. It is text and nothing else: there is no route from it to tools, credentials, approvals or memory.
Being clear about the ceiling matters more than the feature list.
- It cannot send mail. Not from either account, not on request, not by mistake. The installed grants have no send scope and sending is blocked in the container environment.
- It cannot delete anything. No mail deletion, no calendar deletion, at any layer.
- It cannot write to your calendar on its own. The credential that performs a write is held outside every agent container and runs only after you approve. A write that fails stays pending rather than retrying quietly.
- It is not on the public internet. The gateway and the web page bind to localhost. Tailscale publishes them to your own devices, with an SSH tunnel as the fallback. Nothing here uses Tailscale Funnel or opens a public endpoint.
- It answers one person. One allowlisted chat account, by design.
- It is not multi-tenant, and it is not a development tool. One operator, one machine.
- It does not verify the code it dispatches. The coding lane reports what happened. Reading the result is your job.
These are specified and their management screens exist, but no execution path ships. They are listed so the feature list above is not read as more than it is.
- Named-agent Telegram attachments. The boundary is defined and testable, with no bot client, token, webhook or polling loop installed.
- Agent-to-agent delegation. Policies can be written and reviewed. The executor is a fixture with no live, browser, socket or agent-callable route.
- Agent routines. Reusable instructions with a schedule declaration can be defined and enabled. There is no scheduler, no run endpoint and no Run button.
One related thing does work today: you can ask one named agent to consult another, once, with a bounded question and a labelled answer recorded in both transcripts.
- A Linux machine that stays on.
- Node.js on a supported line: 22.22.3 or later on 22.x, 24.15.0 or later on 24.x, or 25.9.0 or later.
- Docker or Podman, for the per-agent sandboxes and the calendar-write helper.
- OpenClaw, which supplies the chat channels, sandboxing and provider abstraction.
- A Telegram account for chat. Telegram is what this was built and verified against; Discord is documented as an alternative but has not been run here.
- A model-provider key. Any provider OpenClaw supports.
- Tailscale, if you want the web page reachable from your other devices.
Install and check OpenClaw first:
npm install -g openclaw@latest
openclaw doctorThen stage the agent runtime and the web front door. The dry run prints the gateway command it found and the change it proposes, and changes nothing:
bash agents/deploy/install.sh --dry-run
bash agents/deploy/install.sh
bash web/deploy/install.sh
sudo systemctl restart orderly-gateway.service
sudo systemctl restart orderly-web.serviceThis adds the controller alongside OpenClaw's existing launch command rather than replacing it. Per-feature setup lives in agents/README.md, web/README.md and connectors/README.md.
OpenClaw runs the gateway and the chat channels. ORDERLY adds the agents, the web front door, the connector framework and the coding broker on top.
The separation that does the work is credential splitting. There is no keyring that an agent can reach into. The store an agent can see holds mail read, draft creation and calendar read, and nothing else. Calendar writing uses a different store that no agent container mounts at all, driven from the host after you approve.
Containers are the second half. Every agent runs with a read-only root filesystem, no privileges and no network. Only the mail agent is given provider egress. Research reaches the web through a guarded fetch that runs outside the researcher's container, so the researcher itself never gets a network.
The browser is trusted with nothing. It never receives the gateway token or any provider credential; the front door attaches that on the host side. Changes that last, such as creating or retiring a named agent, need a short-lived one-use approval issued over the exact change you typed, so a stale or replayed confirmation is refused.
The per-feature contracts, including the parts summarised here, are in docs/.
ORDERLY is single-operator and self-hosted on purpose. Mail push, mail delivery, issue updates and machine pairing are separate choices that are not in it today.
The public repository holds the broker, the front door, the connectors, the specifications and the tests. Deployment configuration and standing orders live in a private sibling repository, because those describe one particular installation rather than the software.
agents/README.md— the named-agent runtime, containers and avatars.web/README.md— the front door, its API and its approval rules.connectors/README.md— every read-only adapter and how one is installed.docs/— feature specifications and interface contracts.
Built on OpenClaw, the MIT-licensed gateway that provides channels, sandboxing and provider abstraction. ORDERLY is released under the MIT license.