Skip to main content

Product: Workforce Ontology

TechEd Podcast episode featuring Career Highways CEO Liz Eversoll discussing AI, skills intelligence, and workforce transformation.

The TechEd Podcast

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.

An AI agent's context window filling with tokens as knowledge overhead competes with the space left for the model to reason.

The Context Window Is the Constraint

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.

Tokens are the unit of consumption

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?’

The KV cache: why token count governs cost, latency, and memory

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.

The representation tax

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.

What it costs across a real corpus

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.

A note on measurement

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.

From token savings to reasoning headroom

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.

Implications for builders

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.

Article: Intent Engineering — Software Was Never the Point

Intent Engineering: Software Was Never the Point

software-eating-the-world

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.

Diagram contrasting AI agents rediscovering context on every run versus operating against structured, executable enterprise knowledge to reduce token consumption.

From Tokenmaxxing to Skills Intelligence: Why AI’s Real Cost Isn’t Compute — It’s Context

Diagram contrasting AI agents rediscovering context on every run versus operating against structured, executable enterprise knowledge to reduce token consumption.

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.

Diagram contrasting AI agents rediscovering context on every run versus operating against structured, executable enterprise knowledge to reduce token consumption.

From Tokenmaxxing to Skills Intelligence: Why AI’s Real Cost Isn’t Compute — It’s Context

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

Overflowing drawer of notes illustrating why a second brain becomes a graveyard of unused ideas

A Second Brain Won’t Run Your Company

Overflowing drawer of notes illustrating why a second brain becomes a graveyard of unused ideas

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.

Read the full article →

Overflowing drawer of notes illustrating why a second brain becomes a graveyard of unused ideas

A Second Brain Won’t Run Your Company

Everyone is building a second brain. 

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.