The Legibility Problem
A plumber in Austin gets a call at 2 PM on a Tuesday. He's under a house, hands full of copper pipe, phone buzzing in his pocket. By the time he crawls out, the caller has moved on, already dialling the next name on the list. That call was worth $4,800. He'll never know.
This is not a technology problem. The plumber has a phone. He has a CRM he half-uses. He might even have an AI tool he signed up for during a free trial and never configured. The problem is something more fundamental, and it sits upstream of every tool, every workflow, every automation pitch that's ever been aimed at a small business owner.
The problem is legibility.
The small business, as an organism, is nearly opaque to software. Not because it's primitive, but because it's dense. A five-person roofing company carries an extraordinary amount of institutional knowledge in an extraordinarily compressed form. How they price emergency work. When they require a deposit. Which zip codes they'll drive to. What "urgent" means versus what "emergency" means. The fact that Mike handles commercial jobs and Terrance handles residential, except on Thursdays when Terrance is on-site at the Riverside project. The fact that repeat customers get a callback within the hour but new leads get triaged by scope first.
All of this lives in someone's head. Maybe some of it lives in a Google Doc that was last updated in 2022. Maybe some of it is written on a whiteboard in the shop. The operating logic of the business, the how, exists, but it exists the way dark matter exists: you can observe its effects without ever being able to point at it directly.
This is what I mean by legibility. Not simplicity. Not documentation for documentation's sake. Legibility is the degree to which a business's operating logic can be seen, reasoned about, and acted upon by humans and machines alike. And right now, for the vast majority of small businesses, that degree is close to zero. The U.S. Census Bureau found that just 6.3% of small businesses are using AI in production. Eighty-two percent of firms with fewer than five employees say AI is simply "not applicable to their business." They're not wrong. It isn't, yet. Not because the technology is lacking, but because their operations aren't legible enough for AI to act on.
Which is exactly why AI, despite being the most powerful tool these businesses have ever been offered, keeps failing them.
The pitch is always the same: AI will make you faster. AI will make you smarter. AI will answer your calls, qualify your leads, follow up with your customers, draft your invoices, remember what you forget. And every word of that pitch is technically true. Large language models can do all of those things. Dario Amodei describes a future that is possibly only a few years away in which AI surpasses human performance at essentially every cognitive task. The capability is real and accelerating. But as Sarah Guo has observed, capability does not equal adoption. The moat in workflow AI is "bottling institutional context and making it useful in the moment of work."
That word, context, is doing all the heavy lifting. Without it, capability is just expensive pattern-matching. Give a model a phone call transcript and no business context and watch what happens. It will extract the caller's name. It might even detect urgency in their tone. But it won't know that this business charges a weekend surcharge for emergency work, or that it doesn't serve addresses north of Highway 183, or that the right next step for this type of inquiry is to ask about the water shutoff valve before scheduling a visit. The model is fluent and confident and completely ungrounded, which is the most dangerous kind of wrong.
The industry's response to this gap has been to hand the business owner a configuration screen. Build your agent. Write your prompts. Define your flows. Set your triggers. The assumption is that if you give people enough knobs, they'll tune the machine to fit their business.
But listen to what business owners actually say they want: not a better interface, not more dashboards, not another place to click around. They want to pull out their phone and say, "Send John Smith an estimate for 3 acres at tier 2 brush density," and have it just happen. Or: "Follow up on all pending estimates for the next 30 minutes. Give me a quick summary of each job and connect the call." That's not a feature request. It's a description of what becomes possible when a business is legible enough for an AI to act on it.
The data says otherwise on where we are today. Ninety-eight percent of users who start configuring a Sona agent abandon the process before finishing. Not because they're incapable. Because they are standing in a customer's kitchen fixing a garbage disposal, and the fifteen minutes it would take to configure an AI workflow are fifteen minutes they literally do not have. The configuration screen isn't a solution to the legibility problem. It's the legibility problem wearing a different hat.
So here is the thesis, stated plainly: Before AI can make a business faster and smarter, the business has to become legible. And the act of becoming legible, of codifying the how, is itself the product.
Not a prerequisite. Not an onboarding step. The product.
Think of it this way. Every business, whether it knows it or not, operates on an ontology: a structured map of how work moves from beginning to end. A lead comes in. It gets triaged. It becomes a quote. The quote becomes a job. The job gets scheduled, prepped, delivered, invoiced, reviewed. Each of those stages has rules, even if those rules have never been written down. Each stage has fields that matter: the customer's address, the scope of work, the urgency, the budget. Each field has meaning that is specific to this business, not to businesses in general.
"Emergency" at a plumbing company means active water damage, same-day dispatch, 2x the normal rate. "Emergency" at a law firm means a court date within forty-eight hours. The word is the same. The operational reality is completely different. And any system that treats them as interchangeable will fail both businesses in exactly the way that matters most.
The ontology, then, is not a database schema. It's not a set of tables with foreign keys. Think of it as a directed graph whose nodes are the stages of a business's operations and whose edges encode the conditions under which work moves from one stage to the next. But the critical layer, the one that makes this more than a flowchart, is that every node, every edge, every field on every record carries a natural-language description of what it means in this particular business. Not just "Urgency: dropdown, three options." Something more like this:
stage: "Triage"
description: "First contact with a new lead. Determine
service type, urgency, and whether we serve their area.
Repeat customers skip this stage entirely."
fields:
- name: "Urgency"
type: enum [routine, urgent, emergency]
description: "Emergency means active leak requiring
same-day service. We charge a weekend surcharge
of 30%. Always ask if they've shut off the main
water valve."
- name: "Service Area"
type: zip_code
description: "We serve 78701–78759. Anything outside
that range gets referred to Dale's Plumbing
(512-555-0147). Be polite about it."
exit_conditions:
- to: "Quote"
when: "Urgency confirmed, service area verified,
scope of work described in at least one sentence."
Every field has a type the system can evaluate deterministically and a description the model can reason over in natural language. The exit_conditions encode the business logic that governs when a lead advances, not as code, but as prose that both a new hire and an LLM can interpret. This is not a workflow builder. It's a knowledge representation, one that happens to be executable. And this executability is what matters. As one Ramp data lead put it: the SaaS vendors that survive will be those who make their primitives and data models easily accessible via agents. Products that force users to click through UI are vulnerable. Products that expose their operating logic to machines are durable.
Those descriptions are the load-bearing element of the entire architecture, and they serve two audiences simultaneously. For a human, whether a new hire, a partner covering calls on vacation, or the owner themselves, they're documentation. For the AI, they're something more precise: they become fragments of the system prompt, assembled dynamically at inference time based on the current context. When a call comes in and the system needs to decide how to handle it, it doesn't query a static prompt template. It traverses the ontology, gathers the relevant stage definitions, field descriptions, and business rules, and composes them into the context window that the model reasons over. The ontology is the prompt, generated fresh for every interaction, specific to the exact situation at hand.
This is the unlock. Same artifact, two audiences: human documentation and machine instruction set, written once, consumed both ways.
Now place a person inside this ontology. A customer calls. They are, in the language of the system, a contact, but not the flat, CRM-record version of a contact. They are a point of living context moving through the business's operational map.
What we know about this person exists in two distinct registers. The structured register is clean and queryable: their name, their address, the service they've requested, the pipeline stage they're sitting in, the dollar value of their open quote, the date of their last interaction. This data lives in typed fields, and the AI can reason over it deterministically. It can evaluate whether a stated budget exceeds a minimum threshold or whether an address falls within the service area without any probabilistic uncertainty at all.
But the unstructured register is where the relationship actually lives. It's the note from a previous conversation where the customer mentioned they have a newborn and can't handle loud work before 10 AM. It's the email they sent last week with a frustrated tone that the AI can detect but that no dropdown field would capture. It's the fact that they were referred by a longtime client, which changes the calculus of how much patience and attention this lead deserves. These context notes, these fragments of relationship, are what make a business's interactions feel human rather than transactional.
The system's job at the moment of contact is context assembly: pulling together both registers into a single, coherent picture that the model can reason over. The structured fields get serialized directly. The unstructured notes get retrieved, ranked by relevance, and injected alongside the ontology's stage definitions and rules. The result is a context window that contains everything the AI needs to behave like someone who actually works at this business, assembled on the fly, specific to this contact and this moment in their relationship with the business.
The AI's job, then, is to navigate. Picture the contact as a pointer, a cursor moving across the ontology, from node to node. At each node, the system evaluates: What stage is this relationship in? What does the ontology say about this stage's exit conditions? What structured and unstructured context do we have about this specific person? What action is most likely to move things forward, and how confident are we?
And then one of two things happens. If the answer is clear and the stakes are low, the AI acts. It sends the confirmation text. It books the appointment. It follows up on the unpaid invoice. If the answer is ambiguous, or the stakes are high, or the confidence falls below a threshold the business has set, it proposes the action and waits for a human to approve it.
This is not a binary switch. It's a dial. Call it the autonomy slider. At one end, the AI is an observer: watching conversations, populating fields, surfacing patterns, but never speaking on the business's behalf. At the other end, the AI handles complete interactions across every channel, unsupervised. Most businesses will live somewhere in the middle, and they'll move along the dial at their own pace, as trust accumulates through thousands of small, successful decisions.
The psychological architecture here matters as much as the technical architecture. Trust is not a feature you ship. It's a residue of repeated, observable competence. A business owner who sees the AI correctly extract a customer's budget from a call transcript, fifty times in a row, starts to believe the AI understands their business. When they see it draft a follow-up message that sounds like something they'd actually write, they stop editing the drafts. And one morning they realize they haven't touched a draft in three weeks, and the thought arrives naturally: Why am I still approving these?
That's not automation. That's earned authority.
But earned authority requires a receipt. This is the piece that most AI systems skip, and it's the piece that makes all the others trustworthy.
Every action the AI takes, every message sent, every appointment booked, every lead triaged, should be traceable back through the ontology. Not in the vague, "the AI decided this" sense. In the specific, auditable sense:
receipt:
contact: "Margaret Chen"
pipeline: "Sales"
stage: "Qualify"
inferences:
- source: voicemail_transcript
extracted: { budget: "$8,000", confidence: 0.92 }
- source: contact_record
extracted: { zip: "78745" }
evaluations:
- rule: "budget >= $5,000 minimum"
result: true
- rule: "zip in service_area [78701–78759]"
result: true
- rule: "stage exit requires: budget_confirmed
AND service_area_verified"
result: true
action_taken: "schedule_site_visit"
autonomy_level: "propose" → sent to owner for approval
That's a receipt. It cites its sources. It shows its path through the map. And it makes visible the seam between what the AI inferred and what it verified.
The technical insight here is that the ontology provides deterministic checkpoints within probabilistic reasoning. The model used judgment to extract a budget figure from a rambling voicemail (confidence: 0.92, not 1.0), and that step is inherently probabilistic. But the decision about whether $8,000 exceeds the $5,000 minimum, or whether ZIP code 78745 is in the service area, or whether the Qualify stage requires both conditions to be met before advancing, those are lookups against the ontology. They're Boolean. The receipt shows both kinds of reasoning side by side, and this separation is what makes the whole thing auditable rather than merely explainable.
When something goes wrong, when the AI does the wrong thing or the right thing at the wrong time, the receipt tells you exactly where the breakdown happened. Maybe the ontology's definition of "service area" is outdated. Maybe the stage exit conditions don't account for a new edge case. Maybe the model misinterpreted the caller's budget from a noisy transcript, and the receipt makes that inference visible so the human can correct it. The problem is always locatable, and the fix is always the same: make the ontology more accurate, or give the model better signal.
This creates something remarkable: a system that debugs itself through use. Every correction a human makes, whether adjusting a field description, updating a stage definition, or adding a rule, tightens the map. The AI gets more accurate because the business got more legible. The business got more legible because the AI revealed where the gaps were. It's a flywheel, but not the growth-hacker kind. The kind where the machine and the humans are teaching each other, continuously, through the work itself.
Now zoom out. If the ontology is the map and the AI is the navigator, then the navigator doesn't care where it's standing when you call on it. It can be triggered from a phone call at 2 AM, from a text message sent while the owner is at their kid's soccer game, from a web form submitted by a stranger who found the business on Google, from a webhook fired by a job management platform when a work order is completed.
The architecture that makes this possible is worth understanding. Every inbound event, regardless of channel, enters the same pipeline: identify the contact, resolve their current position in the ontology, assemble the relevant context (structured fields, unstructured notes, ontology definitions, business rules, conversation history), evaluate the autonomy level for this type of interaction, and then reason over the assembled context to determine the next action. The input modality, whether it's a voice transcript from Twilio, a parsed SMS, an email body, or a structured webhook payload, gets normalized into the same intermediate representation before the model ever sees it. This is what makes "same brain, every surface" an architectural statement rather than a marketing one. It's the same principle that led OpenAI to build Frontier around what they call a "semantic layer for the enterprise," a shared context that all agents reference. The insight is converging from multiple directions: agents don't need more intelligence. They need more legibility about the work they're supposed to do. The plumber under the house doesn't need to configure a separate AI for calls versus texts versus emails. The ontology powers all of them, because the ontology isn't about channels. It's about how the business works.
But look closely at Frontier's architecture diagram. At the bottom, in a dashed-line box, separate from everything above it: "Your systems of record." The business context layer, the agent execution layer, the evaluation loops, the interfaces, all of it sits on top of a system of record that OpenAI treats as someone else's problem. For enterprises with an existing Salesforce instance, that's the right design. But for businesses building from scratch, the lesson is the opposite. If you design your system of record in a vacuum and bolt the intelligence layers on later, three things happen: you limit what the agents can do, because the underlying data model wasn't built to be reasoned over. You move slower, because every new capability requires retrofitting a foundation that wasn't designed for it. And you miss the boat entirely, because the businesses that built legibility into their system of record from the start are already operating at a speed you can't catch.
The system of record is the ontology. Or it should be.
This is the vision: an army of quiet, competent digital workers. Not general-purpose chatbots, but agents that carry a detailed understanding of this specific business and this specific customer into every interaction. They answer the phone at 2 PM on Tuesday when the plumber can't. They follow up on the quote that went cold last week. They remind the customer about their annual gutter cleaning. They do it all in the business's voice, following the business's rules, within the boundaries the business has set. And they show their work.
There's a temptation, when you describe a system like this, to make it sound inevitable. Like the technology will simply arrive and arrange itself into the correct shape. It won't. Amodei calls this period the "adolescence of technology," and the metaphor is apt: the capabilities are growing faster than the structures needed to use them wisely. The hard part is not the AI. The hard part is the legibility layer underneath it: the patient, specific, unglamorous work of encoding how a business actually runs.
That work is not configuration. It's not prompt engineering. It's something closer to reflection. When a business owner adds a contact field called "Urgency" and writes, "Emergency means active leak requiring same-day service", they're not configuring software. They're articulating, maybe for the first time, a rule that has lived in their head for fifteen years. They're making the implicit explicit. And the extraordinary thing is that this act of articulation, this small moment of legibility, benefits them whether or not they ever use AI at all. It helps the next employee they hire. It helps their partner cover calls on vacation. It helps them see their own business clearly.
The AI is downstream of that clarity. It's the reward for doing the work of knowing yourself.
Small businesses don't need another tool. They need their operations to become visible to them, and to the machines that are, finally, capable of helping. The businesses that become legible first will be the ones that capture the disproportionate value of this moment. Not because they adopted AI fastest, but because they understood what AI actually needs to work: a map of the territory, drawn by the people who know it best.
The plumber is still under the house. The phone is still ringing. The difference is that now, something answers. Something that knows what "emergency" means, knows which zip codes to serve, knows to ask about the water valve. Not because it was programmed with a script, but because the business made itself legible, and the AI learned to read.