Your agents are a generation behind, and they will never tell you

Last week a company called TypeSafe shipped a model named Jev, and I spent an afternoon arguing with an agent that had no idea it existed. Jev doesn't generate text. You hand it some state and a typed question and it hands back a value and a probability in a few hundred milliseconds, for about four cents per million input tokens. Whatever you make of the product — I have opinions, and they're below — it changes how you'd design a classifier, a router, or a spend gate. The agent kept confidently proposing a Haiku call in a loop, which was the right answer in May and is a worse answer now.

It never once said I might be out of date.

That's not a complaint about the models. It's arithmetic. Every model has a cutoff and everything after it is simply absent. What bothers me is the shape of the failure: an agent missing a fact doesn't hedge, it just designs with the best approach it knows and hands you something reasonable. No error. Nothing to grep for. You find out months later when someone ships the thing you could have built for a tenth of the cost, and the post-mortem is that nobody asked a question nobody knew to ask.

Most teams already wrote the rule meant to catch this. Ours lives in AGENTS.md and says, in enforced capital letters, to search before building. Good rule, real work — but it only addresses demand. It tells an agent to go look. It says nothing about what anyone found last time. So every agent, every session, re-runs the same three searches, reaches its own conclusion, and throws that conclusion in the bin when the session ends. The searching was never the expensive part. The judgment was.

A shelf, not a feed

So we built the supply side: a short shelf of dated, graded briefs on things our team actually adopted, or deliberately ruled on, after the models were trained. It ships with the ox CLI as an add-on, and ox addons install post-cutoff puts it in front of every coworker's agent, in every repo, once.

Everything interesting about it is a constraint.

The bar is adoption, not novelty. It launched last week and looks promising does not qualify, however true that is. If we use it, or looked hard and said no, it earns a place. Otherwise it's noise — and noise is fatal here, because the whole value proposition is that an agent can read the entire index before a design decision without thinking about it. A shelf you can't read in one glance is a shelf nobody opens, which is the same as not having one.

A person promotes every entry. An agent can research and propose; it never adds, and it never goes trawling release notes looking for things to put on the shelf. Deciding something is worth every teammate's agent knowing about is a judgment about where the team is going, not a research result. The moment an agent can self-serve that, you're back to unbounded search with extra steps.

And the arithmetic is unforgiving in a way that surprised me. In our monorepo, 96 registered skills cost roughly 10,700 tokens of always-on metadata — about 112 tokens each, paid at the start of every session whether anything reads them or not. Content inside a skill's references/ costs nothing until something opens it. So the index sits at the cheap tier and the substance sits at the free one, and every entry you add is a standing tax on every session forever. The public benchmarking points the same direction: a few well-targeted skills measurably improve outcomes while bloated sets measurably degrade them. More installed knowledge is not more capability. Usually it's less.

What an honest entry looks like

The first entry is Jev, and the honest version is the entire point.

TypeSafe's launch claims are that it runs 40 to 200 times faster than frontier models, costs a fraction as much, and "mathematically cannot hallucinate." The first two are directionally true. The third is where an entry earns its keep.

Cannot hallucinate means the model cannot emit a value outside the option set you supplied — the output head is the type, so a type error is impossible by construction. That's a genuinely lovely property and a much weaker claim than the words imply, because a confidently wrong boolean is still wrong and type safety has nothing to say about correctness. On an independent 2,000-email phishing benchmark Jev scored 62.6% where Claude Haiku 4.5 scored 81.3%. A plain regular expression scored 91.6%. TypeSafe publishes no calibration metric at all, and the independent work that exists found the miscalibration flips sign depending on the question type, which quietly means a single global confidence threshold is unsafe. The headline speed multiples come from the vendor's own tasks on the vendor's own harness timed on the vendor's own laptops — they disclose all of that, to their credit — and every independent measurement lands closer to 3–11× faster and 20–100× cheaper.

None of which means don't use it. We're running it in production, in a log-triage agent, and the entry is genuinely enthusiastic about the shape of the thing. But notice what a team gets from that paragraph that it cannot get from a launch post, a podcast, or an agent reasoning off the press cycle: a number to plan with, a threshold policy that won't silently betray them, and the instruction to benchmark a dumb regex first.

The best section in that entry never mentions TypeSafe. A large fraction of LLM calls in a mature codebase are decisions wearing a generation costume — you send a prompt, get text back, parse it down to one boolean, and throw the rest away. The tells are easy once you look: max_tokens set to 24, a validator rejecting anything outside a set you already knew, an expensive summarizer invoked and discarded whenever a skip flag comes back true. Finding those, typing them at the seam, putting a cheap gate in front of expensive generation — that's worth doing whether or not this particular vendor is alive next year.

