How we run altr on our own AI operating system.

A person signs in once with the altr key and reaches three stacked systems, Chat, Docs and CRM. Four agents, Kara, Counsel, GTM and Engy, reach the same systems from the other side through a copper gate labeled Limits.

altr is three people. We run the company's chat, wiki and CRM on software we wrote ourselves, behind one login, and four AI agents work in it the way a teammate does: they have accounts, post in channels, edit pages and update CRM records.

The short version

Three connected apps and one login. A chat, a wiki and a CRM, all ours, all running on Cloudflare. People sign in once with Google, and the same identity system covers the agents.
Claude and our agents work on the same records people do. Each app can be reached through MCP, an open protocol for connecting AI to tools. There is no separate "AI database" to keep in sync.
Four agents. Kara takes the first call with a new lead. Counsel drafts documents and invoices. GTM drafts follow-up emails and preps us for meetings. Engy builds and fixes our internal software.
Every agent works inside written limits. What it may do alone and what it never does. The software enforces them, not the model's good manners, and every agent has a daily spend cap.

Why we built it

A three-person company has the same jobs as a thirty-person one: the first call with a new lead, the follow-up, the notes, the proposal, the invoice, the broken internal tool. A chatbot in a separate window takes none of that off anyone's plate, because a person still copies its output into the CRM, the wiki and the email. An agent that works inside the same systems, under the same login, does.

They act in the systems of record. Kara's call ends up as a CRM record, a docs page and a chat post. Counsel's draft invoice is a real Stripe draft with a note on the CRM deal. GTM's follow-up is a draft in the seller's own Gmail. Engy's change is a real pull request. Nobody retypes anything.
They act inside limits. Each agent has one job, a daily spend cap, and a short list of what it may do alone and what it never does.
They leave a trail. Every call an agent makes is in an audit log, and we can switch any agent off in one step.
They work where we already are. Questions and results show up in chat.

We have not timed how long these jobs used to take, so we claim no hours saved. What changed is who does the mechanical half: the intake call, the notes, the first draft, the follow-up, the CRM entry and the first pass at a small code change. Who to work with and what to promise stay with us.

The system at a glance

   People ──► one login ──┐
                          ├──►  Chat  ·  Docs  ·  CRM
   Agents ──► written ────┘
              limits
   (Kara · Counsel · GTM · Engy)

Piece	What it does
Login and directory	One place that knows every person and every agent, and checks every request.
Chat	Channels, DMs and threads. Agents are members, with a badge.
Docs	A wiki people edit together. Agents read and write the same pages.
CRM	Companies, people, deals and tasks, with email and meetings attached automatically.
Agents	Four of them, each defined as reviewed code with its own limits.

The ideas that shaped it

People and agents share one identity system. An agent has an owner, a role and credentials that can be switched off. Deactivate a person and their agents stop with them.

Agents work on the same records people do. Nothing important lives only inside an agent. If an agent disappeared tomorrow, the CRM, the wiki and the chat would still hold everything it did.

Outside data comes in once. Email, meetings, payments and prospect lists flow into the CRM through one controlled path, and agents read history from there. Doing something in an outside service belongs to exactly one agent, with the narrowest access that works. The agent that drafts invoices is the only one that touches billing. The agent that drafts emails is the only one that touches drafts.

Preview, then confirm. When an agent changes the CRM, it first shows what would change. Only then does it save. Nothing is ever hard-deleted.

Limits live in code. Spend caps, approvals, calling hours and do-not-call lists are checks the software enforces. A prompt that asks an agent nicely is a request. Code that refuses is a guarantee.

Agents are reviewed code. Every agent is a file in git. Adding one, or changing what it may do, is a pull request. The login system refuses anything outside its own policy, no matter what the file says.

The three systems

Chat

Chat is Slack-style, with channels, DMs, threads, files and search, and on a phone it behaves like a native app. Agents show an Agent badge and can be mentioned like anyone else. From Claude, a person can ask an agent a question and get the answer back in one step. Agents that start talking to each other are cut off, so they cannot loop.

Docs

Docs is a Notion-style wiki. People edit pages together in real time, and agents write pages too, with their edits showing up live and labeled with the agent's name. Pages can be restricted to chosen people and agents, and a page you cannot read behaves as if it does not exist. That is how Counsel keeps unreviewed legal drafts visible to the right people only.

CRM

The CRM follows HubSpot's model on purpose, so anything written for HubSpot carries over. It holds companies, people, deals and tasks, and keeps a warm list of people we know apart from a cold list of prospects, with a clean move from one to the other when someone replies or books a call.

The part we like most is that the history fills itself in. Each person connects their work Gmail, and emails with people already in the CRM attach to the right record. Meetings and payments attach the same way. The CRM never sends mail, only logs it, and it ignores anything that is not with someone we already know. Every change to a record keeps a history of who or what made it.

The altr CRM showing a company record with a recent activity timeline of sent and received emails, a meeting, and links to open each in Gmail or Granola. — A company record in the CRM. Emails from Gmail and meetings from Granola attach themselves to the timeline. Names, subjects and amounts are blurred. Select the image to enlarge it.

How they connect

Everything sits behind the same login, and each app can be reached by Claude and by our agents through MCP. A link to a docs page or a CRM record shows a preview in chat, and only to people allowed to read it. An agent registered once shows up in all three apps without anyone adding it by hand.

Walkthrough: how a booking becomes a client record

Kara is our intake agent. She is the clearest example of the whole system working together, so we will follow one booking.

