SilHills AI-OS

Over time I organized that folder around how I actually worked. I explained to an AI harness exactly how my work got done, then connected it to the tools my company already used so it could do some of that work with live data. Each piece made the next one easier to build, and without really knowing it, I had built the start of my first AI operating system.

Today I spend most of my day working through AI harnesses like Claude Code, Cursor, and Grok Build, and most of the routine work in my job, and across the business, runs through that system.

The change in my own day to day was big enough that it turned into an idea. If this worked so well for me in my job, other businesses could run the same way. That idea is what led Kallen and me to launch Silicon Hills Technology, and since then we've built AI operating systems with owners and operators across various businesses. Each one ends up with its own structure, but the same principles hold up across all of them.

Here is how it works.

What an AI-OS is

An AI-OS is an intelligence layer that sits inside the business you already run. It lives in one folder (a directory or a repo, on your laptop or on a server) and you work through it. It knows the business, it can reach the tools you already use, and it runs named jobs and workflows across both, whether you kick them off yourself or they run in the background on a schedule or trigger.

A few things make it different from "using AI":

• Context matters more than the model. Everyone has access to the same models. The advantage comes from what's in your folder, and from always asking what else the harness needs to work better for you.
• It sits on top of what you already have. You don't switch to a new platform. It works with your inbox, your CRM, your books, your files.
• You operate it. It's a system you orchestrate and guide to get real work done.
• It's alive. The information has to stay current. If the folder goes stale, everything built on top of it gets worse.

The reason it matters: most owners and operators, and really anyone whose job keeps a business moving, spend around 80 percent of their time keeping things running and only 20 percent on new initiatives that help it grow. The OS exists to shift that ratio over time.

The four layers

1. Context: what the system knows
2. Data & Tools: what it can reach
3. Abilities & Intel: what it can do
4. Automation: what runs without you asking

They're built in order, and each one is only as good as the one under it. A system with no context gives generic, unfocused answers. A job that can't reach live data has to be fed by hand every time. Automation on top of either just runs the wrong job faster.

Most people already have pieces of this. The work is knowing what to put in each layer so the system works for you, and fixing the thin one before building higher.

Layer 1: Context

Context is the system's source of truth about you and your business. Every session starts from it, and everything the system does after that is steered by what is in it.

What goes in it

• Who you are: persona, your voice, your values
• How the business works: the model, pricing, process, pipeline, market
• Who the people are: team, roles, clients, vendors, who makes which calls
• What's live: current projects, deals, deadlines, open loops
• What's settled: past decisions, constraints, preferences, your rules, hard no's

A few things stay out. Passwords, API keys, and other logins belong in a secrets manager. Data that already lives in your tools, like email threads or customer records, stays in those tools instead of getting copied into the folder. The system reaches that data through the tools it's connected to, and the logins stay with you.

How to organize it

How you organize the folder matters as much as what goes in it. The harness doesn't read everything at once. Some files load the moment a session starts, and the rest get pulled in only when the work calls for them. Deciding which is which keeps the system fast and focused.

• Instruction files load automatically. The main one sits at the root of the folder, usually named AGENTS.md (or CLAUDE.md in Claude Code), and gets read every session, so every line has to earn its place. Keep it to how the folder is laid out, where things live, and the few rules that apply to every task. Each area of the business, like a department, a client, or a project, can have its own instruction file that only loads when you're working in that area.
• Reference files load on demand. They hold the detail: the pricing sheet, the SOP for onboarding a client, the contract template, notes from last week's call. The instruction files say where each one lives, so the system opens the onboarding SOP when you're onboarding someone and leaves it alone the rest of the time.

Here's what that looks like in the starter kit we set clients up with. The root instructions file explains how the folder works and tells every session to read three short context files: one on the business, one on the tools and accounts it runs on, and one on the operator's role and voice. Everything else lives in its own folder and stays closed until a task needs it: references for the documents you reuse, projects with a folder for each piece of work, skills for named jobs, and an archive for anything superseded.

