Traditional shift left moves work earlier in the process. Shift left hard goes further by embedding the governed standard directly into the tools producing the work. This article explores how AI can reduce handoffs, eliminate routine translation, and prevent errors before they happen—while allowing specialists to focus their expertise on standards, exceptions, and judgment rather than repetitive review.
Why faster, cheaper, and better don’t have to be a trade-off
Shift left is a term from software development. It means moving a step earlier in a process, doing something sooner instead of later, because catching a problem early is dramatically cheaper than catching it late. Barry Boehm and Victor Basili quantified this principle: a defect caught during requirements and design is often up to 100 times cheaper to fix than the same defect caught after release, on a large system; on a smaller, less critical one, the gap is closer to five times. Larry Smith named this shift-left discipline in 2001, moving testing and security earlier in the development cycle for exactly this reason. The logic has held for over twenty years because it’s simply true.
That’s the narrow definition. The broader definition means putting the work, and the tools to do the work, closer to, or directly into the hands of, the person who has the idea and runs the business. Not shifted to a specialist who translates it for them. Shifted to them.
Done properly, this has a second effect that is harder to anticipate. It doesn’t just move the work. It simplifies it: fewer tools, fewer stages, fewer places for the truth to get lost between one stage and the next. Shift left and simplify aren’t two separate benefits. They’re the same change, seen from two angles. You don’t get one without the other.
Most work has moved the opposite direction for as long as anyone can remember. Someone who runs the business, a claims manager, a plant supervisor, a sales ops lead, knows exactly how the work should go. They couldn’t say it in a language a designer, an engineer, or a compliance reviewer could act on, so the idea moved right instead: to a business analyst, who wrote it up for a product manager, who handed it to a designer, who handed it to an engineer, who handed it to QA. Every handoff was a translation. Every translation cost time and lost something the original person meant.
That chain was never incompetence. It existed because turning an idea into something built required skills the person with the idea usually didn’t have themselves: how to structure a requirement, how to design an interface that meets an accessibility standard, how to write code that passes a security review. Shifting left was never really about speed. It was about whether the person with the idea could do the downstream work themselves. Mostly, they couldn’t.
AI changes that calculus directly. It isn’t that the specialist stops mattering, and it isn’t that the handoff disappears. The handoff still happens. What changes is what gets handed off, and when. The expert who used to translate every case by hand, one request at a time, now sets the standard once: the rule, the pattern, the regulation, the approved component. That standard gets built into what the person with the idea is drawing from, so the ordinary case doesn’t need a human translator anymore. It still gets checked. It just gets checked against a standard the expert already set, instead of interpreted fresh by the expert every single time.
That’s what shift left actually means. Not “the business analyst gets a productivity tool.” Not “the business analyst is no longer needed.” It’s that the business owner needs less of the business analyst’s time on the routine case, and more of it on the standard itself, and on the case unusual enough to actually need their judgment. Less mundane translation, done over and over. More of the judgment only they can make, done once and reused.
Most of what’s sold as AI shifting left doesn’t do this. It shifts the chain by one link, not by breaking the chain apart. The developer still gets the ticket and still writes the code, just with a copilot suggesting the next line. That’s real, and it isn’t nothing. But it’s the same chain, moved slightly left, with the same people doing the same mundane work, just faster.
Ordinary shift left moves work to someone who can do it faster. Shift left hard moves the standard itself into the tool that person is using, so what they produce is already correct against that standard before anyone reviews it. Not a faster path to the same check. A check that’s already been passed by the time there’s anything to look at.
That only works if the standard is actually built into what’s generating the output, not written down somewhere and left for a person to remember and apply. We call the governed version of that standard Canon, In Design this is: the design patterns, the usability rules, the accessibility requirements, the regulatory constraints, the approved components, and the business rules behind all of it, compiled into a form the system draws from directly. The system doesn’t produce an off-brand color or a non-compliant component because neither one exists in what it’s drawing from. It isn’t skipping a check. There’s nothing to check, because the violation was never an option to begin with.
Here’s what that changes for the person who used to catch it. The risk hasn’t moved. It’s still sitting at the same step, with the same person who always caught it. What’s different is how much of it still needs their attention: next to none for the routine case, because it’s already correct. What’s left for them to review is the real exception, and that’s the part that gets faster, not skipped.
Shift left hard has a requirement that’s easy to state and hard to actually do: all of it has to live in Canon. Not most of it. Not the parts that were easy to write down. If the standard is still split across application code, a policy document, a prompt someone wrote into an AI tool, a skill definition, a RAG search over a SharePoint drive, and the memory of whoever’s been doing the job the longest, the system is still guessing. It’s just guessing from more places at once, faster. Canon isn’t one more place knowledge lives. It’s the source all the others call, instead of building their own copy of the rule in. Code doesn’t encode the eligibility logic anymore; it calls Canon for it. A prompt or a skill doesn’t restate the standard from memory; it calls Canon for it too.
And it has to be the same Canon, for everyone drawing from it, at the same time. A human and an agent working from two different versions of the standard, one from a wiki someone updated last year and one from whatever the model happened to learn, will produce two different answers to the same question. That’s not a governance gap to patch later. That’s the exact same fragmentation this piece has been describing, just moved into the AI layer instead of out of it.
Here’s what that actually looks like day to day. When I’m working on a design in Claude and it places something a certain way, sizes it a certain way, picks one pattern over another, I can ask why. Not asking it to guess at its own reasoning. Asking which rule it followed, and where that rule lives. It should be able to point to the actual standard in Canon behind that decision. Then I get to make the real call, not “was the AI right,” but “was the rule right.” Sometimes the rule stands and so does the design. Sometimes it doesn’t, and now I know exactly which rule to go fix, for every output after this one, not just this one.
That’s the actual difference between fast and governed. Fast gives you an answer. Governed gives you an answer and the reason behind it, in a form you can actually check and correct.
This is the simplify half of the claim, and it isn’t only about who does the work. It’s about which tools the work requires in the first place, and most of the tools built for the old chain exist to compensate for a single problem: no stage in that chain ever had the whole truth.
The old toolchain had a tool for almost every stage: a lo-fi tool for early ideas, a hi-fi design tool for the visual layer, a separate prototyping tool to make it clickable, then a design-to-code handoff into whatever engineering used. Each one holds part of the deliverable. A tool like Figma keeps the paint chip: the exact color, the font, the pixel spacing of a component. It doesn’t keep the rule for where that paint chip is allowed to go: which component is approved for which context, what an accessibility standard requires of a given interaction, which regulation constrains a specific field or disclosure. That rule lived somewhere else entirely: a style guide nobody opened, a senior designer’s memory, a compliance sign-off applied by hand, differently, every time.
Canon is where both halves live together: the component and the rule for using it, in the same place. Once a system generates output directly from that, the intermediate tools stop being necessary. Not because they got faster. Because the reason they existed, carrying half a truth from one stage to the next so the next stage could find and apply the other half, is gone. A lo-fi tool, a hi-fi tool, a separate prototyping tool, a separate accessibility audit: four different attempts to reassemble a whole truth that was never in one place to begin with. Put the whole truth in one place and you don’t need four tools to approximate it. You need one system that already has it.
Here’s where the distinction between shift left and shift left hard actually shows up. Ordinary shift left, even done well, still means the idea enters a queue. A designer has to be available. A developer has to pick up the ticket. Even a well-run team with short cycles is still waiting on someone’s calendar, and that wait, not the work itself, is often the biggest cost in the whole chain. Weeks pass before anyone finds out whether the idea was even worth pursuing.
I can take an idea, something as unformed as a sentence, and build a full, high-fidelity prototype of it in a few minutes: on-brand, accessible, built from approved components, checked against the usability and regulatory standards that apply to it, backed by real, working code. Not after a design slot opens up. Not after a sprint gets planned. In minutes, while the idea is still in the room. That’s long enough to settle the question that actually matters before anything else gets spent: whether it’s worth pursuing at all. Feasibility, and the go or no-go decision behind it, moves from a multi-week wait to something you can decide before the meeting ends.
If the answer is go, the acceleration doesn’t stop at the prototype. Design review against something that’s already standards-compliant is fast, because it’s confirming work that was built correctly the first time, not starting from a blank canvas. Development from there is highly automated. QA is highly automated too, checking against the same standard the prototype was already built to, instead of discovering that standard for the first time. A feature that would have taken three months to deliver end to end fits inside a two-week sprint.
That’s the real distinction. Ordinary shift left moves a check earlier in a queue that still exists. Shift left hard removes the queue for the part of the work that no longer needs one, and moves the check to every output along the way instead of a single gate at the end. It isn’t only design work that moves. It’s the analyst work that used to structure the request, the product manager’s work of grooming a backlog item until it was ready, the project manager’s work of sequencing whose turn was next. A business leader with an idea can build the prototype themselves, in minutes, absorbing pieces of all four roles’ work for that one instance. The people who used to do that work don’t disappear. Their judgment moves to setting the standard, running the review, and owning the exception, the part of the job a queue was never actually protecting.
What this is worth, at a scale we can already measure
You don’t have to take the larger claim on faith. A narrower version of it has already been measured, at companies that never went further than a shared design system: a governed set of visual components (paint chips), still built and maintained by hand.
Airbnb’s design system cut its combined UI design, development, and testing time by 60 percent. Westpac’s GEL system cut design time by 66 percent and pushed UI design output up sevenfold. VMware prevented roughly 30 percent of accessibility bugs before they ever reached QA. Figma found that teams working from an up-to-date design system completed design tasks 34 percent faster than teams without one. None of those companies had gone further than the paint chip, consistent components, consistent visual rules, still requiring a team of humans to build the system and keep it current.
Everything above made its case through design, because it’s the clearest version: everyone can see a color, a component, an accessibility violation, and judge immediately whether it’s right. But nothing about the mechanism is specific to design. The same shift applies anywhere a process runs on a standard that currently lives in a document, a policy, or someone’s head instead of in the system doing the work.
An underwriting decision has a standard: the rules that determine what qualifies, what doesn’t, what needs an exception. A contract review has a standard: the clauses that are approved, the language that isn’t, the terms that trigger legal sign-off. A benefits eligibility call has a standard: the policy as written, not the version the rep half-remembers from a training two years ago. In every one of these, the same failure shows up when you shift left without shifting the standard with it: someone moves faster, and the risk sits exactly where it always sat, waiting for a reviewer who now has more of it to get through, faster, with less time to catch it.
Shift left hard means the same thing everywhere it applies: the standard, whatever it is for that process, gets compiled into what the person or the agent is drawing from, before they act, not checked after. Design is just an example you can visualize.
We don’t have a measured number yet for what happens when business rules join the visual layer in the same governed system, the way Airbnb or Westpac measured their design systems on their own. What we can reasonably project: if a consistent paint chip alone is worth a 60 to 66 percent cut in design and development time, adding the layer that actually causes most rework, the rule, the exception, the regulation nobody wrote down in the first place, should compound that, not just add to it. A design system reduces visual rework. It doesn’t touch the rework that comes from a wrong business rule reaching code in the first place. By the research above, that’s a different, and likely larger, share of the cost.
Shift left hard doesn’t make the old steps faster. It removes them. What that’s worth isn’t just a speedup multiplier on the new process. It’s the up-to-hundred-times penalty the old process used to pay for catching things late, that a removed step no longer incurs at all.
Traditional process improvement almost always trades one thing for another: fast, cheap, or good, pick two, is one of the oldest observations in the discipline. Shift left hard breaks that trade, because the same mechanism drives all three at once:
Shift left hard doesn’t trade fast against cheap against good. It delivers all three, from the same mechanism.
OpenAI found that 61.5% of real-world AI work requests could not be mapped to an occupation. This article examines what that missing majority reveals about traditional job-based workforce models—and why measuring work through governed, reusable skills provides a clearer view of AI impact, workforce capability, and how work actually gets done.
In July 2026, OpenAI published Work at the Frontier. Researchers analyzed more than 800,000 chat messages, real requests from people trying to get work done, and tried to match each one to an occupation.
Three outcomes were possible. The request matched the sender’s own occupation: 21.8 percent. It matched a different occupation: 16.8 percent. It matched no occupation at all: 61.5 percent.
The research question was about job boundaries, so only the first two outcomes could answer it. OpenAI reported the 61.5 percent, then excluded it from the calculation. Of the requests that could be tied to an occupation, 43.5 percent crossed into somebody else’s. That is the number being quoted everywhere.
The number nobody is quoting is the one that got set aside.
Now look at what the same company builds. OpenAI’s research measures work as tasks rolled up into occupations. Its products run on skills: ChatGPT and Codex both adopted the open agent-skill format, where each file holds one capability and the standard for performing it. The research and the products use different units. The research uses the one that cannot hold most of the behavior.
A task is a piece of work to be done. Build the Q3 revenue forecast for the EMEA region.
A skill is a capability that gets a task done. That forecast takes an analyst four of them: financial modeling, variance analysis, reading the pipeline for what is real, and defending a number in front of a CFO. One task, four skills. The task ends. The skills remain: they repeat across hundreds of other tasks and travel with the person into the next role at a higher proficiency.
An AI skill is a file. Developers and, increasingly, employees use it to give an AI system instructions for one job. It is software configuration, not a human capability.
Throughout, skill means human capability. AI skills are named explicitly.
That analyst’s job description probably says she supports regional planning and reporting. None of her four capabilities appear on it.
That is the 61.5 percent, and it is not an artifact of OpenAI’s dataset.
Job descriptions are duty lists, and duty lists are always incomplete. Work shifts week to week. Much of what someone did last month was never assigned in a document and never will be.
Capabilities are different. They are finite and you can name them. You cannot list every negotiation a commercial lead will run this year. You can state that the role requires commercial negotiation at a defined proficiency, and that holds across all of them.
That is the difference between a job description and a skill profile. Stop enumerating the work. Name what the work requires.
Mercer’s 2025/2026 Skills Snapshot found 38 percent of organizations now maintain a single enterprise-wide skills library, up from 30 percent in 2023. It also found 55 percent map skills directly to jobs, up from 47 percent.
Then look at what the library is used for. In a 2024 Gartner poll of HR leaders, 2 percent said their organization had adopted skills-based approaches across all their processes.
Nearly two in five have built the inventory. Almost none run the business on it.
Buying a taxonomy can take an afternoon. Getting the business to agree on what a skill means, at what proficiency, and for which roles takes quarters. Resolving every role, job, program, and pathway to the same canonical skills, then keeping that system current as work changes, is where these programs stall. Most stop at a library that nothing downstream reads.
Career Highways analyzed roughly 3,500 roles inside one organization. About 800 of them shared the same top strategic skills.
That is not sloppy job design. It happens for two reasons.
Skills deepen across roles rather than getting replaced. An analyst, a manager, and a director may all require financial forecasting. That is one capability at three proficiency levels. People do not swap skills out when they move up. They get better at what they hold and add a few.
Strategic skills are needed in many places at once. If a company competes on customer retention, customer-needs analysis appears in sales, service, product, and marketing. Breadth is what makes a skill strategic.
This is why “43.5 percent of AI use crosses job lines” sounds more alarming than it is. When a designer’s AI use resembles a market researcher’s, the job-based view reports a boundary crossing. Both roles run structured analysis of qualitative feedback. One capability, two subjects, and it was always in both jobs. Nobody wrote it down in either.
The two views lead to opposite decisions. Crossing tells you to redraw job boundaries. Sharing tells you to build one capability deliberately for everyone who needs it.
Skills are not another HR program. They are the foundation the others depend on.
Once every role, person, program, and pathway is expressed through the same governed skills, compensation can tie to capability and market value instead of title and tenure. Development can target the specific gap between what someone holds and what the next role requires. Internal mobility becomes visible because you can see who is already most of the way to a role nobody offered them. Workforce planning can show where capability is concentrated and how long it would take to rebuild.
The biggest implication is AI impact.
In a skills-based organization, AI impact is not a study you run once. It becomes an attribute of every skill: whether AI automates the capability, augments it, or leaves it as a human advantage; how much can be delegated to a system; and which AI capability is driving the change. That attribute is governed and versioned, just like proficiency and scarcity. When AI shifts, you update the skill. Every role and person expressed through that skill updates with it.
How the research decides what AI can do
This matters because the headline numbers rest on it.
The method behind much of this work comes from Eloundou, Manning, Mishkin, and Rock in 2023. It works like this. Take the government’s catalogue of task statements for an occupation, one-line descriptions such as “prepare financial reports.” For each one, answer a single question against a rubric: would access to an LLM cut the time to do this by at least half, without losing quality? Code the answer three ways. Add up the results to get the occupation’s percentage.
GPT-4 rated all of them. Humans rated a sample. The rubric given to GPT-4 was, in the authors’ words, “modified to enhance agreement with a set of human labels.”
No model is run on the actual work. Nothing is checked for correctness. The output is a prediction about a sentence.
The authors are direct about the weaknesses. Their annotators were “not occupationally diverse” and may hold “biased judgments regarding LLMs’ reliability” in unfamiliar domains. They state that obtaining high-quality labels requires workers engaged in those occupations. They also note that the results are sensitive to the rubric’s wording, the prompt’s order, and which examples are included.
So “90 percent exposed” does not mean AI can do 90 percent of a job. It means a model predicted AI would at least halve the time on 90 percent of the catalogued task statements.
That estimate is one side of the comparison people quote. OpenAI’s April framework sets it beside observed AI use, roughly 23 percent in the most exposed occupations, and calls the distance the capability overhang.
Two problems. The estimate and the observation are different kinds of numbers, yet subtracting one from the other produces something that looks like a measurement. And both are matched against occupation-based definitions, where the 61.5 percent already told us most of the work is missing.
The useful measure runs the other way: not the shortfall against a rated hypothetical, but the gain you have actually realized. It is the share of work now automated or augmented by AI, measured at the skill level, from work that actually happened.
That number is computable in a skills-based organization and nowhere else. Every canonical skill already carries its category. Roll those skills up to a role and you get the role’s position. Roll them across the organization and you get the enterprise position. The measure carries a date, expires, and is re-derived when the underlying skills change.
Two signals. Both are already inside your company.
The first is what people use AI to help them do. Map that activity to job titles and most of it disappears. OpenAI’s 61.5 percent makes that visible. Map it to canonical skills and you can see which capabilities people are exercising, where AI is landing, and whether your AI impact assessment matches what is happening in the building.
The second is stronger. When an employee builds an AI skill to help them work, they are writing a specification of a capability: what it is, when it applies, and how it is done correctly here, precise enough for software to execute.
Now set that against what the exposure researchers said about their own method. High-quality labels, they wrote, require workers engaged in those occupations. Those workers are now producing exactly that, unprompted, every time they author an AI skill to get work done. But the signal is readable only if you have a skills foundation to attach it to.
OpenAI measured how people actually use AI at work and found that 61.5 percent of the requests did not map to any occupation. It then set that finding aside because it could not be used in the occupation-based calculation.
That is the point. Work happens at the skill level, not the title level. Measure by job title and you cannot see most of what AI is doing to your workforce.
AI pilots are failing at significantly higher rates than traditional IT projects, but the technology itself often isn’t the root cause. Research points to three deeper problems: poorly defined business problems, existing processes that were never redesigned for AI, and critical business rules that were never codified for machines to execute.
This article examines why even well-planned AI initiatives can stall when agents are forced to interpret fragmented policies, undocumented institutional knowledge, and conflicting sources of truth. It explores how a governed enterprise knowledge layer and machine-readable rules can give AI agents consistent, executable guidance instead of requiring them to infer the answer.
Everyone has a theory for why AI pilots stall. The data’s messy. The model isn’t good enough yet. The rollout moved faster than the training did. Pick a theory and you’ll find a vendor selling the fix for it.
The actual research says something less obvious. Most AI pilots aren’t failing because of the AI.
RAND found that AI projects fail at more than twice the rate of ordinary IT projects, over 80 percent. Project NANDA’s preliminary findings, out of MIT, put the share of generative AI pilots showing no measurable return at 95 percent. Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027. S&P Global found the share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent in a single year.
Ordinary IT projects have never had a great track record either: Standish’s long-running research puts outright failure at roughly one in five projects, with close to half landing over budget or over schedule. AI projects failing at all isn’t surprising, then. What’s alarming is that they’re failing at several times that baseline rate, not a modest step up from it.
There are three failure reasons underneath all of that, and none of them is the model.
RAND asked the people who build these systems why their projects failed, then ranked the causes. The most common one was business leadership misunderstanding how to set the project up to succeed in the first place. Nobody defined the problem clearly enough before the work started.
That’s not new, and it’s not really about AI. PMI’s research on project failure found that inaccurate requirements were the primary cause of failure in 37 percent of unsuccessful projects, going back over a decade before anyone was running an agentic pilot. Every project, AI or otherwise, needs a clear problem statement and a real success metric. That part is table stakes. Get it right and you’ve earned the right to build. You haven’t fixed anything yet.
Deloitte’s explanation for its own failure data is that organizations are automating broken processes instead of redesigning operations. “Broken” isn’t quite right, though. Most of these processes aren’t broken. The company is still running, which means the process works well enough to get by. Some of it is genuinely inefficient. But the bigger issue is that AI lets you do the underlying work differently, not just faster. A step that used to need its own approval, its own handoff, its own person, existed because that’s what the available tools permitted at the time, not because the work actually required it. Automate that step exactly as it stands, and you take a constraint that no longer applies and build it permanently into the new system.
Deloitte’s own numbers show how often this gets missed: nearly half of organizations introduced AI without redesigning the workflow it sits inside, and just 12 percent report redesign at scale, with a new operating model behind it. Redesign, in the sense process people actually mean it, isn’t reshuffling boxes on a flowchart. It’s asking, for every step, whether it should be eliminated, combined with another step, or shifted somewhere else, the same three moves that have defined process redesign since business process reengineering became a discipline in the 1990s.
Here’s where it usually breaks down for an AI pilot specifically: the subject matter experts are typically in the room, most teams get that part right. What doesn’t get questioned is the tooling underneath them. A system of record, a productivity tool everyone already knows how to use, gets treated as fixed infrastructure rather than one more thing worth asking about, so the redesign happens around it instead of including it. Nobody sits down and asks whether that tool, or the step it requires, is still earning its place, or whether it’s just familiar. Redesign doesn’t get skipped on purpose. It gets skipped because the existing system was never actually on the table. And redesign isn’t just rearranging the same steps in the same order. It’s asking whether the process needs all of them: fewer handoffs, fewer tools, fewer places where a request sits waiting on someone else’s calendar before anyone even looks at it. Automate it exactly as it stands, same steps, same handoffs, same queue, and you get the same inefficiency. Just faster, and executed with more confidence.
Here’s what the research doesn’t say loudly enough: plenty of pilots start with a genuinely well-defined problem, and a real process redesign, and still fail. The team interviews the right people. They write down the actual requirements. They redesign the process instead of automating it as-is. And the pilot still stalls, because the AI can’t return the same result twice, or hit the accuracy a given step actually requires.
A requirements document describes what the process should do. It rarely contains the actual rules the process runs on: the eligibility logic, the pricing exceptions, the compliance thresholds, the judgment calls a fifteen-year employee makes without thinking about it. That knowledge lives in application code nobody wants to touch, in a compliance folder nobody opens except at audit time, and in the heads of the two or three people who’ve been doing the job the longest. IDC estimated years ago that Fortune 500 companies lose at least $31.5 billion a year because knowledge like that never gets written down before someone leaves.
Even when the knowledge does exist somewhere, an agent still has to find the right version of it. Ask an agent for the current expense policy and it doesn’t fail because it can’t read. It fails because it pulls whatever document SharePoint or OneDrive ranks as most relevant, which might be last year’s policy, a draft that was never approved, or a regional variant that doesn’t apply to the group asking. Nothing in a shared drive tells the agent which version is actually in effect. A person doing the same search has the same problem; a person just has more context to catch the mistake before it turns into a decision.
Companies have tried to fix this before. Business rules engines have existed for two decades specifically to pull logic out of code and into one governed place. They’ve been costly, and they’ve mostly failed for the same reason: nobody got all the rules into one place that was actually accessible to everyone who needed it, the people running the process, the systems executing it, and now the agents automating it. A rules engine gets built for one team, then another team builds a second one, and a third keeps its logic in a spreadsheet nobody else can see. Large companies routinely end up running two or three rules systems that don’t talk to each other.
There’s a more basic reason they never became the single source of truth. They were built for IT and systems to execute, not for the humans who actually own the policy to read. A business owner couldn’t open the rules engine and confirm it said what they meant, so they kept their own version, a spreadsheet, a policy document, a page in someone’s head, and the two drifted apart the moment either one changed. That drift never went away. It’s compounded. The same rule can now live in a rules engine, in application code, in a policy document, in an AI agent’s prompt, in a skill definition, and in the head of whoever’s been doing the job the longest, all at once, with nothing keeping them in sync.
If your AI pilot is trying to fix this right now, it’s probably reaching for an ontology, a knowledge graph, or a semantic layer, the standard fixes everyone reaches for. Each one can genuinely help. An ontology gives the model a map of how things relate. A semantic layer keeps a term or a metric consistent. A knowledge graph connects facts that used to sit in separate silos. What none of them do is codify the actual business rule. They’re probabilistic, every one of them, which means none of them can guarantee the answer. The model is still inferring, still weighing likelihoods, still capable of being wrong in a new way instead of the old one. Stack probabilistic tools on top of a probabilistic model and you get a better guess. You don’t get a deterministic one.
An AI agent running on top of that fragmentation doesn’t fix it. It has to guess at the eligibility rule, the discount exception, the compliance threshold nobody wrote down, and it guesses with total confidence. That’s how a pilot produces a fabricated eligibility decision or an invented discount that sounds right and isn’t.
Business rules, business logic, company policy, the law and industry standards that apply to you, none of it is real to an agent until it exists as structured, machine-readable rules instead of a document the agent has to interpret, a governed source of truth compiled into a form software can actually execute. That’s rules as code. Policy as code, law as code: the same idea wearing different names.
We call the source of truth Canon and the compiled, machine-readable version SIGN. The name doesn’t matter. What matters is that the rule gets decided once, in one place, instead of guessed at differently by every agent and every person that touches it.
That’s the difference between a pilot that gives a different answer every time it’s asked and one that gives the same answer every time, and can show exactly where that answer came from.
You need a governed enterprise knowledge layer. Not an ontology, and not a knowledge graph, though if you already have one, it becomes an input to build from rather than a separate system to maintain on top of it. We call it Canon, and the name means what it says: a single place, in the true sense of the word, your source of truth, where the policies and business rules that actually run your business get written down once and kept current.
Canon by itself isn’t enough. It gets compiled into SIGN, a language your agents can execute directly instead of interpreting from a document. That compilation is what makes agent behavior deterministic: the agent isn’t inferring the rule from whatever context it happened to find, it’s following the rule it was handed, so the same input produces the same response, every time.
You’ve invested significantly in your AI pilot. Let’s save it.
Featured in Forbes
As businesses build more of their institutional knowledge into AI systems, questions of ownership, portability, and control are becoming increasingly important. In this Forbes article, Jason Snyder examines the risks of AI vendor lock-in and what happens when the technology an organization depends on changes, disappears, or can no longer carry its accumulated knowledge forward.
Career Highways CEO Liz Eversoll shares her perspective on why portability and explainability are becoming essential to trusted enterprise AI—and why organizations need both control of their data and confidence in the decisions AI makes with it.
As organizations embed AI deeper into everyday operations, a critical question is moving to the forefront: Who controls the knowledge and intelligence created along the way?
In the Forbes article “We Are Renting Our Brains, And Nobody Reads the Lease,” technology writer Jason Snyder examines the growing risks of AI and SaaS vendor lock-in—from model deprecation and data portability to the loss of institutional knowledge accumulated inside systems an organization ultimately does not control.
Career Highways CEO Liz Eversoll contributes an important distinction to that conversation: organizations need both portability and explainability. They need the ability to act on their own data and take it with them, but they also need to understand and trust the decisions AI systems make while that data is being used.
That distinction becomes particularly important in workforce technology. Skills data represents both an organizational asset and an individual’s professional identity. When AI influences decisions about skills, roles, mobility, and opportunity, organizations need more than an answer—they need governance, traceability, and the ability to understand how that answer was reached. As Liz explains in the article, an AI system may be capable of making a decision without those foundations, but it may not be capable of defending it.
The Forbes article explores why control, portability, explainability, and trust are quickly becoming fundamental requirements for enterprise AI.
Career Highways CEO Liz Eversoll was recently featured in Forbes in “We Are Renting Our Brains, And Nobody Reads the Lease,” an examination of AI vendor lock-in, data sovereignty, and the growing importance of maintaining control over the knowledge organizations build within AI systems.
In the article, Eversoll discusses two critical requirements emerging as organizations adopt AI at scale: portability and explainability. Businesses need the ability to act on and retain control of their own data while also understanding and trusting the decisions AI systems make with it.
The discussion reflects a growing shift in enterprise AI—from simply adopting powerful technology to ensuring that the intelligence organizations build remains portable, transparent, and governed.
Career Highways CEO Liz Eversoll joins The TechEd Podcast to discuss how organizations can move beyond traditional job architectures and embrace skills intelligence. The conversation explores AI, workforce transformation, and practical strategies for building more agile, skills-driven talent ecosystems.
As enterprises move from chat assistants to production agents, the real constraint isn’t model intelligence — it’s the context window, and it’s denominated in tokens. This piece traces why: how text becomes tokens, why the key-value cache makes those tokens the true driver of cost, latency, and memory, and why the format you choose to represent knowledge is both an efficiency and a reasoning-quality decision. It introduces SIGN, Career Highways’ open notation, which cut a ~200-document canon by roughly a quarter versus markdown — with the deepest savings in the most governed content.
As enterprises move from chat assistants to production agent systems, a quiet architectural truth is surfacing: the binding constraint on an agent is not the intelligence of the model. It is the context window — and the context window is denominated in tokens.
Every rule, definition, and governance constraint an agent must operate under has to enter the model as tokens. There is no side channel. This piece traces a single causal chain that most knowledge-management strategies ignore: how text becomes tokens, why tokens govern the real economics of inference through the key-value cache, and why the format you choose to represent enterprise knowledge is therefore both an efficiency decision and a reasoning-quality decision — not a documentation one. It is the argument behind SIGN™ (Sigil Intelligence Graph Notation), an open specification originated at Career Highways, illustrated here with measurements against our full ~200-document canon.
A language model cannot operate on letters or words directly; it operates on numbers. Before any text reaches the model it is segmented into tokens — typically subword chunks — and each token maps to an integer ID drawn from the model’s fixed vocabulary. Common words often become a single token; rarer strings are assembled from smaller pieces. In English, a token averages roughly three-quarters of a word, though this varies substantially with language, code, and numeric content and should be treated as a rule of thumb rather than a constant.
The consequence is that structure is not free. Punctuation, delimiters, and repeated field names are all tokenized exactly like meaningful content. A model is, mechanically, a next-token predictor rolling forward one vocabulary entry at a time — and it pays, in every sense, for each token it must carry. The question ‘how do we represent knowledge for an agent?’ is, underneath, the question ‘how many tokens does that knowledge cost, on every single call?’
To understand why token count is so consequential, look at how autoregressive generation actually runs. The core operation of attention projects each token into a query, a key, and a value. To generate the next token, the model compares the current query against the keys of every prior token and blends their values accordingly. Naively, producing a sequence of length N would recompute every token’s projections at every step — work that scales with the square of the sequence length.
The standard optimization is the key-value cache. A token’s key and value never change once it is in the sequence, so they are computed once and stored. Each new step then processes only the single new token and reads the rest from cache, collapsing per-step work and making generation practical. Essentially every production inference stack relies on it.
The catch is where that cache lives and how it grows. The KV cache must sit in fast accelerator memory for the entire lifetime of a request, and its size grows linearly with the number of tokens in context and linearly with the number of concurrent requests. Model weights are a fixed, one-time cost; the KV cache is a per-request, per-token cost that stacks. On long contexts under real concurrency, it can rival or exceed the memory footprint of the weights themselves, and it is frequently the true reason a deployment runs out of memory or slows down — not model size, but the aggregate weight of the caches.
This reframes what a token in the context window costs. It is not merely input billed once. Each token is persistent accelerator memory held for the duration of the request, and it contributes to latency. And critically, every token spent on knowledge overhead is a token unavailable for the model’s own reasoning — a point we return to below. In an agentic enterprise running many calls per day, the representation of knowledge becomes a first-order driver of cost, throughput, hardware ceiling, and the room left to think.
If tokens are the currency and the KV cache is the reason they are expensive, then the encoding of enterprise knowledge is an efficiency lever hiding in plain sight. The formats teams reach for were each designed for a different consumer, and none for the agent context window as the primary unit of consumption.
| Approach | Limitation for agent knowledge |
|---|---|
| JSON | Machine-readable but token-heavy. A large share of tokens is structural noise — braces, quotes, and field names repeated on every record — carrying no domain meaning. Weak at expressing relationships, constraints, or inference. |
| Raw markdown | Token-efficient but structurally untyped. An agent cannot reliably distinguish a hard constraint from a property or a description, and there is no relationship model. |
| RDF / OWL | Semantically rigorous but adoption-hostile: verbose syntax, heavy toolchain, and sparse presence in model training data, so models are not fluent in it. |
| Prompt engineering | Fast but ungoverned — unversioned, unauditable, and non-reusable. It does not survive scale. |
The gap is not a syntax preference. It is that typed, governed knowledge and low token cost have been treated as mutually exclusive. Structure-rich formats are expensive; cheap formats are unstructured. That trade-off is the tax.
SIGN is a knowledge-contract notation designed against the agent context window as its target. Its central move is the use of sigils — compact, single-glyph markers — to carry type and structure densely, so that entities, properties, relationships, constraints, inference rules, and provenance can be expressed with the fidelity of a knowledge format without the structural-noise premium a serialization format like JSON imposes.
Rather than lean on a single hand-picked document, we measured the effect across our entire canon — 198 documents with one-to-one markdown-to-SIGN coverage. Encoding the corpus in SIGN rather than markdown reduces it from roughly 372,000 tokens to roughly 275,000: about a 26% reduction against a format that is already lean, and a far larger reduction against the JSON many teams would otherwise inject.
| Corpus | Markdown | SIGN | Savings |
|---|---|---|---|
| Canon core (44 docs) | 109,600 | 87,900 | 20% |
| Tenant canon (154 docs) | 262,200 | 187,100 | 29% |
| Combined (198 docs) | 371,700 | 275,000 | 26% |
The corpus-level average hides a more useful signal: SIGN’s™ savings track structural density. Prose-dominant material compresses least — general commons and domain documents land around 85% of their markdown size — because there is little structural overhead to remove. Highly structured, governance-heavy material compresses most: our top-level governance charter falls to roughly 45% of its markdown size, since that is exactly the content where typed declarations, relationships, and constraints would otherwise carry the heaviest scaffolding. The rule of thumb for builders: the more typed and relational your knowledge, the more a purpose-built notation returns.
These figures are estimates from modern subword tokenizers, not official counts from a specific production model. We bracketed the corpus with two independent tokenizers; they agree to within about 0.6%, and tokenizer choice does not move the comparison. As a known property of this class of tokenizer, absolute counts tend to run somewhat below a frontier model’s own tokenizer on prose — plausibly on the order of 10–20% higher in the real model, more on heavily structured text — so treat the absolute totals as a floor and the ratios as the durable result. What is invariant under any tokenizer is the comparison itself: the format runs about three-quarters the size of markdown overall, and the savings concentrate in structured content.
Efficiency is only half the story, and arguably the smaller half. The more consequential effect is on how well an agent can reason over its knowledge — and this arrives through two distinct channels.
The first is representational. Markdown gives an agent text to retrieve; a typed notation gives it structure to reason over. When a constraint is explicitly marked as a constraint, a relationship as a governed predicate, and a fact as asserted-versus-inferred with its provenance attached, the agent is not left inferring the shape of the knowledge from prose formatting. It can distinguish a rule it must enforce from a property it may use, traverse declared relationships rather than pattern-match across paragraphs, and weight a fact by its derivation rather than by how confidently it happens to be phrased. Each of these removes a class of misread that untyped text invites — the failure mode where an agent treats a hard mutex as a soft suggestion, or an inferred claim as ground truth.
The second channel is budgetary, and it ties directly back to the KV cache. Modern reasoning models do their best work by spending tokens to think — intermediate reasoning, self-checking, working through constraints. That reasoning competes for the same finite context window, and the same cache memory, as the knowledge you inject. Every token reclaimed from knowledge overhead is a token returned to the model’s reasoning budget. A roughly one-quarter reduction in the resident cost of the canon is not merely cheaper; it widens the headroom in which the model can actually reason before it hits the wall — and it does so on every invocation, so the effect compounds with agent volume rather than being paid once.
We want to be precise about the nature of this claim. The representational and budgetary arguments are mechanistic — they follow from how typed knowledge and finite context windows work — not from a controlled reasoning-quality benchmark, which we have not yet run. The honest next step is measurement: paired evaluations that hold the model and task fixed while varying only the knowledge encoding, scoring constraint adherence, correct inference, and error rate. The token economics are measured; the reasoning uplift is, for now, a well-grounded hypothesis we intend to test rather than a number we will quote.
For CTOs and researchers standing up agent platforms, the practical takeaway is to treat knowledge representation as an infrastructure decision measured in tokens, not a formatting choice — and to recognize that the same decision governs how much room the model has to think. Instrument the token cost of your injected knowledge, treat that cost as recurring KV-cache pressure rather than a one-time input charge, and prefer representations that hold typing and governance without the structural-noise premium.
SIGN™ is one answer, published as an open specification under the Apache 2.0 license so it can be evaluated, measured, and adopted on its merits. Whatever notation a team lands on, the underlying discipline is the same: in the agentic enterprise, the context window is the constraint, tokens are how you spend against it, and the format of your knowledge determines both what you pay and how well your agents can reason within what remains.
SIGN™ (Sigil Intelligence Graph Notation) is Career Highways’ open standard for expressing enterprise knowledge — rules, constraints, and inference logic — in a form AI agents can read, reason over, and act on with governance. It makes knowledge executable rather than just accessible, cutting knowledge-layer tokens 50–60% while producing consistent, explainable, governed decisions.
Career Highways has released SIGN™ (Sigil Intelligence Graph Notation), a new open standard that turns enterprise policies, rules, and definitions into a structured format AI agents can read, audit, and act on. The company has also filed patent applications related to the technology and is making SIGN™ freely available under the MIT License.
As businesses move AI agents into real operations, a gap keeps appearing: agents can find information but struggle to apply company rules, respect constraints, or explain their decisions. SIGN™ closes that gap with a compact, token-efficient knowledge layer between enterprise systems and AI agents — one that can reduce representation overhead by up to 50% compared with formats like JSON, while keeping decisions governed and traceable.
SIGN™ lets organizations capture five things agents need: facts, rules, constraints, inference patterns, and provenance. The result is knowledge that’s structured, enforceable, versioned, and auditable — so an agent’s output can be traced back to the exact rule, source, and version behind it.
“SIGN™ gives organizations a governed way to declare what they know, what rules apply and what an agent is allowed to do with that knowledge,” said Liz Eversoll, CEO of Career Highways. “It is the missing contract layer between enterprise knowledge and agentic AI.”
Documentation, examples, and the codebase are available now on GitHub. Learn more at careerhighways.com.
New token-efficient format can cut representation overhead by up to 50% while keeping AI decisions governed, versioned, and traceable.
MADISON, WI — July 14, 2026 — Career Highways today unveiled SIGN (Sigil Intelligence Graph Notation) and confirmed it has filed patent applications tied to the technology. SIGN is an open standard that lets organizations translate their policies, rules, definitions, constraints, and provenance into a structured form that AI agents can read, verify, and act on. The company is publishing SIGN under the MIT License.
The launch targets a problem that surfaces as companies push AI agents from pilots into live operations: agents are good at retrieving information but unreliable at applying an organization’s actual rules, respecting its limits, or explaining the reasoning behind a decision. The underlying knowledge usually exists already — scattered across documents, systems, and governance workflows — but not in a shape agents can use consistently. SIGN sits between enterprise systems and AI agents as a compact, structured knowledge layer that fills that gap.
“AI agents are moving into production faster than most organizations can govern the knowledge those agents depend on necessitating a governance framework they can operate with,” said Liz Eversoll, CEO of Career Highways. “SIGN gives organizations a governed way to declare what they know, what rules apply and what an agent is allowed to do with that knowledge. It is the missing contract layer between enterprise knowledge and agentic AI.”
Career Highways frames SIGN as doing for enterprise knowledge what SQL did for structured data: providing a shared language. Where documents are human-readable but not enforceable, and JSON serializes data without conveying meaning, SIGN is purpose-built for agent reasoning. It lets organizations express five things — facts (definitions, properties, relationships, and domain knowledge), rules (the logic agents apply to decisions), constraints (the boundaries agents must stay within), inference patterns (when agents may draw new conclusions), and provenance (the source, version, and authority behind a piece of knowledge).
The company points to common failure modes that pure retrieval doesn’t solve: a customer-service agent locating the right policy but botching an exception, an HR agent surfacing career-pathway details while missing eligibility rules, a compliance agent citing a regulation but not the current version, or a workflow agent making a recommendation without showing which rule justified it. SIGN is built around three capabilities meant to address these — reasoning-ready knowledge that encodes rules and inference patterns rather than just generating text; governed decisioning through versioning, provenance, and auditability so outcomes trace back to a specific rule and source; and token efficiency that fits more governed knowledge into an agent’s context window at lower cost.
Releasing SIGN openly is a deliberate bet. “Foundational infrastructure wins when it is open,” Eversoll said. “SQL, HTTP and OpenAPI became durable because organizations could adopt them without locking themselves into one vendor. We believe the knowledge layer for AI agents needs that same openness.” Alongside the open standard, Career Highways plans to offer enterprise-grade infrastructure around SIGN — including registry, namespace, validation, audit, and governance systems — for teams deploying agentic AI at scale.
Documentation, examples, and implementation guidance are available now, and developers can access the codebase on GitHub. Learn more at careerhighways.com.
About Career Highways
Career Highways is a workforce strategy and technology company that helps large, complex organizations design and activate transparent, skills-based career pathways at enterprise scale. Its services and tools — including Skills Intelligence — digitize job architecture, map skills to roles, and turn workforce data into clear pathways for mobility, upskilling, and planning. By pairing AI-enabled insight with human expertise, the company supports better decisions about talent development, internal movement, and the changing impact of technology on work.
Media Contact: Philip Robertson, Impact Partners PR LLC
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.
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.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
