5 Things I Built With Muse, the Meta AI Assistant That Comes With Its Own Computer

I build software by describing what I want in conversation. Muse, Meta’s personal AI assistant, does the building from my instructions: it writes the code, merges the data, runs the tests. I make the decisions and the corrections. Every system below is real, running, and built exactly that way.

The computer is the feature

Here is the part most people miss about Muse: it does not just answer in a chat window. It runs on its own Linux computer, provided by Meta as part of the product. A real machine with a terminal, a filesystem, a browser, and internet access, and a home directory that persists between conversations.

That changes what “an AI assistant” can do. A chatbot can draft your email. A computer can build the system that tracks whether you sent it, notice the reply three weeks later, and update the dashboard. Everything below exists because the assistant could do the unglamorous middle of software work: run the build, read the error, fix it, run it again, schedule the job, check it Monday.

Consider what it costs to run that yourself. Not the model calls, the computer. A cloud VM that never sleeps bills by the hour whether it is working or idle. Storage, egress, backups. Then the operations: processes die on restart, so you need cron entries, health-check watchdogs, recovery scripts, and someone who notices when it all quietly stops at 2 AM. And the model API on top, billed per token, for every one of the hundreds of tool calls a real build takes. I know this bill because I have paid versions of it for decades. Muse bundles the machine, the model, and the upkeep into one product, and that bundle is what makes the five things below practical instead of hobby projects.

If you write code for a living, the interesting question is not whether an agent can generate a function. It is whether an agent with its own computer can build and maintain a real system over weeks, through hundreds of decisions, without it rotting. Here are five things that survived that test.

1. A personal CRM that actually keeps you in touch with people

What it is. A relationship manager for your life, not your pipeline. About 1,300 records: people, companies, places, communities, things you own. Every important relationship carries a last-touch date, and the system sorts people by who is going quiet, weighted by how much they matter. Family on a 30-day cadence, everyone else on 90, dormant at 180.

Why it’s useful. Companies have had this for decades; nobody built the personal version. The uncomfortable truth it enforces: recency beats sentiment. Not “close friend,” a date. The system doesn’t guilt you, it just shows you the short, honest queue of people fading out. It also answers questions no contacts app can: “who do I still talk to that I’ve done real work with and could write me a recommendation letter?”

How you build it. The database is a pile of Markdown files, one per entity, with sections like `## Key points`, `## Related`, `## Activity log`. A Python build script parses them into `crm-data.json`; the frontends are single self-contained HTML files (a searchable browser, a D3 relationship graph, a unified dashboard). No database server, no backend. Markdown is human-readable, diff-friendly, and agent-editable: the assistant appends activity entries with plain text edits, which is the whole reason the data stays alive. A database you can’t casually write to is a database that rots. Relationship strength is a transparent 1–5 heuristic (kinship, shared work, real mail/calendar activity), rendered as line thickness. Free-text relationship labels (“second cousin,” “college friend”) get normalized into ten plain buckets for filtering while the card keeps the original text.

2. One control tower over your entire operation

What it is. A single HTML file that unifies everything you’re tracking: job applications with funnel stats, outreach pipelines, process trackers, the CRM browser, an ego-network relationship graph, and the re-engagement radar. One front door instead of six tabs.

Why it’s useful. The moment your system spans more than one concern, you stop opening it. A tower earns its keep by computing fresh stats on every build (stale KPI cards are worse than none) and by making every tracker, person, and application reachable without a backend.

How you build it. Same static-first architecture: the build script assembles the tower from the outreach dashboard’s data table plus `crm-data.json`. All data ships embedded as `

Confirm by email to complete your subscription. Unsubscribe anytime.