My own system works the same way at a bigger scale. One folder holds my personal work and the business side by side, each with its own instructions file, and a single map says where every kind of information lives. Inside the business, each client gets a folder with its own instructions file, its setup, its agreements, its deliverables, and project tracking, so a session working on that client sees that client and nothing else. That way I can go deep on one project or task at a time without the rest of the business getting in the way.

Two habits keep the folder clean as it grows. First, give every piece of information one home and reference it from everywhere else. Update it once and it's updated everywhere, which prevents drift and keeps the system clean and accurate as more context gets added. Second, when you catch yourself explaining the same thing twice, write it into the file where it belongs.

Where to start

You don't have to build the folder by hand. Open a harness in an empty folder and describe, in plain English, what you do and what you're trying to achieve. It will help you lay out the structure and write the first files.

From there, the system can help keep itself current. At the end of a session, ask it what it learned or what changed, and have it file that where it belongs. A new client, a changed price, a decision you made on a call. When something changes in the business, it should change in the folder too, and most of that upkeep can happen as part of the work instead of as a separate task.

Takeaway

Every other layer draws on this one. A connected tool is only useful if the system knows what it's looking at, and a skill or task only does the job right when it has the right knowledge to work from. Get the context right and everything you build on top of it starts from the same place you do.

Layer 2: Data & Tools

Data & Tools is what the system can reach and act on. It plugs the system into your workspace and your company's data, so it works from what's live: today's inbox, your calendar, the deal that moved yesterday.

The easiest way to decide what to connect is to start with the data. What would the system need to see to do the work you do? Usually that's some mix of email, calendar, files, contacts and deals, invoices, contracts, and meeting notes. Then connect the tools that hold it. For a typical business, that looks something like this:

• Google Workspace or Microsoft 365: email, calendar, docs, and sheets
• A CRM: contacts, deals, and the pipeline
• QuickBooks or Stripe: invoices, payments, and the numbers
• A meeting notetaker: call notes and transcripts
• Slack or Teams: team conversations and communication

Add any other tool your company uses day to day. The folder from Layer 1 sits alongside all of it, so the system reads the live data with your context already in hand.

How it connects

The harness reaches each tool through a connector. A connector signs in as a specific account, and that account's permissions set what it can do. There are a few kinds, and which one you use depends on what the tool offers:

• MCP servers. A standard way to hand the AI a set of tools. Major apps usually have one. You add it to your harness, sign in to approve access, and it's connected, which makes MCP the easiest place to start.
• CLIs. Tools the system drives by typing commands in a computer terminal. Models already know terminal commands well, and a CLI only takes up room when a command runs, so it's usually faster and far lighter than an MCP server. The tradeoff is that it has to be set up on each computer and gets the full access of whoever signed in, so it fits best for one person on their own machine.
• APIs. The front door a piece of software offers to other software. The system calls a specific endpoint, like create an invoice or list new contacts, and gets back exactly that, which makes APIs precise, fast, and cheap to run. Nearly every tool has one, even when it has no MCP server or CLI. The tradeoff is setup: someone has to manage the keys and work through the tool's documentation, which the system can help with but takes more effort than a sign-in.
• Webhooks. A tool sends the system a message when something happens, like a new form submission or a paid invoice. These matter most once you get to automation.
• The browser. The system clicks through a website the way you would. It works for tools with no other way in, but it's slower and breaks more easily, so save it for last.

Each connection goes both ways. The system reads live data and writes back when the job calls for it, like moving a deal forward in the CRM, adding a meeting to the calendar, or saving a document to the right folder.

This article is a small example of all this working together. I wrote it in a Google Doc and left comments on the parts I wanted changed. The system read those comments through the Google Workspace CLI, rewrote each section using my writing style and the other context already stored in my system, and resolved the comments when it was done. I never pasted a line of it into the chat.

Connect what you use

It's tempting to connect everything, but every connection has a cost. In many harnesses, each connected tool loads a description of itself into the session before you've typed anything. Stack up enough of them and you get context bloat: tool descriptions crowd out your context, and every session gets slower, costs more, and picks the wrong tool more often. Before you connect something, just ask yourself: does it earn its place?

