88 Skills, 194 Decisions Logged, One AI System That Actually Runs My Business

Most people are using the most capable AI models ever built like a vending machine. You put in a question, it gives you an answer, you close the tab, and it forgets you existed the second the window shuts. I got tired of re-explaining my own business to it every single day, so I stopped building a chatbot and started building it an operating system instead.

Here’s what that actually means in practice: a memory that never resets between sessions, 88 skills it now runs that I built one at a time as the same work kept repeating, a connected second brain with 13 wiki pages distilling what matters, and 194 decisions logged in a file it checks before it acts. It doesn’t answer my questions anymore so much as carry the context of the business forward and act inside it.

Why “just use a chatbot with memory” isn’t the same thing

The default assumption is that turning memory on in a chat app closes the gap. It doesn’t, because memory alone is still one flat list the model skims, not a system that knows which of 88 repeatable jobs it’s currently doing or which of the last 194 decisions constrains this one. A chatbot with memory still starts every session from a question. An operating system starts every session already knowing what it’s for.

The mistake that actually built this

I didn’t design this system on a whiteboard. I built the memory layer because I caught myself answering the same strategic question three different ways across three different weeks, since nothing forced me to check what I’d already decided the first time. That’s the failure that actually mattered: not that the AI forgot things, but that I did, and it had no record to catch me. The decision log came first, before any of the 88 skills. Everything else got built because the same problem kept showing up in a new shape: the same email triage happening from scratch every morning, the same proposal structure rebuilt from zero for every prospect, the same research pattern repeated by hand. Each repeat became a skill instead of staying a repeat.

What’s actually running under the hood

The decision log came before any of the 88 skills.

Persistent memory. Every session starts by reading the same context files instead of asking me to re-explain the business, so a decision made in July doesn’t get silently re-litigated in September.

88 skills, built one at a time. Each one is a folder with a single instruction file covering one job I noticed I was doing manually more than twice. The first time I counted, it was 51. It’s 88 now, which is less a finished system than a compounding one.

A second brain. A 13-page wiki plus a knowledge graph, kept separate from the live business data but wired to it, distilling what’s evergreen (positioning, offers, past decisions) out of what’s just in-flight.

A decision log. Every meaningful call gets one append-only line: what was decided, why, and the context around it. It’s the file that stopped me from re-deciding the same thing three times in one month.

A command layer with real limits. A cockpit that renders every skill, project, rule, and decision as one graph, and a guarded deck that can only fire preset commands, never freeform ones typed into a browser.

The guardrails matter more than the autonomy

Five limits that make it safe to leave running.

Autonomy without limits is how an automation story turns into an incident report. The command layer only runs entries from a fixed preset list, never raw prompts from wherever a request came from. Anything it runs is scoped to its own workspace with no shell access, on a five-minute wall clock, one job at a time so nothing fans out unsupervised. If a run’s estimated cost passes 50 cents, the whole deck locks until I acknowledge it by hand. Every run writes to an audit log whether it succeeded or not. None of that is exciting to build. All of it is the reason I’ll actually let it run unattended instead of babysitting every session, which is the entire point of a system instead of a chat window. It’s also the exact gap I flagged from the enterprise side in the piece right before this one: a small operator doesn’t get a platform team’s review layer for free, so you build the limits into the workflow yourself or you find out the hard way.

What it actually runs

Outreach, content, and proposals move through this system end to end, not as three separate tools I switch between but as one place that already knows the context for all three because it’s the same memory and the same decision log underneath. Nineteen active projects live inside it at once. None of that replaced judgment. It replaced re-explaining the same context to get to the point where judgment was even possible.

Frequently asked questions

Do I need to be a developer to build something like this?

You need to be comfortable enough to describe a repeated workflow precisely, which is closer to writing a clear process document than to programming. The code that reads memory files and runs skills gets built once. Adding the 89th skill is writing down a job in plain language, not writing software.

How is this different from just using an AI chat app with memory turned on?

Chat memory is a flat log the model skims at the start of a conversation. This system has 88 distinct, named jobs it can run, a structured decision history it checks before acting, and a second brain that separates what’s evergreen from what’s just in-flight. Memory is one ingredient. The skills and the decision log are what turn it into something that acts instead of just recalls.

How long did it take to get to 88 skills?

I don’t treat it as a project with an end date. The first count was 51 skills; it’s 88 now, added a handful at a time, each one built the moment a task repeated for the third time rather than batched into some big rebuild. The count keeps climbing because the business keeps changing.

What happens if it tries to do something it shouldn’t?

It can’t get far. The command layer only fires from a fixed preset list, has no shell access in its scoped runs, locks itself when a run’s projected cost crosses a fixed ceiling until I clear it by hand, and logs every attempt either way. The guardrails are designed to fail loud and stop, not fail silent and continue.

Can this run a business without a human checking anything?

No, and it isn’t supposed to. It removes the re-explaining and the re-deciding, not the judgment calls. I still approve anything client-facing or financial. What changed is how much context I have to reconstruct before I can make that call, which used to be the actual bottleneck.

The part that generalizes

What actually changed wasn’t the AI getting smarter. It was refusing to let it forget, then giving it somewhere to put what it learned instead of losing it at the end of every session. If you’re running anything with repeat work in it, you don’t need 88 skills on day one. You need the decision log first, then the first skill built from the workflow you’re most tired of doing from scratch, before you build anything else.