Don't Be Michael runs a local office of Claude Code agents

One manager agent over a roster of Claude Code workers

Don't Be Michael is a desktop application that puts a small office of AI workers around a single manager. The workers are Claude Code agents. Each one carries a job title such as finance, customer support, sales or marketing, and Michael is the office manager who sits between you and them. You talk to Michael, he decides which agent receives the work, he answers the questions the agents raise, and he brings back to you only the items that need a human decision. The agents are not remote services: the project documentation states that everything runs on your computer on the Claude plan you already have, so the harness leans on your existing subscription instead of selling you model access.

That is the real difference in approach against driving Claude Code yourself. A single Claude Code session is one worker with one context, and you are the router, which means every routing decision stays with you for the rest of the day. Here the routing layer is a separate agent with a standing view of the office, and the roles are configured data rather than a prompt you rewrite each morning. The price of that design is that a manager agent can misfile work, and the office metaphor in the UI hides how much prompt and state glue sits underneath the pods you see.

Setup asks for your kind of business before it hires anyone

Setup starts with two questions: what your business is and what kind of business it is. The answer selects a suggested team from the Office Pack. A Restaurant and Food business gets Finance, Executive Admin, Customer Support, Marketing, Quality Control, Supply Chain and HR Manager. A Retail Shop gets Inventory and Shipping and a Sales Director in place of Quality Control, and Pro Services gets IT Security while the SaaS and Consulting row adds an IT Engineer. You pick who joins, and the setup notes say you can hire more later.

Two fields define each hire. A Role description tells Michael what kind of work belongs at that desk, so routing has something concrete to match against. A Work style tells the agent how to do the job at your business rather than in the abstract. Both are editable in Edit Agent. The consequence is that the suggested roster is a starting point rather than the product itself. If your shop has no marketing hire, you can add one without touching anything else, and the role description you write becomes the rule Michael uses to decide a task belongs there.

Every job gets its own mailbox and its own send rights

Mail is where the office model turns into concrete permissions. Rather than one shared inbox, the app connects as many IMAP mailboxes as the business runs on, and each agent works from the one matching its job. In the role table, Pam the Executive Admin watches [email protected] and can only send on approval, Kelly in Customer Support watches [email protected] and can send, and Dwight in Sales watches [email protected] and can also send.

Connection happens in Settings, under Connections and Mailboxes. Gmail, Google Workspace, iCloud, Yahoo and Zoho are listed, and the documentation describes adding any other IMAP mailbox with an app password. The login is tested before it is saved, and the password stays encrypted on your computer, never in a file an agent can read. That last detail is the one that matters most in a tool that holds business correspondence.

Rights are granted per agent and per mailbox, and the choices are Can send, Send on approval and Draft only. Each mailbox is watched by one team member, and moving it to another asks you first. You can also let one agent send from a mailbox another agent watches, so Sales can send outreach from the CEO address without reading the CEO inbox, and the mailbox itself shows who else sends from it.

Approval can be taught once, then revoked

Approval here is a spectrum, and the project lets you move along it. Can send goes out immediately. Send on approval puts every message on the Needs you board, where you can edit it, approve it, ask for changes or stop it, and the agent learns from your edits. Draft only saves replies in the mailbox Drafts folder for you to send yourself.

The interesting part is the escape hatch. If you keep approving the same kind of email without changing it, the agent offers to send that kind on its own. You tick the offer on the card and it appears under Sends without asking on the agent's Access tab, next to a Revoke control. A separate quick check reads each such email first, and anything that does not fit comes back to you.

That is a sensible default in theory and a sharp edge in practice. The pattern is defined by your behaviour, so a habit of approving a template answer to a routine enquiry teaches the office to treat later enquiries in that shape as pre-approved. The quick check is the only guard, and the documentation describes it as a separate read rather than as a filter with visible criteria, so you would be trusting it without being able to tune it.