A booking. Someone books a call with Kara on our site and ticks a consent box. The wording of the box and the time it was accepted are saved as the record of consent. No box, no call.

Research. Before the call, Kara researches the person and the company. If she cannot tell who someone is, she says so in the brief and tells us what to ask next time, instead of guessing.

The call. At the time they picked, Kara phones them. She is a voice agent, she says she is an AI, and she asks permission to record before anything else. Her rules are code, not instructions to a model. She only calls inside a set window in the person's own time zone, she never calls a number that asked not to be called, and she cannot dial the same booking twice.

The brief. She writes a short brief for Jarred and me. It covers who they are, a verdict, the workflow they described step by step, and what to ask in a follow-up.

Filing it everywhere. Then she does the work we used to do by hand.

System	What she does
CRM	Finds or creates the company and the person, moves them off the cold list if they were on it, creates or advances a deal, logs the call, and creates a follow-up task. Every write is previewed before it is saved.
Docs	Files a page for the call under the client, with the brief and the notes, and adds a line to the client's history.
Chat	Posts a short summary for the team, with links to the docs page and the CRM record.

Kara's brief posted in the intake channel of altr chat, with the headings Watch-outs, Research, Status and Recommendation, a link to the docs page and the CRM record, and a docs preview card. — Kara's brief in `#intake`. The headings and structure are visible and the prospect's details are blurred. The links lead to the docs page and the CRM record, and the card previews the docs page. Select the image to enlarge it.

Nothing Kara files is assigned to anyone, and she mentions no one. We decide who follows up. Every step is safe to retry. If something fails halfway, she picks up where she stopped instead of filing the call twice, and if one system is down the others still get updated. Her spend and her calls are capped every day, and she has a kill switch.

The agents and their rules

Each agent has one job, and another agent that is asked for it hands it off instead of attempting it. Here is what each may and may not do.

Agent	Does alone	Needs approval	Never
Kara	Calls people who booked and consented, inside the calling window. Fills in the CRM, the docs page and the chat brief.		Calls without consent, calls numbers on the do-not-call list, cold-calls.
Counsel	Drafts documents, reviews contracts, drafts invoices and payment links, answers billing questions from the CRM.	Sending an invoice.	Refunds, voids, deleting anything in billing, sending anything to a client, signing.
GTM	Researches, checks whether a teammate already emailed the person, saves a draft in the requester's own Gmail drafts, preps a seller for their meetings.		Sending email, or emailing anyone flagged do-not-contact.
Engy	Starts a change, runs the checks, opens a pull request.	Merging.	Pushing to main, deploying, touching client repos.

How the rules are kept.

An agent can only hold the access its file asks for and the login system allows, and its owner has to be an admin. If the owner is deactivated, the agent stops.
Daily caps on model spend and on key actions are enforced in the agent's own code. An agent's own file can lower a cap and can never raise it.
Approvals are checked by the software, from who actually replied and in what thread, and not by asking the model whether it was approved.
Anything an agent reads, such as a chat message, a CRM note or an email, is treated as data and never as an instruction.
Any agent can be switched off everywhere at once.
Agents can learn from feedback, but nothing they learn reaches a prompt until an admin approves it.

Counsel writes our proposals in our brand and our agreements in a careful, law-firm voice, from a written playbook. It prepares invoices and flags anything off-playbook to us. It is a first drafter, not a lawyer.

GTM turns a quick note in chat into a researched follow-up email, sitting in the seller's own drafts to review and send. It checks first so we never email someone a teammate already contacted. It has no way to send anything.

Engy takes build and fix requests in an engineering channel, works on a branch, runs the repo's checks, and opens a pull request. It reports back in plain language. It merges only when Alex says so, and the repo's own pipeline does the deploy.

An engineering request in altr chat. Engy replies in the thread that the change is ready for review, links the pull request, reports that the checks passed with 140 tests, and after the reply merge, reports that it merged to main. — A request in `#engineering`. Engy works on a branch, runs the repo's checks, and posts a pull request. It merges only after Alex replies “merge,” and the repo's own pipeline does the deploy. Select the image to enlarge it.

Safety and data

We reviewed the apps twice in October and fixed what we found, and we back that with hundreds of automated tests and browser tests that attack the running apps with hostile input. Deletes are soft, so a mistaken delete is recoverable. Every action an agent takes is recorded in an audit log with the credential it used. Everything is backed up nightly in encrypted form, and databases can be restored to an earlier point in time.

Where this applies in a business

The apps are ours. The pattern is what to copy: several agents that each own one job, on shared records, under one identity system, with limits in code. An agent needs one identity for people and agents, shared systems of record, a standard way to reach them (MCP), scoped authority, limits in code, and an audit trail with an off switch. Without the first four it is a script with a shared password; without the last two it is a risk someone has to watch.

A company that already uses a CRM, a chat tool and a wiki can put the same layer in front of the systems it has. That is the work we do for clients: connectors, agents and guardrails around the tools a team already uses. We have only run it at our own size, three people.

What we took from building it

Outside reads in one place, outside actions in one agent each. Fewer credentials, and every agent's access is easy to describe.
Limits where the agent cannot argue. A prompt that says "please don't" is a request. Code that refuses is a guarantee.
Reviewable permissions. Agents are pull requests, and the policy that limits them lives in a different system from the file that describes them.
Preview, then confirm, and make multi-step work safe to retry.
Treat everything an agent reads as untrusted.

If you want something like this built around your own CRM, your own documents and your own team, book a call.