Open Source AI Employees Should Be Files You Can Read, Not a Platform You Rent

On Saturday, September 19, the eight AI employees I built for my own business go public under the MIT license. Every routine, every schedule, every guardrail. Nothing held back behind a login.

Before that happens, I want to deal with a naming problem, because it decides whether anything you download under this label is worth installing.

"Open source AI employee" currently describes three very different things. Some are agent frameworks: good parts, no job. Some are self-hosted platforms: a stack of containers, a database and a vector store that wants 16 GB of memory before it does anything. And some carry a "community license" that forbids reselling the software or running a competing service, which is a perfectly legitimate choice and is not open source.

So here is how I think about the category, what is actually inside the eight I am releasing, what they cost to run, and where they stop.

What makes an AI employee actually open source?

Two tests. The license, and the shape.

The license test is the easy one. An open source license gives you the right to use, change and redistribute the thing without asking. The MIT license text is short enough to read in a minute: you may use, copy, modify, merge, publish, distribute, sublicense and sell copies, and the one condition is that the copyright and permission notice stays in. That is the whole deal.

The trap runs the other way too. A public repository with no license file is not free to reuse. GitHub's own licensing documentation is plain about it: without a license, default copyright law applies, and the author keeps the rights to reproduce, distribute and make derivative works. Being able to see the code is not the same as being allowed to build a business on it.

The shape test is the one that matters day to day. A framework gives you the parts to build an agent. An employee is already built, for a role, and it runs without you starting it. If what you download needs you to design the workflow, wire the tools and write the prompts before it does anything, you downloaded a toolkit. Useful, but not an employee.

Framework, platform or employee: which one did you download?

A fast way to sort anything wearing the label:

• A framework answers "how do I build an agent?" It ships code libraries, examples and abstractions. You write the job.

• A platform answers "where do my agents live?" It ships a server you host, a dashboard, a database, often a cloud tier. You still configure the job, now inside someone else's interface.

• An employee answers "who is doing this work tomorrow morning?" It ships a role, the rules it follows, the schedule it runs on and the routines themselves. You answer a few questions and it starts.

Mine are the third kind, and deliberately the smallest possible version of it. No server. No database. No dashboard to host. Each employee is a folder of plain text files that runs on your own machine, on the AI agent you already use.

What is inside one of my AI employees

Open any of the eight folders and you get the same set of files:

• An install prompt. What your agent reads once to set itself up. It researches your business from your public website before it asks you anything, writes its own strategy files, builds a dashboard and registers its own schedule.

• A role file. Who this employee is and how it thinks about the work.

• A contract. The rules every routine follows on every run: what it may touch, what it must never do, where it stops.

• A schedule. When each routine runs and the window it is allowed to work in.

• A releases file. Empty when it ships. This is yours, and it is where you hand over a channel (more on that below).

• A capabilities file. How the routines map onto whichever agent you run.

• A routines folder. One folder per routine, each with a single instruction file. Across the eight employees there are 59 of them.

That is the product. You can read every line before you run anything, which is the point of shipping it this way.

The eight roles:

1. GTM Engineer. Go to market and launch: positioning, the launch board, outbound drafts, directory and press forms, the weekly scoreboard.

2. SEO/AEO Employee. Search and answer visibility: keyword research, articles, indexing requests, rank review.

3. Web Dev Employee. Site health, error triage and small changes shipped through git with a report.

4. Social Media Employee. Platform native drafts in your voice, with a veto window before anything goes out.

5. Ad Manager Employee. Account reads, creative sets and build sheets. Money moves only when you approve it.

6. Sales Employee. Prospect sweeps, first touches written into your own drafts, follow ups that never go quiet.

7. Customer Satisfaction Employee. Inbox sweeps, replies drafted hardest first, churn flags with evidence.

8. Chief of Staff. Reads every other employee's run log and names what quietly stopped.

Why a scheduled routine is not a skill

This is the design decision people get wrong most often when they try to build their own, so it is worth a section.

A skill is something you ask for. A routine is a job that runs at its time, in its folder, whether you opened your laptop or not. If you copy an employee's routines into your agent's global skills folder, every routine loads into every session you open, and the agent can invoke one outside its window, where it does nothing useful.

Each of my routines carries its own window. If the machine was asleep and the job fires late, or fires twice, the routine checks whether today's work is already done or the window has passed, and exits. That one check is what makes an employee safe on any scheduler.

The scheduler you pick matters more than people expect. Claude Code's scheduling documentation spells out the difference: a loop inside a session stops when the session closes and recurring session tasks expire after seven days, while desktop scheduled tasks persist across restarts and run on your machine with access to local files, as long as the machine is on. An employee needs the durable kind. The install registers it for you.

The two guardrails, and the one you can loosen

I wrote about the general version of this in my AI agent approval workflow. Here is how it lands in the kits.