The fix is the same idea behind organizing the folder in Layer 1: load what the work needs, when it needs it. In practice that comes down to a few moves:

• Connect tools where they're used. Many harnesses let you set up a connection for one project folder instead of everywhere. Your finance folder can load QuickBooks while your marketing folder loads analytics, so each session only sees the tools that work needs.
• Turn off what you aren't using. You can usually switch a connection off without removing it, so bringing it back for a task is one toggle.
• Use a CLI for the tools you reach for constantly. It costs almost nothing until the system runs a command.
• Check whether your harness loads tools on demand. Some harnesses only pull in a tool's description when the system goes looking for it, which handles a lot of this for you.

If it still feels like a lot to manage, ask the system to look at what's connected and suggest what to switch off.

Keep the keys yours

Layer 1 kept passwords and keys out of the folder and the logins with you. Here's how that works in practice:

• Keys live in a secrets manager. Each key is stored encrypted in one place and pulled in only for the call that needs it, usually as an environment variable or a short-lived token, so it never lands in a file or shows up in the chat. Because every connection reads from that one place, replacing a key is a single update, and some secrets managers can rotate keys for you on a schedule. Keys pasted into docs, notes, or chat threads are one of the most common security gaps in a small business, and one of the easiest to close.
• You own every login. Each connection signs in as your account or your company's account, so the access stays with you. Switching harnesses or computers means reconnecting, not starting over: sign in to the MCP servers and CLIs again, and point the new setup at the same keys.
• Review each connection one setting at a time. Each connection has its own permissions for what the system can see, change, and do in that tool. Turn on only what the job needs, let the system read before it writes, and keep anything you can't undo waiting on your yes.

Where to start

Pick the two or three tools you live in and connect them one at a time. The big ones usually have a ready-made connector, and when one doesn't, the system can walk you through setting it up.

Once a connection works, do two things. Have the system write down how it was set up, in a short doc or a skill, so you can reconnect or swap the tool later without starting over. Then add a line to the context file on your tools and accounts saying what each one is for: which inbox is sales, which payment account is live, what lives in which drive. That way the system knows what it's looking at when it gets there.

Takeaway

Context gives the system the knowledge, and tools and data put that knowledge to work on live information. With both in place, the system knows the business and can see the work as it happens. That sets up the next layer: the system doing the work for you.

Layer 3: Abilities & Intel

This is where what the system knows and what it can reach turn into finished work. Abilities are the actions: draft, file, schedule, follow up, research, reconcile, update the CRM, track projects, pull the numbers. Intel is the judgment: how you decide, what done looks like, what to ignore, what to escalate, your tone and priorities. Put the two together and you get named jobs the system can run from start to finish, written down as skills and sometimes built into full automations.

A few jobs a skill can take over:

• Inbox triage: sort what came in, draft replies to the routine ones, and flag what needs you
• Meeting prep: pull all the deal context, from past call notes to recent emails, into a one-page brief
• Invoice follow-up: find what's overdue, check whether it's been paid, and draft the reminder in your voice
• Lead follow-up: log the new lead in the CRM, research the company, and draft the first reply
• Project and job tracking: update where each job stands from emails, notes, and messages, and flag what's falling behind
• Weekly reporting: pull the numbers and write up what changed and why

Each one leans on the layers under it. Context tells the system how you do the job and what good looks like, and the tools and data give it the live inbox, calendar, CRM, or any other tool the job needs.

What a skill is

A skill is a markdown file that holds the recipe for one job. It lives in a skills folder from Layer 1, and like the reference files, it only loads when the work calls for it. Harnesses that support skills read a short description at the top of each one and open the full file when your request matches, so you can keep dozens of skills without bloating the session. That description decides whether the skill gets picked, so write it to say plainly what the job is and when to use it.

A good skill covers a few things:

