For thirty years, durable software was the only path to the outcomes organizations wanted — so we built it, maintained it, migrated it, and kept feeding it. Most enterprises now spend 60–80% of their IT budgets just sustaining systems that already exist, leaving twenty cents on the dollar for anything new. The machine developed an appetite — and a whole services ecosystem to keep it fed.
AI is being sold as a way to build software faster. That’s true, and it’s the least interesting part. The real shift: when AI can assemble software on demand to serve a specific outcome and dissolve it when the moment passes, software stops needing to be durable. It becomes temporal — built for the moment, gone when the moment ends. The question that’s haunted every technology budget for thirty years finally has an answer: it stops when the moment passes.
But temporal software needs a venue — a durable, governed foundation of organizational knowledge, ontology, and intelligent infrastructure that every temporary application inherits. Most organizations are deploying AI without one. They’re booking events without a venue. The engineers who matter most in this model aren’t building applications — they’re building the venue. We call them intent engineers.
Most people treat AI like a vending machine — feed it a question, take the answer, walk away. Liz Eversoll built hers to run the company. This is a layer-by-layer tour of a working operating system built on Claude, and why the part no one can copy isn’t the model — it’s the governed core of canon and rules underneath it.
The old investing adage is to make money while you sleep. I want more than that. I want the company to run while I sleep — to our standards, our context, our policies — whether the work in front of it is done by a person, a person with AI, or automated outright.
Most people treat AI like a vending machine: feed it a question, take the answer, walk away. I built mine to run the company.
Over the past month I have assembled what I can only describe as an operating system: a layered stack, built on Claude, that does the work a company generates so I can spend my time on the work only a CEO can do. It has the same shape as the operating system on the device you are reading this on — and that shape is the point. I will walk it layer by layer and show how each one is built.
What an operating system is for
An operating system earns its keep by doing two things at once. It abstracts the machine, so you work at a high level instead of flipping bits. And it governs access, so the things that must be reliable stay reliable no matter what runs on top.
Hold onto that word: governance. Almost everything that separates my system from a clever assistant — or a second brain — comes down to it: a privileged, trusted core that decides what is true and what is allowed, with everything else running above it. Strip the governance out and you do not have an operating system. You have a chatbot with good intentions.
Here is the full stack.
The engine
At the very bottom is the reasoning the whole system runs on — and after a real search, that is Claude. I did not start here. We worked through Copilot, then Perplexity, then ChatGPT, and settled on Claude. It is not that the others can’t do this, it is that Claude is the only one that could operate every layer of this stack — a connected through-line from the engine to the screen. It reaches our systems of record, runs the skills, executes the scheduled processes, and holds to our standards across all of it. The others answer questions. Claude runs the system.
Above the engine is the wiring — the connectors that let the system reach the tools the business already runs on, through MCP. I deliberately think of these by category, not brand: the CRM, the financial system, the HRIS, the email and messaging layer, any system of record. The goal is a true driver layer — that you can swap a tool underneath and everything above keeps calling the same operations while the wiring handles the translation. We are not quite there yet, but that is the direction.
These connectors have one property worth flagging now: some can write back, and some can only read. That single difference decides whether a whole process can finish inside the system or stalls at the screen you were trying to leave. I will come back to it.
The governed core
The next two layers are the ones almost everyone skips — or cannot implement — and they are the entire reason this works. They are also where our proprietary IP lives. Together they are the governed core: the trusted context the system runs on, and the rules that govern what it may do.
Start with canon. Every operating system has a file system — a structured, persistent record of what the machine knows. Ours is our company canon: our single source of truth. It is our trusted business context — definitions, strategy, standards, the design system, operating concepts — written down once and treated as authoritative. It is not a folder of notes, our Sharepoint or a Google Drive connected to the system. Our canon is consulted in a strict order of precedence, so the system always reaches for the most authoritative context available before anything lower down: true canon first, company data, and then other ranked sources.
Canon is the thing you actually run a company on, and it is what lets you automate a process with confidence. When a function needs a fact or a standard, it reads from canon. Other systems may not invent an answer outright, but without a governed source of truth you never know which version you will get — the whole junk drawer is on the table to choose from. Canon takes the junk drawer away.
Then the rules. A real operating system does not let every program do everything; it has a protected mode that gates privileged actions so one misbehaving program cannot corrupt the machine. Ours are governed by SIGN — a specification language we built to encode our policies, standards, data and boundaries in an explicit, machine-checkable form. The rules do not just sit in a document; SIGN’s guidelines let agents reason over our enterprise knowledge in a governed manner — so when the system acts, it is reasoning within the lines we have drawn, not improvising around them. Changing a policy or the ruleset in SIGN is itself governed — proposed, reviewed, and published to the system — so the boundaries stay authoritative instead of drifting.
A concrete one: a process can review a deal and recommend moving it forward, but it cannot advance a deal past Qualified to Buy on its own. That takes me. The intelligence on top can propose; it cannot cross the line the rulebook draws. Recommendation is cheap; authority is governed.
The toolkit
On top of the governed core sit the core functions — the system calls. I started here, with the mundane things I was spending an inordinate amount of time on: finding information, transforming it, storing it, sharing it. Find, transform, store, share, review — the small, reliable operations everything else is built from.
These are skills I built once and now invoke constantly, and the important thing about them is what they govern. One does not just write a document — it writes in our voice. One does not just make a deck — it makes one to our brand standard. One takes a messy contract and standardizes it to our format, clause by clause. These skills carry the voice and the standards into every output, so find happens in a precedented way and transform lands on brand every time, no matter who runs it.
Because each skill reads from canon and obeys the rulebook, the same skill produces the same quality for anyone in the company.
Standing operations
Above the toolkit is where the system stops waiting to be asked.
These are standing operations — processes I built once that now run on a schedule or a trigger, each chaining the toolkit’s functions into real work. The system does research and writes first drafts of articles. It reviews the week’s news and social and drafts the posts. It reviews my pipeline and flags what has stalled. It handles customer and prospect follow-up, prepping me before a meeting and capturing commitments after. Every Monday morning a dashboard assembles itself from live CRM and financial data and lands in my inbox before I am awake.
None of these is a prompt I retype. Each is a standing process — scheduled or triggered — that runs the toolkit’s functions on its own. And this is not only mine: everyone in the company builds their processes on the same toolkit, composing the same governed functions into the work their role needs. One shared foundation, many processes.
The round trip
This is the property I flagged earlier: a process only completes if the system can write back, not just read.
Pulling data out of a tool is easy. The test is whether you can push the result back in — close the loop — without a human re-keying it through a screen. When that round trip works, an entire workflow can run inside the system: read the data, do the work, write the result back to the system of record, automate the whole thing.
This is why I run my task list in Notion and draft in Superhuman. I read, transform, write back, and let the process run end to end. When the round trip is open, a tool becomes a place the system can operate, not just observe. I say more in a companion piece about what this means for the tools that don’t allow it — because it is a bigger deal than it first appears.
The cockpit
The top layer is the one I touch.
This is the screen — where I stop operating the machine and start operating the business. I ask how we are doing, and the system pulls the live picture: pipeline, cash, what is stalled, where risk is concentrating. I do not assemble the report. I read it, and then I do the part that is actually mine — decide, delegate, set direction. And when I need something built, I reach straight past the screen and call any function in the toolkit on demand.
Everything below this layer exists so that this layer is all I have to touch.
Why this works
Step back, and the value is not where most people look. The engine is Claude — extraordinary, and available to anyone. The connectors are standard. The screen I talk to is the easy part, and the standing processes are just the toolkit on a schedule. Strip all of that away and what is left — the part nobody can copy from us — is the governed core: our canon and our rules, written in SIGN and reached over MCP.
Canon, SIGN, and the wiring that lets them act: that is the differentiator. It is also why automation is trustworthy here and brittle elsewhere. A second brain, or an agent loose in a folder, has the engine and the apps and the screen; what it lacks is a governed core, so it drifts. Ours does not, because every layer above reads from trusted context and obeys encoded rules.
And because the core is governed rather than personal, this is not really my operating system. It is the company’s operating system. The same context, the same standards, the same rules are available to anyone — so the business runs the same way no matter who is at the keyboard, and whether the work is done by a person, a person with AI, or fully automated.
Which is the whole ambition. The old adage is to make money while you sleep. I want more than that — I want the company to run while I sleep, to our context and our standards and our policies, and then to hand me, in the morning, only the decisions that were ever really mine.
AI spend is climbing faster than anyone budgeted — and the industry is blaming usage. That’s the wrong target. AI gets expensive when it runs without understanding the work, forcing agents to rediscover context on every run. Liz Eversoll and Joe Shepherd break down why context is the new advantage, and how encoding knowledge in SIGN cut token consumption by half.
By Liz Eversoll, CEO, and Joe Shepherd, CPO — Career Highways
Over the last month, two stories have surfaced in the AI market. On the surface they look unrelated. Read together, they expose the same problem.
The first is cost. Reports from Microsoft, Uber, and other large adopters show AI usage costs climbing faster than anyone budgeted. Uber’s CTO told The Information the company burned through its entire 2026 AI coding budget in four months. The cost per token keeps falling, but total spend rises as usage scales — and Goldman Sachs projects agentic AI will drive a 24-fold increase in token consumption by 2030. Cheaper to use, more expensive to operate.
The second is behavior. Engineers at major technology companies have been encouraged — sometimes incentivized through internal leaderboards — to maximize token consumption as a proxy for AI adoption and productivity. The practice has a name now: tokenmaxxing. Cognizant CEO Ravi Kumar S. recently called it what it is: a vanity metric.
Both stories are being framed as an AI cost problem. They are actually exposing something larger. AI does not get expensive because you use too much of it. It gets expensive when it runs without understanding the work — and without structured knowledge to operate against.
If you own the AI bill — and increasingly that is the CTO — this is the distinction that matters. Cost is exploding and usage is exploding, and your CFO and CEO can see both. What they want to know is whether it can be controlled. It can. But not by capping usage. By fixing what the usage is spent on.
The Wrong Metric
For decades, companies measured labor utilization. Now many are measuring AI utilization. Neither tells you whether value is being created.
Token consumption is simply the latest case of Goodhart’s Law: when a measure becomes a target, it stops being a good measure. More prompts, more agents, and more AI calls do not necessarily produce better decisions, better products, or better outcomes.
The real problem is not that organizations use too much AI. It is that most cannot say what work should be done by people, what should be augmented by AI, and what should be automated outright. Without that understanding, you optimize for activity — and activity, billed by the token, is expensive.
Context Is the New Advantage
Here is what the cost narrative misses. AI is expanding access to problem-solving across the entire workforce. People no longer need years of specialized training to analyze data, build a workflow, generate a solution, or ship working software. The barrier to participation has dropped.
As access to answers goes up, something else becomes scarce and valuable: context. Understanding the business problem. Understanding how the work actually gets done. Knowing what a good outcome looks like — and how to tell whether the AI produced one. A model can generate an answer. It cannot reliably tell you whether you are solving the right problem.
This is why a company like Cognizant is expanding hiring beyond traditional technical backgrounds. Value is shifting toward people who understand the business, the customer, and the workflow — not only the technology. AI widens who can participate; context determines who creates value. The question is no longer who can perform the work. It is who can frame the right problem, validate the solution, and put it into production. Those are skills.
From Skills to Execution
Understanding the work, and the skills behind it, is the first step. Most organizations still lack a systematic way to define that work, map the skills it requires, and apply that consistently across the enterprise. That is the gap Career Highways closes — identifying the work that actually exists, defining the skills required to perform it, and connecting those skills to roles, workflows, and outcomes. The result is a system of record for capability: what work needs to be done, and who can do it.
But a second constraint shows up the moment you try to operationalize it. Even when the work and the skills are defined, AI still struggles to use that knowledge efficiently.
Why AI Keeps Rediscovering What You Already Know
Most enterprise knowledge already exists — policies, frameworks, data models, domain definitions. It is just not structured in a way AI can reliably apply. Documents describe intent but cannot enforce it. Data may be structured, but the relationships and constraints that govern how it behaves are not. Prompts try to fill the gap, and introduce inconsistency every time.
So agents retrieve information, but they do not apply it systematically. They infer, approximate, and reinterpret the same logic on every run. That is what drives both inconsistency and cost. AI is expensive precisely because it has to rediscover context every time it runs.
Introducing SIGN
At Career Highways, we built SIGN (Sigil Intelligence Graph Notation) to solve exactly this. SIGN is an open standard for expressing enterprise knowledge in a form agents can read, reason over, and act on — consistently, and with governance.
If JSON serializes data, SIGN makes knowledge executable. More simply: SIGN is the Rosetta Stone of agentic knowledge — it unlocks the institutional knowledge an organization already holds, in a form every agent can read, apply, and be held accountable to.
It separates what is defined from how it is executed, so knowledge can be reused and enforced consistently across systems. Instead of describing rules in prose or burying them in code, SIGN encodes them directly into the knowledge layer — defining what is true, what must be enforced, and how decisions are made.
“AI systems today spend most of their time reconstructing context that already exists in the enterprise. SIGN flips that model. It makes the knowledge itself executable, so agents don’t have to guess — they operate against defined logic.” — Joe Shepherd, Chief Product Officer, Career Highways, and inventor of SIGN.
Why This Changes the Cost Equation
The AI cost problem is not only about scale. It is about how inefficiently knowledge is represented and applied. Most enterprise formats force AI to do unnecessary work — JSON adds structure without meaning, documents demand heavy context to interpret, prompts recreate the same logic over and over. The result is longer prompts, repeated reasoning, inconsistent outputs, and higher token consumption.
SIGN removes that inefficiency by encoding meaning directly. Rules, constraints, and inference logic are defined once and applied consistently — so AI executes against known logic instead of inferring what it should already know.
From Probabilistic Guessing to Deterministic Execution
In most systems today, reasoning is left to the model. Because large language models are probabilistic, rules get applied inconsistently, constraints get missed, and outputs vary from run to run.
SIGN moves that responsibility out of the model and into the knowledge layer. It defines what must happen, what cannot happen, and how conclusions are derived — so agents operate with governed logic instead of inference. The result is a shift from probabilistic output to deterministic decisioning: ask the same question, get the same answer.
The Impact: Fewer Tokens, Better Outcomes
When knowledge is structured and executable, AI no longer has to reconstruct context or reinterpret logic. Prompts get shorter. Workflows become reusable. Outputs become consistent.
We have measured this in our own platform. Encoding our knowledge in SIGN cut our token consumption by roughly half for the same work. Same knowledge. Half the tokens. Deterministic results.
The Bottom Line
The debate about AI costs is real — but most of it is aimed at the wrong problem. AI does not get expensive because it is used too much. It gets expensive when it is used without understanding the work, and without structured knowledge to operate against.
Career Highways defines the work and the skills. SIGN makes that knowledge executable — so AI can operate with precision instead of guesswork.
For the CTO, the first move is small and measurable: take one high-cost agentic workflow, encode the knowledge that governs it in SIGN, and watch the token count. Stop tokenmaxxing. Start work-maxxing. That is how AI stops being a cost and becomes a capability.
Sources
“The Pulse: ‘Tokenmaxxing’ as a weird new trend” — The Pragmatic Engineer
“Microsoft reports are exposing AI’s real cost problem: Using the tech is more expensive than paying human employees” — Fortune
“Cognizant CEO is swimming against the tide on AI: he’s hiring over 20,000 graduates this year and says AI tokenmaxxing is a ‘vanity metric’” — Fortune
“AI Agents Forecast to Boost Tech Cash Flow as Usage Soars” (24-fold token growth by 2030) — Goldman Sachs Research
Everyone’s building a “second brain” — capture enough notes, links, and prompts, and clarity will follow. It rarely does. Most systems become a graveyard of notes that never turn into finished work.
This piece argues the real answer isn’t a bigger pile of memory — it’s an operating system: a governed, layered stack with a protected core that decides what’s true and what’s allowed. A brain can’t enforce a rule on itself. An OS can.
Read the full article on why a governed operating system beats the second brain everyone else is building — and the read/write gap that should make a few software companies nervous.
The promise is seductive: capture enough — notes, links, highlights, clever prompts — and clarity will follow. It rarely does. The notes pile up. The folders multiply. Six months in, you are scrolling a junk drawer you never open. One honest practitioner admitted to thousands of notes in his system and almost nothing ever turned into finished work. That is not a system. It is a graveyard with good intentions.
I went a different way. I built an operating system to run our company — a governed, layered stack I describe in full in a companion piece – CEO Operating System. This article is about why that beats the thing everyone else is building.
A machine brain is not your brain
Start with the metaphor itself, because it hides the problem.
A second brain sounds like an extension of your mind. It isn’t. It is a machine’s brain, and a machine knows nothing about how you want things done until you tell it — every preference, every standard, every rule, every time. The moment you take that seriously, you discover that telling a machine everything you want, reliably, on every run, has a name. It is structure. It is governance. It is a framework.
Which means the work of making a borrowed brain trustworthy is the work of building an operating system. The brain is not an alternative to the OS. The brain is what you get when you skip the OS and hope.
What the brain is missing
Put a real framework next to a second brain and the gaps are structural, not cosmetic.
No kernel. A second brain is all user space — notes, links, an agent rummaging through them. There is no privileged, governed core that decides what is true and what is allowed. A real system has one: enterprise knowledge and a governance layer sitting underneath everything. A brain cannot enforce a rule on itself. An operating system can.
No protected mode. The newer, AI-native versions hand an agent the keys to the whole vault and hope it behaves. There is no boundary it cannot cross. A real operating system gates authority — it can recommend advancing a deal but cannot cross the line on its own. That is not a feature bolted on. It is a property of being an OS.
It confuses memory with thinking. The whole genre treats remembering as the goal — capture more, store better. Even the clever setups bolt reasoning on top of one undifferentiated pile. An operating system separates the record from the reasoning: the reliable things stay reliable because they do not live in the same place as the improvising.
It rots. A drawer fills with junk because nothing governs what goes in or whether it is still true. That is the graveyard, and it is the metaphor failing in public. A governed record with a rulebook does not accumulate noise the same way. Structure is what stops the rot, and a brain has none.
Where the brain metaphor is actually fine
I am not going to pretend the idea is worthless, because it isn’t.
For an individual capturing ideas, the second brain works. The founding insight — your mind is for having ideas, not holding them — is true, and offloading memory is real value. The metaphor isn’t wrong. It is just small. It tops out at personal note-taking. It was never trying to run an enterprise, so beating it on governance is partly beating it at a game it never entered.
And the AI-native crowd — the ones putting an agent inside the notes, giving it an operating manual, letting it act and write back — are closer than the rest. That pattern is a genuine step up. Where they stop is the bottom of the stack: loose files in a folder instead of a governed record. They have built the top two layers and skipped the governed core — the canon and the rulebook — which is exactly the part that makes the difference.
The honest cost
An operating system is heavier than a brain. A second brain is something one person stands up in an afternoon with a folder and a markdown file. A real one depends on enterprise knowledge, a specification language, governed connectors, and a rulebook. That is infrastructure, not a weekend project.
I will not pretend otherwise — because the weight is the point. A drawer is light because it does nothing. The moment you want a system that runs the work and that you can trust unattended, you need a governed core, and that costs something to build. The brain stays light by staying passive. I traded lightness for a machine that actually operates.
The gap nobody is talking about
There is one more difference, and it is the one that should make a few software companies nervous.
A system of record only completes a process if you can read and write it. Most connectors are read-only. You can pull data out, but you cannot write back — to Microsoft To Do, to Teams, to plenty of others — which means you cannot round-trip a full workflow through the agent. The process dead-ends at the very screen you were trying to leave behind.
That sounds like an integration nit. It is actually a market threat. The switching cost of a system of record was always that everyone knows the screens. But once an agent can write directly into the record, the screens leave the daily path — and the moat goes with them. Suddenly the question is not which interface my team knows, but which system lets me push data in, read it back, and automate the loop.
That is why I moved my task list to a tool that round-trips and draft my mail in one that writes to drafts, while the read-only options in my current system sat untouched. I did not switch because the screens were better. I switched because one let the system operate and the other only let it look. Every system of record that stays read-only is teaching its customers the same lesson — and inviting the same replacement.
What to build instead
A second brain helps you remember. An operating system lets you run the company and step away from the machine — because the things that must be reliable are governed, and only the things that benefit from judgment are left to you.
If you are pouring hours into a second brain and wondering why you still feel buried, that is the reason. You have been building memory. Build a machine that runs instead. I laid out the full framework in the companion piece; and the part that makes it work isn’t the engine or the apps everyone has. It’s the governed core almost no one builds.
