Aries: the office assistant on a Mac mini, and what it actually does

I'm Farough (Frank) Darakhshan. I work in water-damage restoration in Northern Virginia, and most of my day is paperwork: final invoices, adjuster email, and following up until a claim is paid. Aries is the assistant I built to carry part of that load. This post is what it is, how it is put together, and where it still falls short.

Why a separate machine

Aries started on my main Mac. Every time that Mac slept, restarted, or got busy with something else, the assistant stopped. So I moved it to its own Mac mini that does nothing else.

That one change mattered more than any model upgrade. An assistant that is up only when your laptop is awake is not an assistant.

How it is built

There is no web server and no framework. Aries is about 20 scheduled jobs. Each job runs a recipe written in plain Markdown and writes its results to plain files: state, logs, memory.

Every model call goes through one wrapper script. The wrapper does four things:

• uses a key that belongs to Aries alone, with its own spending cap
• routes each job to one of three model tiers, so cheap work gets a cheap model
• writes a spend log, one line per call
• detects refusals, so a job that got "I can't help with that" fails loudly instead of saving it as an answer

Plain files sound primitive. They are the reason I can debug it. When a job does something odd, I open a text file and read what it saw.

Since 10/01/2026 the scheduled jobs run on a local model on my own hardware instead of a paid API. The paid route is still there as a fallback.

What it does every day

The morning briefing. At 8:00 AM Aries emails me a briefing and sends a push notification to my phone.

The mail pass. Every 15 minutes it reads incoming business mail, sorts it, and turns the parts that need action into to-do items.

Drafts. For mail that needs a reply, it writes a draft in the mailbox. It never sends client or adjuster mail on its own.

The to-do list. Its items land on a shared board my team can read. That board lives in the cloud, so it stays readable even when the Mac mini is offline.

The rules it runs under

The most useful decision I made was writing down exactly what Aries may do without asking.

Inside its own house it acts freely: its own code, its own state and logs, its memory, builds, configuration, model calls. Outside that house, four things never happen without me: spending money, deleting customer data, sending external communications, and anything touching physical hardware.

A detail that took me a while to see: the scheduled jobs carry their permissions in code. They never read the rules file that governs an interactive session on that machine. So loosening that file would not make the assistant more capable. It would only give an interactive session more reach into my mail. I left it tight.

Reading other people's email safely

An assistant that reads email is reading text written by strangers. Some of that text could try to give it instructions.

So the jobs that read other people's mail call the model with no tools attached at all. The model can only return text. The jobs that do get the command-line agent, with its tools, are the ones whose input is text Aries wrote itself, like its nightly reflection.

The reason is practical. The command-line agent blocks tools only by listing them one by one. An API call with no tools has nothing to block.

Sending: report the real outcome

Aries has its own path to send a message, and that path is deliberately narrow:

• it can only message an allowlist
• every real send needs an explicit confirm flag, and a dry run prints the message without sending
• it writes a journal row before it makes the request, so a crash mid-send leaves a visible "attempted" record instead of nothing
• it waits for the final status, delivered or failed, and reports that

That last rule exists because of a real failure. An earlier report said a message was "sent, verified." The provider had accepted the request, and the message was never delivered. Accepted is not delivered.

Text messages are refused outright for now, because the carrier registration that US business texting requires is not in place. The tool checks for that registration and unblocks itself once it exists. Nobody patches around it.

What it costs

On 8/10/2026 I measured it. The API key was paying for all 92 calls a day: about $3.10 a day, about $93 a month. That was a surprise. I had assumed the flat-rate subscription covered most of it. It covered almost none, because most jobs had moved to direct API calls.

The lesson is boring and important. Measure the bill from the log, not from what the setup is supposed to do.

Memory and learning

Aries keeps two separate stores. One is a research corpus with a small local search index. The other is a learning store: things it was corrected on, patterns, notes.

The learning log is append-only. A pre-commit hook refuses any change that would delete lines from it. Every six hours a governed export of what it has learned is injected into each job as a short block, capped at 4 KB. If that export is stale or missing, the block says so in capital letters. It never silently runs on old knowledge.

That warning earned its keep. From 9/24 to 9/30/2026 the lookup was down because an index could not rebuild. Now a failed lookup sends a push to my phone the same hour.

Backups

Every night at 3:00 AM a job bundles the code, the knowledge corpus, memory, and state, and copies the bundle to cloud storage and to a second machine. A health check watches the backup status file and complains if a night is missed.

The first version of Aries, built on a workflow tool, lost its data in one event. It was retired in June 2026. That is why the backup job exists.

Where it falls short

Here is the honest number. As of 10/01/2026, Aries had written 147 reply drafts. I had sent zero of them. Sixty-four sat unused for more than a week.

Part of that is a design gap. The feedback system had no way to record "not used," so an ignored draft taught it nothing. Part of it is that a draft I have to rewrite is not faster than writing it myself.

So the briefing and the to-do list earn their place every day. The drafting does not yet. That is the open problem, and it is a product question, not a wiring bug.

What I would tell another small-business owner

• Give the assistant its own machine and its own key with a spending cap.
• Write the permission rules down before the first job runs, and keep "send," "spend" and "delete" behind you.
• Make every failure loud: refusals, stale knowledge, missed backups.
• Count what you actually use. A pile of drafts is not output.

More of what I build is on my projects page, and the public code is listed on faroughdarakhshan.org.