Six weeks before this repo went public I had never written a line of code. No job in tech. I'm 49.
I'm putting that at the top because it should change how you read the rest. I'm not going to pretend I'm an engineer who knew what they were doing. I'll show you the decisions that ended up in the build, explain why they're there, and be honest about the bits where I was lost and asking an AI "is this stupid?" over and over until something worked.
The project is Mission Control. It's a self-hosted agentic OS. You chat with an always-on agent (I called mine Dave), and when you want to separate tasks he hands it to a pipeline: a repeatable workflow run by a team of agents. It runs on your hardware, with your choice of model, free and local through LM Studio or Ollama, or a paid cloud model through OpenRouter. The code is open source under MIT and it's mostly TypeScript.
Here are the parts I think are worth your time, whatever your experience level.
Chat and pipelines are two different things, on purpose
When I started I thought the goal was one clever agent that reasons its way through anything. That's how a lot of agent demos work. In practice it was a mess. It would improvise the next step, get it wrong, and I had no way to audit it or pick it back up after a crash.
So Mission Control splits the work in two. Dave is the chat: conversational, improvised, and capable of real work on his own. The only ceiling on what he can take on is context length, which comes down to your hardware. Pipelines are for work you want done the same way every time, with a budget, optional human approval, and a saved report at the end. A pipeline is a recipe written as a YAML file. You can start one yourself from the Pipelines section, or just ask Dave in chat to fire it off. Either way, once it starts a plain runtime drives the steps, not the model.
The difference matters most on small models. I run most things on a local model on a mini PC, and free-form agent loops fall apart there. A pipeline doesn't care how clever the model is, because the model isn't deciding the order of things. The steps are.
Splitting it this way had a payoff I didn't plan for. Because chat and pipelines each point at their own model and provider, I can run two at once. The best part is Dave kicks it off himself: I'll be chatting with him on the local model on my mini PC, ask him to take on a bigger job, and he fires up a pipeline that runs on a cloud model while we keep talking, separate contexts, neither one blocking the other. Nothing forces a particular split: either side can be local or cloud, so I can chat local while a cloud pipeline runs, flip it, or run both on cloud on different models. Whatever fits the job. That still feels like a cheat code to me.
Three tiers, and workers that can't talk to each other
The agents are arranged in three tiers, each with one job.
Dave is tier one, the personal agent you actually talk to. He has chat, 17 built-in tools, and memory that survives between sessions. The Orchestrator is tier two. It doesn't do tasks itself, it breaks them up and hands them out. The workers are tier three, a Researcher and a Coder for now, each doing a single job and returning a result.
The rule I'm glad I stuck to: workers only ever talk to the Orchestrator. Not to each other, not to Dave directly. And it isn't a polite guideline, it's enforced in the code. Workers don't get the tool that spawns other agents and don't get the one that sends messages, so they can't start a conversation with anything. Hub and spoke, by construction.
I needed it built that way for a selfish reason. I couldn't hold a tangle of agents talking to agents in my head. With this layout, when something breaks there's a short list of places it could have broken.
Memory that doesn't quietly lie to you
The tool I learned on used to throw away context silently to save space, so my agent would forget things mid-task with no warning. That drove me up the wall, so memory here has one rule: nothing happens silently.
Short-term daily notes fade after about a week. Milestones stick around, and the agent decides what's worth keeping. Everything is stored locally in SQLite, so it's on my machine, searchable, and pulled in only when it's needed rather than sitting in the context window costing tokens. When the agent does forget something, it's because it chose to, not because the tool truncated it behind its back.
The night it nearly killed my computer
It was not all clean decisions. One night a background loop I'd set up wrong slowly ate the machine's memory until the whole thing seized. Fans screaming, cursor stuttering, five seconds a click. I couldn't tell you which of the commands I'd pasted in caused it, because I didn't really understand any of them.
Another night I came back to a workspace wiped clean by a file-sync I'd set up wrong. Days of work gone.
That second disaster is why everything important is now stored in the database rather than loose on the filesystem, and why the system logs what it does. When something goes wrong I can actually trace it now, which I could not do on the nights I needed it most. I built the boring safety parts because I'd already lived without them.
Things I deliberately kept locked down
A few of the safety choices, in case they're useful if you build something similar:
The shell tool is off by default. It only runs inside the workspace folder, it's stripped of your secrets, it's time-limited, and you have to give an explicit confirmation before you can even turn it on. The gateway checks the origin of every connection and needs a token, so nothing connects to it without permission. API keys are encrypted at rest and never written to logs. File tools can't climb out of the workspace folder. Pipelines have hard token and cost ceilings and stop themselves if a step keeps failing, so nothing runs away with my money while I'm asleep.
None of that is clever. It's the stuff I wish I'd had on the bad nights.
What I brought to it
What I brought was the decisions, the questions, and a refusal to let anything through that I didn't understand or that wasn't up to standard. I held a hard line on quality the whole way: if a part wasn't right, it didn't ship.
The scariest call I made was tearing out the foundation the whole thing sat on and rebuilding it to stand on its own, with no dependency on the tool I'd started with. It worked. That turns out to be enough to get to real, defensible architecture, even starting from nothing.
Try it, or tear it apart
It's free and open source. I'd honestly rather you find the holes than tell me it's nice.
- Mission Control (MIT): https://github.com/OldGenAi/mission-control
- The setup guide I wrote documenting every wall I hit (free): https://github.com/OldGenAi/wsl2-openclaw-setup-guide
If you're somewhere near where I was a couple of months back, staring at an error that might as well be in another language, sure everyone else finds this easy: it looked exactly that hopeless from my chair too. What got me through wasn't talent. It was one more question, and then one more after that.