HERMES / BUILT & USED BY CHRIS
I built a personal intelligence system behind my AI chats. It keeps my memory, runs background jobs and uses tools on my own computer.
An authorised AI is the way in. The memory and work stay with me.Proven through local Hermes / Remote Desktop. Direct hosted ChatGPT, Grok and Gemini connections are not yet fully verified.
Saved to Drive, restored into an empty cache, retrieved with its source.
Memory architecture + recovery DROP OFF A JOBI kept talking. The work continued.A background task completed; a fresh controller retrieved the saved result.
Independent workflows FOLLOW A REAL QUESTIONQUEST sellers. ICP usage. IMX value.Collectors and source records feed the research. Missing evidence stays visible.
Research + data systemsVerified 30 September 2026. Tests cover the stated flows, not every possible use.
SEE WHAT I BUILT / 59 SECONDS
Memory, background work and the decisions behind Hermes.
Silent film · AI-generated illustrations, not a product recording. The build log below records what is tested and what remains partial.
01 / HOW I BUILT IT
My design choice was to separate the AI from the memory and the work. An authorised assistant can use the same tools; each new connection still needs its own test.
ILLUSTRATE A DIFFERENT AI
ChatGPT: tested through local Hermes / Remote Desktop. Direct hosted attachment is not yet verified.
Interactive explanation. Switching a label here does not connect an AI account.
02 / IT REMEMBERS
The decision you made. The correction that mattered. The project you put on hold. Relevant context returns with its source, even in a fresh conversation.
Memory lives outside the chat provider. Facts, your decisions and AI interpretations keep their own labels. Sensitive records stay out of ordinary context.
How continuity was tested ↗A selected record, not a copy of every private conversation.
03 / IT WORKS WHILE YOU DON’T
Long work gets its own place in the queue. You keep talking. The job continues, the result is saved, and you can come back later.
Analyse recurring QUEST sellers.
Job accepted. You can carry on.
What did we decide last time?
Your decision, with its original context.
A six-second illustration of the queue. QUEST analysis remains partial. No real job is submitted.
A diagnostic job continued while another query returned, then a fresh controller retrieved the saved result.
Read the test ↗Small jobs can use a local model. Bounded tests ran with $0 API cost. When an answer needed stronger reasoning, the guard returned it for review. The test and its limits ↗
04 / IT WATCHES WHAT MATTERS
Three real research streams from Chris’s system. Each separates what a source says, what the data supports, and what still needs an answer.
Public ecosystem sources, pool observations and recurring-seller research. The question stays open until the evidence is strong enough.
WORKING Collection and evidence records
PARTIAL History is incomplete. Seller exhaustion is not proven.
A framework that follows announcements toward builds, pilots, deployment, users and economic activity. A headline is a starting point.
WORKING Official-source monitoring
PARTIAL Observed statements do not prove adoption or revenue.
Separate ecosystem progress from token value capture. Follow fees, demand and the staking questions that could change the thesis.
WORKING Source collection and review framework
PARTIAL Token capture remains an evidence question.
Research examples, not investment recommendations. Diagram shapes are illustrative. This page has no live connection to private research or financial accounts.
Conceptual flow. No private interface or host details shown.
05 / YOUR COMPUTER BECOMES THE WORKER
The controller reaches Chris’s own machine through an authenticated private connection. Background work can continue after the conversation ends.
Service restart and catch-up have been tested. The computer needs power and a connection to run new jobs; a full cold boot is still to be checked.
TESTED Service restart and private HTTPS access.
PARTIAL Physical-phone access and notification receipt remain to be checked.
06 / IT KNOWS WHEN TO STAY QUIET
A useful system shouldn’t become another noisy inbox. Alerts are collected in one place, repeated notices are grouped, and you can acknowledge what you’ve seen.
Failed work can ask for attention. Research keeps its uncertainty. Email and fitness alerts are future applications, not active integrations.
See the evidence. Decide the next step.
Illustrative alert. In-app alerts work; phone delivery still needs device acceptance.
07 / DREAMING · EXPERIMENTAL
The experimental reflection process reviews corrections, failures and repeated effort. It proposes lessons or improvements, with evidence behind them.
The system can suggest a change. It cannot grant itself more access, deploy consequential changes or turn its own inference into a fact.
EXPERIMENTAL / UNDER DEVELOPMENT08 / ROOM TO GROW
Start with something specific. Add a bounded capability when it earns its place. Keep the same memory, permissions and record of what happened.
Research is the first working branch. Email, fitness, travel, files and everyday admin are possibilities to build and test in their own time.
09 / WHY I BUILT IT
Every new chat meant explaining myself again. Useful work stayed trapped in old conversations. Long tasks made me wait, and keeping track of everything became another job.
So I designed a system with its own memory and a queue that keeps working after I leave the conversation. I connected local tools with cloud storage, then tested whether the context and results survived a fresh session.
I use it to keep decisions and follow research questions. Phone control is the next acceptance check. New needs can become new jobs, using the same memory and permissions. The useful parts can then be adapted for someone else.
The work, the tests and the limits ↗Chris Rothwell Founder, Acorn Labs10 / THE BUILD LOG
Each piece of work shows a problem, the design choice I made, a result I checked and a lesson I can use in the next build.
I separated context from the chat, then proved it could be recovered.Memory architecture · Retrieval · Recovery
I gave the worker ownership of the job, then reconnected to its result.Workflow design · Durable state · Testing
I made claims traceable to sources, with gaps kept alongside the evidence.Domain research · Data collection · Provenance
11 / WHAT THIS COULD DO FOR YOU
These are parts of my own system that might be useful elsewhere. Any adaptation would need its own scope and checks.
“I miss enquiries.”
Bring enquiries into a review queue and flag what needs a reply.
Starting point: tested jobs and in-app alerts. Inbox integration would be new. ↗“I never know what changed.”
Follow agreed sources and bring important changes back with the evidence.
Starting point: research collectors and the alert broker. ↗“We keep losing company knowledge.”
Make past decisions, corrections and sources retrievable by the right people.
Starting point: proven personal memory. Team access needs its own design. ↗“Competitor research takes hours.”
Collect relevant sources and keep observations separate from conclusions.
Starting point: evidence-led research. Your sources and questions set the scope. ↗“I keep repeating the same admin.”
Give a repeatable task a clear input, saved result and review point.
Starting point: the tested background queue. Your workflow still needs acceptance. ↗These are possible adaptations. Customer integrations, including inbox triage, still need to be scoped, built and tested.
TALK TO CHRIS
If something here looks useful for a problem you have, tell me about it.
Tell me about it ↗A conversation about what might be useful.
