More of my clients are coming to me lately with a specific question: how do I actually put AI to work in my business? Many are still using it as just a smarter search engine, while more tech-forward ones are using it as a reasoning partner, and that’s fine as far as it goes. But increasingly, the conversation is about something different: letting AI perform actual tasks the way a junior employee might, rather than just answering questions.
And every time that conversation gets serious, the same fear starts to show up. If I take the chains off AI, how do I know it doesn’t hallucinate and do something that will hurt my business?
That fear is reasonable. But I’d like to share an operating system design that addresses that fear.
Why This Fear Is Justified, and What Fixes It
AI already reasons well. That’s not really in question anymore. But it reasons generically. Ask it to take an action on your business’s behalf without describing the nuances of your business, and it defaults to generic action, the kind of thing that’s true of businesses in general, not necessarily true of yours. That’s not a hallucination in the strict technical sense, but functionally, it’s the exact failure the fear above is about.
I wrote about this gap in more depth in The Evolution of AI: Why It’s an Architecture, Not a Timeline, for Your Business. There, I called it Business Representation, one of four dimensions AI needs to mature along before it becomes something you can actually trust to perform work. Now I want to pick up on that thread and make the process of creating it a bit more concrete.
That written knowledge about your business doesn’t show up on a schedule, either. It shows up mid-job, mid-conversation with a client, on a drive between appointments, whatever hour you’re actually thinking about your business, which for most small business owners is well past nine to five. That’s the case for building a habit of capturing it wherever you are, not waiting until you’re back at a desk. More on exactly how I do that a little later in this post.
What “Taking the Chains Off” Actually Looks Like
When clients describe what they actually want AI to take off their plate, the requests tend to fall into a handful of categories. Responding to routine inbound questions from prospects instead of the owner fielding every one personally. Watching accounts that have gone quiet and flagging them before they’re lost. Generating invoices and following up on the ones that go unpaid. Reordering supplies before they run out. Confirming bookings and scheduling within the business’s actual capacity. None of them are crazy difficult, but they’re time-consuming and require vigilance to keep them from falling through the cracks.
None of that is “run my business.” They are tasks, the kind you’d hand to a junior employee or admin with clear instructions, not the keys to the whole operation. Nobody sets AI up like this and walks away.
But none of it works, not safely, until the AI has access to information about the business. When you hand a task to AI without any context, it falls back on generic defaults, which is exactly the failure mode described above. So, the real question isn’t whether AI can do these things. It’s how you provide it with instructions and boundaries, often called the “harness,” so it understands what it can and can’t do and knows your business well enough to act reliably.
Two Things AI Needs to Know
That harness is made of two different things, and it’s worth naming them separately before going further.
AI needs to know what things are: what a customer is in your business, what a vendor is, what a project is, structured and named consistently so it isn’t guessing. And it needs to know what to do when something happens: a rule for handling a problem when one shows up, or an opportunity when one opens up. I think of the first one as Bones and the second one as Muscles. Both live inside Business Representation, the dimension I described in Evolution of AI.
The names aren’t decorative. Bones are relatively fixed once they’re set, the same way your actual bones don’t change much day to day. Muscles are different. They get stronger with use. Every time a new problem or opportunity gets worked through, the rule library gets a little thicker, a little more capable, the same way a muscle strengthens with repeated use. Bones and Muscles together are the harness.
If this sounds like it’s just a fancier name for a policy manual, it isn’t, and the difference is important to understand. Plenty of businesses already have standard operating procedures (SOPs). Those still worked because a person read them and applied judgment before acting. What’s different here is the precision, but precision doesn’t mean hard-coding a rule for every possible situation the way older automation tried to. That approach breaks the moment something new happens, and in a business, something new happens constantly. What AI actually needs is enough knowledge that it can make its own inferences when a situation shows up that nobody wrote a rule for, and that’s the real difference between knowledge and wisdom.
I’ve written elsewhere about that climb, from data to information to knowledge to wisdom. For example, data might be the color red. Information is that stoplights and road flares are red. Knowledge is knowing what each one means: a stoplight means stop, a road flare indicates caution, each meaning learned somewhere along the way. Wisdom is what happens when you see something new you’ve never encountered before. A red light on a car dashboard you don’t recognize still lets you infer how to treat it: pay attention, check what’s wrong, without anyone ever having written you a rule for that exact case.
A harness has to be precise enough that AI can act on it directly, without a person standing in the middle translating intent into action, and rich enough that it can reason its way through the situations nobody thought to write down.
Both Bones and Muscles get built the same way: you start with something specific, such as a business plan for Bones, a problem or an opportunity for Muscles; you have a real back-and-forth discussion with AI about it, and what comes out the other side is a document you keep as a data source for AI. Not a diagram, not a transcript, not a memory of the conversation. That method doesn’t change. What changes is what you’re pointing it at.
Bones: What Things Are
Let’s start with Bones, because for most established businesses, a good chunk of it already exists in some form. If you’ve written a business plan, feed the whole thing to AI as your starting point; don’t summarize it first, just let it ingest the real document.
If that plan doesn’t already include a Business Model Canvas, that’s where you bring one in. The canvas covers nine boxes: your customer segments, value proposition, customer relationships, channels, revenue streams, cost structure, plus key partnerships, activities, and resources.
Around the outside of your business model canvas sit four external forces worth checking your model against: Market Forces, Key Trends, Industry Forces, and Macroeconomic Forces. I’ve written about each of those separately if you want to dig in.
If you’re newer and don’t have a plan like that yet, I’ve put together a full sequence of prompts in a post called Useful ChatGPT Prompts for Starting a Small Business for building one in one sitting: your target market, a SWOT analysis, PESTEL, Porter’s Five Forces, demographics and psychographics, competitor and regulatory research, the whole thing. That post was written for someone who hasn’t opened their doors yet. This piece assumes you have, and that you’re now trying to automate parts of a business that’s already running.
If you’d rather understand any one of those pieces in real depth instead of just running the prompt, I’ve written about each of them separately too:
Use the prompt if you just want the output; read the deep dive if you want to understand what you’re actually looking at.
Even with all that information, there’s still a knowledge gap, as it stops at the category level and provides no specifics. For example, the digested information might tell AI that your ideal customer is a mid-size local business needing quarterly catering, but it won’t tell you that a specific customer record needs an email address, an assigned account manager, an active contract, and a contracted rate. That’s a different, more granular layer, and it’s worth borrowing some precise language to talk about it.
A taxonomy is a hierarchy of categories, broader types and narrower types nested under them. Your Business Model Canvas work already produces this. It’s telling you what kinds of things exist in your business: customers, vendors, projects, without going much deeper.
A thesaurus builds on that. It’s where you reconcile the fact that the same thing gets called different names. Maybe your team calls a client a “corporate client” one day and a “corporate account” the next. Not a mistake exactly, but if it never gets reconciled, you end up with duplicate, disconnected versions of the same customer scattered across different documents, which nobody notices until it’s already caused a problem. A thesaurus is just where you write down that these are the same thing, and what you actually mean by each term.
An ontology takes it a level further: explicit, specific relationships and actual attributes, precise enough for AI to use directly. This is where the real, practical work happens. Take a plan-level definition: your primary customer is a mid-size local business needing quarterly catering, and you have an extended back-and-forth dialog with AI about it. What information do you actually need on file for a customer like that? Name, contact information, account manager, current contract terms, contract rate, whatever applies to your business. The output is known as a schema, the actual blueprint of fields a customer record needs, not just the category it belongs to.
One additional term is worth naming here even though it’s outside what this Bones discussion covers: a knowledge graph is what you get once that schema is actually populated with real records, your actual customers, not just the definition of what a customer is.
I keep something close to this myself. I run a Claude Cowork project alongside an Obsidian vault, already populated and linked together, so I can look at the graph and watch how everything in my business connects: which posts relate to which ideas, which clients touch which projects. It’s a genuinely useful thing to have. Building one is its own project, and I’ll come back to how I actually use mine a little later. This piece stops at the schema; populating it is a job for another day.
Muscles: What to Do When Something Happens
I’ve been sharing three systems-thinking tools with mentoring clients for years: the Iceberg Model, Stock and Flow, and Causal Loop Diagrams, to help them see their own business more clearly and draw out knowledge they’d never actually written down. They were designed as diagnostic tools for the owner’s own understanding. It turns out they’re also exactly the kind of material that makes an AI actually know your business, instead of guessing at it. These three tools fill in the AI knowledge gap, but they are not the only ones; more on that in a moment.
Briefly: the Iceberg Model helps you move past the event that just happened and identify the root causes by examining the underlying patterns, structures, and beliefs driving it. Stock and Flow Diagrams map what’s accumulating and draining in your business, such as cash, capacity, goodwill, and at what rate. Causal Loop Diagrams trace the feedback loops that explain why the same problem keeps coming back even after you think you’ve fixed it.
Working through each of these models is not mandatory. But I want to be honest about the tradeoff rather than pretend there isn’t one: each tool you skip is a piece of your business picture AI won’t have. Running all three doesn’t take long, and it’s how you end up with a more trustworthy foundation. They also tend to feed each other, which you’ll see in the example below.
It’s worth being clear about how the material these three tools produce actually gets used once it exists, because that happens in two separate moments: one you start, and one AI starts on its own.
The first is when you build it: a problem or an opportunity comes up, you sit down and run it through one of these tools with a back-and-forth conversation with AI, and what comes out is a rule, something you now know to do the next time this situation shows up. You’re the one who starts that moment.
The second moment starts with AI instead. Later, when a real, live version of that situation actually occurs, nobody has to prompt it; AI notices on its own and checks it against everything you’ve built. From there, it runs in one of two modes. Recommend mode: it tells you what to do and waits for your call. Chains-off mode: for whatever task you’ve decided it’s ready for, it just does it. That second moment, AI acting on its own rather than you initiating it, is where autonomy actually happens, the part I wrote about in Evolution of AI.
The Discovery Prompt
As already implied, you don’t need to understand these models well enough to fill them in yourself. You can use AI to assist you in their generation. Begin by telling it what your business does, name which model you want, and ask it to interview you, one question at a time, until it understands your business well enough to build it accurately. Something like this:
“My business does: [describe your business]. The problem or opportunity I’m trying to work through right now is: [describe it]. I’d like your help producing a [Stock and Flow diagram / Iceberg Model / Causal Loop Diagram] to work through it. Please ask me a series of questions, one at a time, until you understand my business and this specific situation well enough to produce an accurate representation. When you have enough, don’t just describe it back to me conversationally; draft it as a structured framing document I can save and reuse.”
That last instruction matters more than it might seem. The point isn’t the conversation, and it isn’t even the diagram; if you want one rendered, the how-to posts linked above show you how. The point in this instance is a structured document you keep and make available to AI on an as-needed basis. For an Iceberg Model, that means the events, patterns, structures, and mental models the AI actually identified. For Stock and Flow, every stock it found, what type each one is, its inflows and outflows, and whether it’s currently being adequately replenished. For a Causal Loop Diagram, the variables, the loops, labeled reinforcing or balancing, and the leverage points they suggest.
Once you have these Muscle documents and your Bones documents, the schema from earlier, this is the point where you’d actually set up your AI’s persistent workspace, a Project in Claude or similar, pointed at a real folder on your computer. Give it some structure while you’re at it: a Bones subfolder, a Muscles subfolder, whatever makes sense for how you think about your own business. If you already keep other foundational material there- your business plan, your mission, your operating principles, past decisions, a roadmap- leave it right where it is; Bones and Muscles are additions to that folder, not a replacement for it. The AI can open and reference any file in it whenever it’s relevant, and it stays current as your business changes since it’s just text.
This is also where I’d like to share a bit more about the Obsidian vault I mentioned earlier. Alongside my Claude project, I keep an Obsidian vault where I can add new information from my phone, my iPad, or my computer, wherever I happen to be. I picked Obsidian over something like Notion, which I also use, for this specific situation: it’s just a folder of plain text files on my own computer, which means Claude Cowork can open and read that folder directly, the same way it reads any other project folder, no separate connector needed. Notion is also a viable option, but it stores everything in its own cloud database, so getting AI to read it requires an integration rather than just pointing to a folder.
It’s not complicated, and it doesn’t need to be. When I have a thought while I’m working, a pattern I notice, or a rule I want to remember- it goes in as a quick note. Later, when I actually have time to sit with it, I turn it into the fuller conversation with AI that produces either a new document or amends an existing one.
If you’re a small business owner, you’re rarely at a desk when the useful thought actually shows up. Whatever tool you already use for quick notes will do the same job. The point isn’t Obsidian specifically; it’s having somewhere to catch the thought before it disappears.
Renata, Copper Table Catering
Everything so far has been conceptual. So, here’s what it might look like applied to a hypothetical business.
Meet Renata, a composite business owner built from businesses I’ve mentored over the years. She runs Copper Table Catering, a small operation, herself, a chef, a logistics coordinator, one event captain, and a rotating bench of event-day staff she calls in for larger jobs. She caters weddings and private parties and holds three standing corporate accounts, local companies that have used her for years, some for monthly board lunches, others for quarterly all-hands events.
Her Bones already exist in outline. Her taxonomy is right there in her business plan: corporate clients are one of her customer segments. Her thesaurus needed a quick fix once she noticed it: her own team called that same segment “standing clients” about as often as “corporate clients,” and reconciling the two is exactly what a thesaurus is for. Her ontology is the real payoff: running that plan-level definition through a back-and-forth with AI produced her actual customer schema: client name, primary contact, standing contract terms, typical headcount, and account manager. That’s Bones, built in full for one piece of her business. What she does when something happens to one of those customers is Muscles, and that’s where the real depth of this piece is.
Renata just had her best wedding season ever. She was booked most weekends from May through October. When she ran her year-end numbers, she saw that revenue had barely grown over the previous year and profits had actually dropped. Moreover, she saw that one of her three corporate accounts hadn’t renewed.
Running her situation through the Iceberg Model surfaced four layers. The event layer was flat despite having a record wedding season. The pattern layer, once she looked back three years, showed that corporate revenue had been slowly declining the whole time. Fewer standing events, not as many add-on services, and now a full non-renewal. Examining the structure layer behind it revealed that her calendar and her staff defaulted to whichever lead was loudest, which, in peak season, was almost always a wedding. Corporate accounts ran mostly on autopilot, the same package quoted every year, no proactive check-ins. And underneath all of it sat a belief layer that weddings are where the real money was coming from.
That belief sounded complete, but it wasn’t.
Running a Stock and Flow analysis on the same business surfaced what tubs were actually filling and draining. The simplest one was the most literal: food inventory. Easy to picture. It filled when she ordered and drained when used for events, lost to spoilage, or left uneaten.
However, some of the more load-bearing tubs were less obvious. Event-staff capacity was one of them. The size of Renata’s trained bench was stock-limited. It was also flow-limited since there was a limit to the total hours that her bench could actually work during peak times before overtime and fatigue capped it.
Her corporate contract base was another. Renewable in principle, a satisfied client renewed every year. But it drained without deliberate maintenance. Right now, the outflow was running ahead of the inflow. She hadn’t actively pursued a new corporate client in years.
Her wedding pipeline was the third. Flow-limited and sharply seasonal. Summer and fall were peak. Mid-winter was the slowest, driven by weather, school breaks, and weekend daylight. Referrals and reviews fed it.
That seasonal detail is what exposes the flaw in her belief. Weddings are the real money, but only during wedding season. Corporate accounts are what carry her through the month’s weddings can’t cover. She’d been treating her own safety net like an afterthought.
The Causal Loop Diagram explained why that mistake kept compounding instead of correcting itself. More wedding bookings pulled staff away from corporate accounts. Corporate service quality inevitably slipped. Then an account didn’t renew. Total revenue leaned harder on the volatile wedding pipeline. That pressured her to chase even more weddings to cover the gap. Chasing more weddings pulled even more staff away from corporate accounts.
It was a reinforcing loop. It was especially dangerous here too. It was eroding Renata’s only counter-cyclical revenue stream. That left her most exposed exactly in the months wedding revenue couldn’t cover.
And the loop was slow enough that it wasn’t obvious. The effect of neglecting a corporate account didn’t show up for months. Sometimes a full year or until the renewal conversation simply didn’t happen. That was why Renata’s best wedding season ever arrived the same year as her first real account loss. And why it took a year-end numbers review, not a gut feeling, to notice the pattern at all.
Put the three together, and you can see what each one actually contributed. The Iceberg Model found a belief that sounded complete. Stock and Flow showed it was only half true. Causal Loop Diagrams showed why ignoring the missing half made things worse on its own for over a year.
Together, they produced something more useful than an explanation. They produced a rule: staff corporate events first, fill wedding bookings from whatever bench remains. That rule didn’t come from a hunch. It came from three separate pieces of evidence, and now it’s written down. That’s the part that actually lets AI act, not just discuss. This new rule doesn’t just stay in your head. It becomes one of your Muscle documents, filed into the same directory AI is already drawing on, ready to reference and act on whenever it’s relevant. It sits right alongside the Bones built the same deliberate way earlier. Renata now has both halves in place for this one piece of her business.
The Argument for Doing This Now
AI is maturing. We started with conversational search, which evolved into better prompt engineering, and now it’s evolving again into something far more interesting: businesses that want AI to do real work are modeling their business architecture rather than just writing better prompts. Building that architecture means working on Bones, what things are, and Muscles, what to do, using the tools in this piece to build both. What comes out of that effort feeds directly into the process described in The Real AI Advantage post and ultimately becomes the harness that enables AI to perform tasks more autonomously, without being prone to error.
The Harness Point
Which brings us back to the fear this post opened with. An AI agent that doesn’t know a business’s actual structure and rules acts on its own defaults, not the business’s intent. That’s the actual mechanism behind the hallucination worry, not some unpredictable glitch, just a system doing the generic thing because nobody told it the specific thing.
Here’s what that looks like for Renata once the material above is in place. Three examples, each with its own explicit boundary, none of them full autonomy.
Staffing. Now Renata has a staffing rule documented in her Muscle documents: staff corporate events first, fill wedding bookings from whatever bench remains. AI applies that rule automatically at scheduling time, instead of relying on whoever’s making the call that week to remember it. This is the example that most directly proves the point of this whole post. The harness isn’t a generic safety feature bolted on afterward. It’s the fix for the exact problem her own diagnostic work found.
Corporate renewal protection. Given the Muscle documents, AI now flags any account approaching its renewal window without a recent check-in, and drafts the outreach for Renata’s review rather than sending it on its own. That’s a deliberately lower tier of autonomy than the staffing example: draft, not send, which is the point: the boundary can be tuned to whatever level of trust fits the task.
Ingredient ordering. Once a booking’s headcount is confirmed, AI generates and places the ingredient order against an existing, already-priced recipe, capped at a preset spend threshold, and only for menus already in the system, never a new one Renata hasn’t costed out yet.
All three examples trace back to the same place: the schema and the rules Renata already built. That’s the harness doing its job.
Conclusion
An operating system isn’t a piece of software you install. It’s the knowledge you were always carrying, in the forms of your schema or Bones and the rules or Muscles, finally documented and available for AI to use whenever it needs it.
You don’t need to build all of this in one sitting. Start wherever the gap is more obvious to you right now, the structure side or the judgment side; that’s enough to begin. Add the other as you’re able. Each piece is one more part of the puzzle toward an AI you can actually trust with real, bounded work.
Which one are you missing, the structure or the judgment, and what would it take to write it down?