The first guardrail is on outbound actions, and it belongs to you. Every employee can technically send, post, submit, publish and spend. Out of the box, every one of those is held. The email is written into your drafts folder. The directory form is filled and left open on its last step. The ad campaign arrives as a build sheet. The last click is yours.

When you trust a channel, you release it in the releases file, one row at a time, with your conditions written next to it. From then on the routine that stages that channel completes the action itself and tells you in the next morning's brief what went out. Two of the eight ship with a channel ready for you to configure: the SEO/AEO Employee publishes articles to the blog you name, and the Social Media Employee hands posts to the channel you connect after a veto window.

The second guardrail is on credentials, and it stays on. No employee creates an account, enters or generates a password, completes a captcha, accepts terms or writes a credential into a file. You sign your browser in yourself. There is nothing to release here because the job never needs your password.

Those two lines are what let a business owner leave one running unsupervised, and they are why I was comfortable putting the whole thing in public.

What does it cost to run an open source AI employee?

The license is free. The model usage is not, and anyone who tells you otherwise is skipping a line item. I broke the full picture down in what it costs to run an AI agent; the numbers specific to these kits are in the repo's cost notes, measured on my own seat with dates and method attached.

The short version:

• On a Claude subscription seat, no dollars beyond the plan. An employee spends a share of your plan's usage limits. Measured over ten days, one employee's scheduled runs were a small single digit percentage of everything that seat sent, with a full working day of my own use on top.

• On a metered API key, roughly $19 on a plain weekday at list price for one employee, and closer to $500 across a month. Most of that is the agent re-reading the kit's documents on every turn.

• An API key also loses the browser lane, which most routines rely on to read your own signed in dashboards. So the subscription is the normal way to run these, not a discount.

Which AI employee should you hire first?

One. The one covering the work you are furthest behind on.

Every run schedules real work, and the first week of any employee is supervision: you read the brief, correct the standard in a sentence, and it carries that correction forward. Start with the role where a reliable morning brief would change your week the most, get that one steady, then decide whether a second is worth it.

If you have no clear bottleneck, start with the GTM Engineer. It has the longest production history of the eight: it has worked my own launch every weekday since late August. If you publish content, the SEO/AEO Employee. If you look after client sites, the Web Dev Employee.

The onboarding itself is a skill you learn once, and I covered it in how to hire your first AI employee.

If you would rather have a guided version, the free account in the Agent Ops Club builds one install prompt for whichever employees you pick and includes the walkthrough lesson. The eight employees never require it.

Can you sell AI employee installs to clients?

Yes. That is what MIT allows, and I chose it on purpose.

You can install an employee on a client's business, customize the role, the routines and the guardrails, and charge whatever you like for setting it up or running it. There is no revenue share and nothing to ask me for. The one condition is the license notice staying in the files.

Two practical notes. First, names and logos are not part of the license: a fork gets its own name. Second, premium employees I build later ship inside the club under a separate member license, and that license is the one that stops you handing the kit itself to a client. The open source eight are outside it entirely.

What happens on September 19

I am running a free live session on Saturday, September 19 at 10 AM Eastern: Open Source AI Employees: 8 Roles, One Repo, Live. Sixty minutes on what an AI employee actually is and the files inside one, the eight roles and which to hire first, and the repo going public. It is free, and the replay is included if the time does not work for you.

If you want to read ahead, the Hire Your First AI Employee replay covers the onboarding side and is available instantly.

Want the guided layer around them?

The employees are free for good. The Agent Ops Club is the layer around them for people who want more than a repo.

A free account gets you the install prompt builder, the walkthrough lesson, the session calendar and employee updates. Pro and Lifetime add the full Agent Ops Masterclass, the premium software library with a resale license for client work, and member events. Current plans are on the club page.

One small ask: if you are going to try one of the eight, start the free account before Saturday so the walkthrough is waiting for you when the repo opens.

FAQ

Are open source AI employees really free?

The files are. The MIT license costs nothing and never will. Running them uses your AI agent, so you pay for that the way you already do: inside a subscription's usage limits, or per token on a metered key.

Do I need Claude Code to run them?

No. They are written for Claude Code, which is what I use, and they are ready for OpenClaw, Hermes, OpenCode, Codex, Antigravity and a handful of other agents. The routines do not change between agents; one capabilities file per employee says how each agent does each step, and the install handles scheduling for the agent you run.

Does my business data leave my machine?

The employee's files, ledgers and strategy live in a folder on your own computer, and nothing runs on a server of mine. Your AI agent's provider still processes what the agent reads and writes, exactly as it does when you use that agent by hand. Keep the folder out of cloud sync drives: a working ledger and a syncing folder do not mix well.

What happens if my computer is asleep when a routine is due?

Depending on the scheduler, the job runs once late or is skipped. Either way the routine checks its window first, so a late run does the day's work once and a duplicate does nothing.

Can I change the routines?

Yes, every file is plain text in your own folder. The easiest way is to tell the employee in one sentence what it got wrong. It writes that correction into the file that governs the behavior, and the correction outranks the original from the next run on.