Issue 0008: Legibility Is the Prerequisite for AI Initiative Success
What would it actually take for an AI agent to work inside your company?
Not in a vendor demo. Inside the real thing, with live customers, open tickets, and an org chart that still lists two people who left in the spring.
What would the agent need to see? Which systems would it need to read, and which of those systems holds the version of the truth you'd defend in a board meeting? What would it need to be able to answer before you let it answer anything on your behalf? Just as importantly: what should it not have access to, and who inside the company should be able to point it at something, and who should not?
Nearly every AI conversation I hear inside sub-institutional companies skips all of these and goes straight to the tool. Which model, which vendor, which pilot. That ordering feels productive, and it's exactly backwards, because the tool is rarely the thing that fails.
What fails is the company's ability to describe itself.
There's a word for that ability, and it's the subject of this issue: legibility.
Why Legibility Is Hard
A company is legible when consistent, accessible, authoritative information about how it actually runs exists somewhere other than in its people's heads.
The word comes from political science. James C. Scott used it in Seeing Like a State to describe a government's capacity to read and map the society it governs: standardized names, cadastral surveys, censuses, the whole apparatus that turns a territory into something the center can actually see.
The corporate version is smaller but structurally similar.
Legible companies can answer basic questions about themselves the same way twice. What did we sell last quarter, by client? How do we resolve our most common service problem? Who owns the number when two systems disagree? In a legible company those answers live in systems, they agree with each other, and someone is on the hook for the version that counts.
Almost no operating company at this scale clears that bar, and the reason isn't dysfunction. It's that the alternative works.
Most sub-institutional companies run on tribal knowledge, and tribal knowledge is not chaos. It's reliable. The sales rep knows exactly what happens when a deal closes: he pulls the latest contract from SharePoint, runs a find-and-replace on the client name and address, and sends it for signature. The accountant knows exactly how the AP report reaches the CFO: exported from QuickBooks on Friday morning, reformatted the same way she's reformatted it for six years. The dispatcher knows which two customers get called back first no matter what the queue says.
Every one of these is a real process, repeatable, reliable, and living inside people’s heads.
The company is legible. It's just legible one head at a time.
And that's what makes legibility hard. Its absence doesn't announce itself. Nothing breaks. The work gets done, the reports arrive, the deals close. A process that lives in the sales rep's muscle memory costs nothing until the day someone (or something, like an AI agent) other than the sales rep needs to run it. So the record never gets made, because making it was always the task that could wait, and the business was running fine without it.
Tom Blomfield, the YC general partner who co-founded Monzo, delivered what could be described as the “maximalist” version of this idea in a Y Combinator batch talk published in May
Blomfield told a room of founders to make their entire organization legible to AI, and he was concrete about what that means: record everything. Every email to a YC partner now lands in a database. Every office hour gets recorded. "If it is recorded, it happened to the AI," Blomfield said; if it didn't get recorded, it didn't happen at all, as far as the company's intelligence layer is concerned.
YC regenerated its decade-old founder manual in a weekend from two thousand hours of recorded office hours, and Blomfield's stated ambition includes smart glasses and microphones in every room.
Most people would immediately dismiss this type of extremism, and it's easy to see why. It sounds like surveillance, it carries real culture costs, and it's delivered by and for companies that were founded eighteen months ago with three employees and no history.
Here is the mistake I would caution against: if you dismiss the maximalism, be careful not to dismiss the premise underneath it, too.
The basic claim predates this AI hype cycle: no intelligence layer, human or artificial, can operate on top of a company that can't describe itself. Operators who've tried to stand up basic reporting already know this. They have the scars to prove it.
Before anything can guide a decision, there has to be a spine of reporting the company actually trusts, and before that, there has to be visibility into the work itself.
AI agents did not create this prerequisite. They just raised the price of not having met it. Which brings us to the tension that runs through this entire concept, which is company age.
The startup founded last year can build legibility by design. Every customer interaction is in a system from day one, every process is documented because there is no one to remember it, every metric has exactly one source because there's only ever been one. Blomfield's audience can follow his advice almost by default; for them, recording everything is roughly free.
The company you run got built the other way: an acquisition or three, a platform migration that stalled at eighty percent, fifteen years of tribal knowledge, and multiple systems that were each the right answer at the time they were bought.
The founder designs for legibility. The operator has to retrofit it without breaking something critical. Those are different jobs, and nearly all the advice in circulation is written for the start-up, not the operating company with 30 years of history.
A Foundation That Fails Both Ways
Consider a CEO I'll call Ray. Ray runs a PE-backed managed IT services business, about $40M in revenue, three years into the seat, with two senior engineers who've each been there more than a decade. Last year he greenlit a pilot for what the vendor called service intelligence: an agent that reads the historical ticket record, learns how the company resolves problems, and starts triaging, drafting responses, and flagging the tickets that will cause problems. The raw material looks ideal. Six months of history, a little over four thousand tickets, and a cooperative vendor.
The tickets say resolved. How they were resolved was never written down in any meaningful way. Ray's senior engineers close tickets with a one or two-word note because the real resolution lives in their hands and their memory, and for ten years that was fine, because the same engineers were there the next time. The agent can't learn from a record that was never made. No amount of model quality fixes this.
There is nothing to read.
The pilot team asked a simpler question to scope the rollout: revenue per client, so the agent could prioritize by account value. Three systems produced that number. For the largest account, the CRM said $412,000, the billing platform said $377,000, and the operations spreadsheet that actually runs the Monday meeting held a third figure. All three were live. All three were used. And nobody in the company had the standing authority to rule which one was real, because that question had never had to be answered before. Every past disagreement was settled ad hoc, by whoever was in the room.
It's worth being precise about which of these problems is which, because they get conflated constantly.
If the data exists but is scattered, locked in vendor systems, or trapped behind missing integrations, that's a data-access problem, and data-access problems are solvable. A quarter of unglamorous pipeline work solves most of them. Genuine illegibility is different in kind: the authoritative version doesn't exist anywhere. No pipeline can move data that was never captured. No integration can query an answer no one holds. The first problem is an engineering backlog. The second is an organizational challenge, and only the organization can change it.
The same root cause has a second face, and it's the one I've watched keep operators up at night. A company that can't tell an agent what it needs also can't tell an agent what to leave alone. Permission sprawl mirrors data sprawl. In Ray's pilot, the agent had read access to a shared drive because everyone did, and three folders deep in that drive sat a compensation file from the last acquisition. Nobody decided the agent could see it. Nobody knew it could, until someone asked it the wrong question and got an answer.
Access control assumes you know where things live and who should touch them. That's a legibility statement. The maximalists get attacked on privacy grounds, but the illegible company is the one actually running the privacy risk, because it's granting access it can't enumerate to systems it can't fully describe.
You can't fence terrain you've never mapped.
The Case for the Narrow Tool
The reasonable objection is this: skip the foundation, buy the contained tool. An AR follow-up copilot. A quoting assistant. A meeting-notes summarizer.
Each needs only a thin slice of legibility, not the whole company, and each can show real return inside a quarter without a re-platforming project or a data team. This is a strong case. In plenty of situations it's the right first move, and I've recommended it as one. Get a win, build momentum.
It's also what Ray did. He shut the pilot down in month five, and within a quarter he'd signed with a narrower vendor: ticket triage only, hosted in the vendor's cloud, trained on the go-forward ticket stream. The new tool works decently well. It's also now building the resolution record his company never had. The risk is that it’s inside someone else's database, under someone else's schema.
That's the trap. Each narrow tool builds the slice of legibility it needs privately, inside itself.
The quoting assistant develops its own product and pricing master. The AR copilot maintains its own customer list with its own idea of who owes what. The summarizer accumulates the only searchable record of decisions.
Five tools in, the legibility problem hasn't been deferred, it's been multiplied. Five new systems of record, each authoritative about its slice, none reconciled with the others or with the three sources of truth the company already struggled to referee.
Last issue's two tests (Altman Test vs. Karp Test) already says which square this pattern lands in: compounding exposure. It passes the Altman Test and fails the Karp Test.
The point solution doesn't remove the prerequisite. It fragments it, and it postpones the discovery to a moment when the fix is more expensive.
What Legibility Actually Requires
Legibility doesn’t require everything. The maximalists are wrong about scope and right about direction, and the retrofit version is narrower than the discourse suggests. In my experience it comes down to three things.
First, an authoritative source for each question that matters. Not one warehouse to rule them all on day one, just a ruling: for revenue per client, this system is the truth, and the other two are references.
Second, the work itself has to leave a record at the point where it happens. The engineer's resolution gets captured when the ticket closes, not reconstructed in a documentation sprint two months later, because the documentation sprint never happens and would be wrong if it did. If you’ve ever had to log hours in a time card system, you know how quickly the data becomes a rough guesstimate.
Third, a defined reconciliation process: a person or a standing rule that determines how you make secondary systems of record conform to the primary system or record.
None of this is AI work. It's the boring substrate underneath it, the visibility and trusted reporting that every intelligence layer has always required. It's also retrofit work, which is why it's harder than any greenfield playbook admits: slower, political, and invisible in a demo.
Blomfield gets legibility as a byproduct of recording a company that's still small enough to record. The operator has to earn it inside a running company without tanking revenue by 10% or having a key employee quit.
That's the actual job, and it's why the question of whether to deploy an AI agent turns out to be downstream of a much older question: can your company see itself?
Five Questions I Ask
When an operator asks me whether their company is ready for an AI agent, I don't answer with a vendor shortlist. I ask several questions.
First: the most important operating metric in the business. How many systems produce a version of it, and do the versions agree?
Second: when they disagree, do you know which one is real, and would everyone in the Monday meeting agree?
Third: the process the business most depends on. If the person who runs it left on Friday, where would anyone read how it works on Monday?
Fourth: if an agent had to be forbidden from touching the most sensitive data in the company, could anyone name all the places that data lives?
Fifth: who should be able to point an agent at customer information, and is that written down anywhere?
The questions this piece opened with sounded like questions about an agent. They aren’t. They are questions about the company, and the agent is just the first “employee” who'll answer them honestly, at scale.
The company’s map has been in people’s heads for years. The AI agent is just the first navigator who can’t work off that memory.