Private AI Operator
Runs the work. Runs itself.
AAROM runs locally on a Windows PC, on a private cloud server, or both, and manages the whole of the work — the projects and their live state, getting changes written, reviewed and shipped, the security of everything already live, the inbound that comes with it, and the cloud infrastructure underneath. It maintains itself the same way: rewriting and reinstalling its own source behind a boot gate, repairing its own tooling, and grading its work with exit-code checks rather than taking its own word for it.
COMMAND CENTRE
What it manages
The work it was built for.
Projects and their live state
Every project on the machine, found rather than typed in: stage, live address, source repository, and a health check per component tested against real evidence — a CI run, a live request, the last deploy.
Getting changes shipped
It dispatches agents into git worktrees of their own, opens draft pull requests, merges what passes, deploys, then watches the release — and can put users back on the previous build if it starts failing.
Whatever is already live
A weekly non-destructive sweep of every live site and API, each finding carrying its fix rather than just the alarm, plus a harder production pass fired by hand when one is wanted.
The inbound that comes with it
Mail and calendar swept on a schedule into a review queue. Email is a letterbox, not a control panel — nothing that arrives there can make the system act.
The infrastructure underneath
Cloud resources, DNS and deploys driven directly — provisioned, migrated and cut over, rather than written up as a runbook for someone else to follow.
Inside it
Sixteen views. These are ten of them.
Not mockups — the running application, photographed screen by screen.
AGENT FLEET & REVIEW
01 / 10
The work queue. Every dispatched agent, its state, and the pull request waiting on a human.
The client names, project names, findings and messages in these screens are stand-ins. The application, the states and the counts are the real thing.
How it holds up
Four mechanisms, running unattended.
Runs locally, in the cloud, or both
It can run on one PC, on a private cloud server, or split across the two. Here the application, the voice service and the local models run on the PC, while its searchable memory and client records live on a private server and are mirrored back to the PC — so if the server drops, it carries on from the local copy. It is reachable from a phone over a private path rather than a public endpoint.
Self-modifying, behind a boot gate
It can rewrite and reinstall its own source code, but a new version never just takes over. The boot gate starts the changed code on spare ports and demands a real health response before anything ships.
Self-healing
On every boot it audits its own tools against a high-water mark — the best count it's ever had. If a server comes back with fewer tools than that, it dispatches a repair agent instead of quietly running degraded.
Self-grading
It grades itself with exit-code checks, so a check that keeps passing while its score is falling stays visible instead of getting rounded up to “it worked.”
Also part of the system
Beyond the core mechanisms.
A fleet of its own
Background agents work in their own git worktrees and open draft pull requests. Nothing lands on main, and nothing goes straight to deploy.
Watching its own perimeter
16 security checks run against the system, plus a red team that fires real probes at the running app — on loopback only, never over the network.
Voice, gesture, and a face
It has voice, gesture control, and face recognition, and it can see through the webcam.
Rave Neal & Associates
Want something like this built for you?
Rave Neal & Associates builds these — either teaching you how to build your own, or doing it for you.
Visit Rave Neal & Associates