• When to run it. Usually a phrase you say, like "prep me for my call with" a client, or a slash command like /meeting-prep.
• What it reads. The context files, references, and tools the job needs, so the system pulls the right material every time.
• The steps. How you actually do the job, in order, including the judgment calls you make along the way.
• What done looks like. A template or an example of the finished output, and where it gets filed.
• Scripts for the exact steps. Anything that should run the same way every time, like a calculation or a file export, can go in a small script the skill runs, so the system doesn't improvise it.
• What it must not do. For example: send anything without your yes, change a price, or touch work outside the job.

How skills get built

There are two ways, and both start from real work:

• Build it forward. Describe the job and have the system draft the skill with you. Some harnesses have a skill creator built in that walks you through it. Run it, fix what it got wrong, and update the file. The first run won't be perfect, and it gets better a little every time.
• Reverse-engineer it. Do the task with the system the long way, going back and forth until you have an output you love. Then ask it to turn what you just did into a skill. Next time it runs without the hand-holding.

Either way, anchor the skill to a template or a single example of the output you want, and iterate from there until it's right. Every time you fix an output, have the system write that fix into the skill, so you only make each correction once.

How skills work together

Once you have a few skills, you can start stacking them:

• Keep each skill to one job. Small skills are easier to correct and easier to reuse.
• Let skills call other skills. A weekly report can run the pipeline skill and the invoice skill, then write one summary from both. Improve a step in one place and every skill that uses it gets better, the same one-home idea from Layer 1.
• Hand heavy work to subagents. A subagent is a separate session the main one sends off with a narrow task, like researching ten leads at once or reading a long contract. It works in its own space and hands back only the result, so the main session stays focused on the job in front of it.

Layered skills pay off most on bigger jobs with a lot of steps, and a few subagent patterns go a long way toward keeping that work consistent from run to run. How to set those up is a topic for its own article.

Where to start

Pick a job you do every week where you know what the finished output should look like. The boring ones make the best first skills: they're easy to check, and you get the time back every week. Do it once with the system, turn it into a skill, and keep correcting it until you'd trust the output without redoing it.

Then look for the next one. Any time you ask the system for the same kind of thing twice, turn it into a skill.

As the skills folder fills up, keep it organized. Every few weeks, or once a month, run a skill audit: check which skills are actually getting used, update the ones that have drifted, and remove the ones that are outdated. The system can run that audit for you.

Takeaway

Context, tools, and data give the system what it needs to know and see. A skill puts the AI in a box: the right context, the right data, and a clear picture of good output, and inside that box it goes to work. Once a skill runs well when you trigger it by hand, the next question is whether you need to trigger it at all. That's the next layer.

Layer 4: Automation

Automation is what runs without you asking. A job starts on a schedule or when something happens, runs from start to finish with no questions along the way, and leaves the result for you to check. Most of these jobs are the skills from Layer 3, and some are simple workflows that don't need AI at all. This layer decides when they run and where.

A few jobs that can run on their own:

• Morning brief: before you sit down, today's calendar, what came in overnight, and what's due, in one list
• New lead to CRM: a form submission or a booked call creates the contact and the deal in the CRM and notes where it came from
• Payment received: a paid invoice gets matched to the client, the receipt gets filed, and the books get updated
• Call wrap-up: when the notetaker finishes, the notes land in the client's folder and the action items land in the project tracker
• Context upkeep: every night, the system files what changed that day back into the folder, so Layer 1 stays current
• Health checks: backups run, logins get checked before they expire, and anything broken gets flagged

Sort the work first

Not everything should be automated, and not everything that should be needs AI. Every job in a business is one of three kinds:

• Deterministic work. The steps are the same every time, like sending a reminder on a date or copying a paid invoice into the books. It can be automated right away, and it usually only needs a simple workflow or script, no AI.
• Judgment work. You have to think, but you can explain how. This is what skills and agents are for. Automate it only once the skill already runs well when you trigger it by hand.
• Decisions. You still have to choose. The system gathers the material and lays out the options, and the choice stays with you.

A majority of the time what people assume needs AI turns out to be deterministic work. Keep that simple and save the model for the judgment.

What starts a job