Scheduled runs put the office on a clock

Since version 0.2.3 the office clocks in and Waiting cards are back. In the same Access tab where you granted mailbox rights, you can add a schedule, for example one that checks the support inbox every hour, and give each run a focus area. The interface is built around a board called Needs you on the right of the office view, where items wait for you, and the release notes for 0.2.3 point at that board returning rather than at any new scheduling depth.

The value of a scheduled agent is that it stops waiting for a prompt, and the value of the focus area is that an unattended run has a stated remit instead of free-ranging across the mailbox. What the documentation does not say is what happens when a scheduled run and a person act on the same mailbox at the same time, or whether a schedule can be confined to working hours. Those cases are simply not documented, so anyone planning unattended customer replies overnight has to check them first rather than assume.

Against manual use of Claude Code, this is the clearest difference in approach. Manual use is a request and response loop that depends on you being present. A schedule is a standing order the office executes without you, which is exactly the behaviour a small business wants and exactly the behaviour a careful adopter will want to narrow.

One foundation document and one card per empty answer

Version 0.2.4 added company foundations and, more to the point, company knowledge you can open. The design is that one document holds what each job needs to know about your business, so a support agent answering a return policy question reads from a single place rather than from whatever it manages to infer. When a job has no answer available, a card asks you once for the missing piece.

Settings lists every document your team searches, and you can open and edit one in your own app. That keeps the system usable: the knowledge base is editable text you control, not a set of opaque preferences buried in a settings dialog, and the link between a card and the document it feeds is visible. For an owner who cannot write prompt engineering, being able to open a document in a normal editor is worth more than another layer of automation.

The limitation is scale. This is one document per business, not a per-role memory system, so two roles with genuinely different needs share the same text or lean on their Role description to compensate. Each agent also has its own folder and its own memory, and the documentation does not explain how that agent memory relates to the shared document, which is the first thing to test if your roles disagree about a fact.

An Electron app on Node 20, labelled an early release

Under the hood this is an Electron application written in TypeScript, with Node 20 or newer required to work on the source tree.

  "name": "dontbemichael",
  "version": "0.2.4",
  "private": true,
  "main": "out/main/index.js",

The package is marked private, so it ships as a desktop application rather than as a registry package. Building it runs the scripts the maintainer uses.

  "engines": {
    "node": ">=20"
  },
  "scripts": {
    "dev": "electron-vite dev",
    "build": "electron-vite build && npm run copy:main-assets",
    "test": "node tools/run-tests.cjs",
    "dist:mac": "npm run build && electron-builder --mac",
  },

An install step also prepares the native terminal pieces the agents need.

    "postinstall": "electron-rebuild -f && node tools/ensure-pty-perms.cjs && node tools/patch-node-pty-conpty.cjs && node tools/name-dev-electron.cjs",

Patching node-pty for ConPTY tells you the agents run in a real terminal process on Windows rather than through a plain request. For end users the install path is a download: the project documentation offers Download for Mac and Download for Windows links pointing at the latest release, and the status badge lists macOS and Windows 11 as the platforms while labelling the project an early release. A Linux build script exists in package.json with no matching download link, so Linux support is not offered there. The repository carries an MIT licence, which covers the harness code and not the behaviour of the agents it drives.

Editorial conclusion

Don't Be Michael fits a small business owner who already pays for Claude Code, runs on macOS or Windows 11, and wants mail and outreach handled by role-based agents under an approval board. It does not fit a team that needs shared server deployment, a Linux build, or agents that act with nobody in the loop. Before adopting it, check three things: that your Claude plan covers every agent you hire, that the send-without-asking shortcut matches how you actually approve mail, and what the TELEMETRY.md and SECURITY.md files in the repository root cover, because the project documentation does not.

Frequently asked questions

Official sources

1. agentvivekkumar/dontbemichael on GitHub
2. License: MIT
3. Project website
4. README
5. Releases