Teach the shape, not the vendor. An entry that says call X is worth nothing the day X gets trained in or dies. An entry that teaches you to recognize a class of problem keeps paying either way.

Why this only matters if you have many repos

One repository needs none of this. Commit a markdown file, open a pull request, done. I wouldn't have built a tool for that and neither should you.

A dozen repositories and a team on different agents is a different animal, and the problem isn't authoring — it's distribution. The same shelf has to reach every repo, every teammate, and every agent brand — Claude Code, Codex, Gemini, Amp, Droid, Goose, OpenCode — and keep reaching them when somebody clones a new repo on a Tuesday afternoon. Copy a file into twelve repositories and you have twelve versions within a month, and the stale ones are worse than nothing, because a confidently wrong fact is precisely the failure we set out to fix.

That's the job ox team context already does, and it's the argument for ox we've been underselling: not that it stores your team's knowledge, but that it delivers it to heterogeneous agents in heterogeneous repos, continuously, without anyone opening a pull request.

ox addons install post-cutoff   # install a curated add-on once, for the whole team
ox skills publish <your-skill>  # push one you wrote up to your team, once
ox skills list                  # what your agents have here, and where each came from
ox skills status                # and when one hasn't arrived, why not

Those first two lines are the two directions this runs in — pull something curated down, push something you authored up — and either way it lands in team context once and radiates from there. An add-on is skills, rules, and the context each skill carries, and that last part is the one that matters: the context isn't dumped into your team's shared knowledge, it ships inside the skill that needs it, so an agent reads it exactly when the work calls for it and pays nothing the rest of the time.

The fourth line looks like a diagnostic and is actually the load-bearing one. A skill that failed to arrive used to look identical to a team that published nothing — a checkout that never cloned, a sparse set that never materialized, a repo none of the entries targeted, an empty shelf. All four produced the same output, which was nothing at all. Distribution you can't debug is distribution you can't trust.

Curated, not a registry

There's an obvious alternative: point at one of the big public skill registries and install whatever looks useful. We're not doing that, and it isn't snobbery.

The public skill ecosystem grew astonishingly fast and the security picture grew with it. One audit of nearly 4,000 skills found a security issue in 36.8% of them — 13.4% rated critical, 76 confirmed malicious, most working by prompt injection, which is exactly the attack an instruction file is shaped to carry. A follow-up technique defeated static scanners by packing payloads into directories the scanners skip. Meanwhile the ecosystem's own practitioners keep pointing at the structural hole: installs track branches rather than commits, and nothing in the toolchain resembles a lockfile.

An installed skill joins your agent's trust boundary. It's instructions, delivered to a thing that follows instructions, on every future session. Treating that like npm install and hoping is not a strategy.

So the ox catalog is small and first-party on purpose. Every materialized file is recorded with a SHA-256 digest in a committed lockfile. Anything in a team-published skill that could actually execute — a bundled script, an allowed-tools grant, an inline command — is withheld until a human approves it against the exact bytes they read, and that approval is committed, so teammates inherit it and it's reviewable in a pull request like any other decision. Curation is the product. Volume is what went wrong everywhere else.

The part I like most is that it rots

Every entry carries a valid-through date. Read an expired one and the agent is instructed to say so out loud and re-verify before relying on it. Retirement is a first-class procedure rather than a cleanup chore, and entries are never deleted — they move to a graveyard with the reason attached, because we looked at this and here's why it stopped mattering is frequently the most useful thing in the file.

The most common reason to retire something will be the happiest one: the models learned it. A year from now every agent will know what Jev is, the entry will be dead weight, and deleting it will be a small pleasure. That's the intended end state, and it's why the index carries a deliberate size budget — when the description grows past about six entries it stops working as a selection signal, which forces a retirement instead of an extension. A knowledge base with no eviction policy becomes a landfill. Making decay a mechanic rather than an intention is the only version of this that survives a busy quarter.

The window between this shipped and the models know it runs about a year right now. It's the most interesting window your team operates in, and most teams spend the whole thing unaware it's open.

Spending it in front instead is not much work. It's mostly deciding what you're willing to leave off the shelf.

The post-cutoff add-on is open source in the ox CLI repository, including its authoring procedure. The Jev entry ships as its own add-on — post-cutoff-jev. Steal the shape.