Every automation needs something to start it. There are two kinds:

• A schedule. The classic tool is a cron job: one line that tells a computer to run a command at a set time, like every weekday at 7am or the first of the month. A background program on that computer checks the clock every minute and runs whatever is due. Many harnesses now have their own scheduler, so you can set the time in plain English instead of writing the line yourself.
• An event. This is where the webhooks from Layer 2 come in. A webhook is a message a tool sends to a web address the moment something happens. When an invoice gets paid, the payment tool sends the details to that address, and whatever is listening there starts the job. You choose which events send one, usually in the tool's settings.

Both need a computer that's on when the moment comes. A cron job on a closed laptop doesn't run, and a webhook sent to a laptop that's asleep goes nowhere.

Where automations run

There are three places, and most setups end up using more than one:

• Your own computer. The easiest place to start. Your harness can run a scheduled task while the machine is on, which is fine for a morning brief you read at your desk.
• A hosted environment. A computer that never sleeps, which you can get two ways: rent one from a cloud provider like AWS, Azure, or GCP, or run a physical server you own. A self-hosted server has to stay powered and reachable from the internet to receive webhooks, which a cloud provider handles for you. Either way, it holds a copy of your folder, runs the cron jobs, listens for webhooks, and can run a harness with no chat window open. Workflow tools like n8n run here too and handle the deterministic work.
• A cloud agent. Some harnesses will run a session on their own infrastructure, like Claude Code routines or Cursor's cloud agents. You give it your repo (your folder in Git), your connections, and the skill to run, and it runs on a schedule or an event with your laptop closed.

Wherever a job runs, it needs the same context and tools it has when you run it by hand, with nobody there to sign in. That means the folder is the same everywhere, and every place pulls its keys from the secrets manager instead of relying on a login that times out.

Here's what that looks like for us. Our business folder is a Git repo, and the same repo lives on our laptops and on a server. The server runs our website, our dashboard, and n8n, which picks up a contact form the moment someone submits it. When we ship a change to the dashboard, a cloud agent can deploy it to the server without anyone opening a laptop. It's one system running in several places, and every piece is built on the same three layers underneath.

Keep an eye on it

Once jobs run without you, you need a way to see what they're doing. Give your automations an audit log, and a place where each run reports what it did, what it skipped, and what failed. That can be a Slack channel, a daily note, or even a simple Grok Bot that messages you a summary. A quick look there tells you which automations are healthy, which ones are failing quietly, and which ones nobody needs anymore. Watch new automations closely at first, and once they've earned your trust, let them run on their own.

When a run goes wrong, the fix is almost always in a layer underneath: missing context, an expired connection, or a skill that needs another correction. The more dialed in the first three layers are, the less there is to watch, and the more the automations just work.

Where to start

Start with the boring version: a morning brief, a reminder, a weekly summary. Then work up.

To find what's next, list the areas of your business and, under each one, every small task that repeats. Start with the ones that are easy to automate and give back the most time, and work down the list. Aim for 60 to 70 percent of the routine work, not 100. The rest is work that still needs you in the loop.

The skill audit from Layer 3 helps here too. A skill you trigger by hand every day is a skill that should probably just run.

Takeaway

Context tells the system what it knows, tools and data let it see and act, and skills make the work repeatable. Automation takes the last step and runs that work on its own, on your computer, a hosted environment, or a cloud agent, so the routine parts of the business keep moving whether or not you're in the chat.

Where this leaves you

Looking back, those first few files were where the context started. The rest came one at a time, in the order this article walks through, because each layer only worked once the one under it was solid.

Connecting the tools let that context work on live data. Writing down how I did each job turned repeated requests into skills, and once those skills ran well by hand, they started running on their own.

Today the system handles most of the routine work, and the upfront effort to build it has paid for itself many times over. The hours it saves go to growing the business.

Your job changes with it: less doing every task by hand, more directing the system that does.

You don't need all four layers to start. Open a harness in an empty folder, write down what your business does and how you work, and build from there. That's how mine started, and it's where Kallen and I start with every business we work with.