Ask Claude Code, Cursor, or Copilot to add a dependency and it names one — instantly, confidently. That confidence comes from training recall: a snapshot of scraped code frozen at a cutoff date. So the agent can't know your team already has an internal, audited library for this. It can't know the package it just named went unmaintained six months ago, or that a supply-chain advisory landed last week. It picks anyway, with identical confidence either way.

Here's the part that compounds: a wrong pick doesn't bounce off. It gets written into your codebase — a hand-rolled auth flow, a dependency on an abandoned package, a second module that duplicates something you already own. That's tech debt the agent created and you inherit. And it's debt with interest: the agent builds on the bad choice, the problem surfaces downstream, and then you pay again — in tokens, review time, and rework — to unwind and redo it.

That's not a prompt problem. You can't fix it by asking the model to "be careful." The model is doing recall where it should be doing evaluation, and recall is frozen.

What recall costs you

A few findings that should make you nervous about an agent picking dependencies unsupervised — and notice not one of these is only a security problem:

• Nearly 1 in 5 packages an LLM names in generated code don't exist — 19.7% across 16 models and 576,000 samples, rising to ~22% for open-source models (Spracklen et al., USENIX Security 2025). A non-existent package is, at best, a failed build you have to diagnose and redo; at worst, an attacker has registered the popular hallucination and waited (the pattern now has a name, slopsquatting).
• ~45% of AI-generated code introduces a known security weakness — Veracode's 2025 review of 100+ models across 80 tasks (report).
• For whole categories of functionality — auth most damningly, where a custom flow is both a liability and code you now own forever — the agent's default is often to hand-roll custom code rather than reach for a mature library. (That one's my own finding; I reproduce it below.)

Each is a place recall fails, and a smarter prompt can't fix a frozen snapshot. The fix is putting real, dated, structured facts in front of the model at the moment it decides.

It's not just security — what a wrong pick actually costs

When the agent chooses from memory instead of facts, you pay on four fronts. Security is the one everyone leads with; it's the smallest of the four for most teams.

• Tech debt — the headline. A guessed dependency is a future migration with your name on it: hand-rolled code you now maintain, an abandoned package you'll eventually rip out, a redundant library because the agent didn't know you'd already standardized on another. The cheapest debt is the line that never gets written.
• Wasted tokens and time. Reversing a bad pick isn't free. The agent writes code against it, the problem shows up later, and unwinding plus redoing is more model calls and more of your review. Facts at decision time cut that loop before it starts. (I haven't put a number on the token savings — it's a mechanism, not a measured stat; see limitations.)
• License exposure. "Is this AGPL? Does this license survive our distribution model?" is a business question, and recall answers it unreliably. A license fact catches the surprise before it's load-bearing.
• Security. The CVEs, the supply-chain incidents, the slopsquatting above. Real — but one axis of four.

All four share one cause: the decision got made without the facts. That's the thing Starlog targets.

Starlog: vet a package by name, at decision time

Starlog puts authoritative facts about a package in front of your agent — license, maintenance status, CVEs, supply-chain incidents — dated, local, no account:

npx starloghq facts ua-parser-js

You get the verified facts on file (here: the 2021 maintainer-account compromise), with an "as of" date. Sub-second, zero setup, no network call. It plugs into your agent three ways:

• a CLI (starlog facts <pkg>),
• an MCP tool (starlog_facts) the agent calls itself,
• and a package-install hook that surfaces a library's facts the moment the agent runs npm install / pnpm add / pip install — before it builds on the package. Advisory, not blocking: it informs the next move.

One command wires all three into Claude Code (and drops instruction files for Cursor, Copilot, and Codex):

npx starloghq init

That's the pitch. The rest of this post is whether it actually works — because "give the model more context" is easy to claim and easy to fake.

Does the agent's decision actually change?

I ran a controlled before/after. Control = a fresh agent answering from recall only. Treatment = the same agent, same prompt, given the package's Starlog facts. The only variable is the facts.

The experiment I had to throw out

My first private-package test gave the agent a fact that said "POLICY: you must use @acme/flags, do not build custom." The agent used @acme/flags 2/2. Clean flip!

It's also worthless as evidence. A fact that says "you must use X" only proves the agent follows instructions — not that the information changed its mind. (A reviewer caught this; it's a tautology trap, and exactly the kind of thing a vendor demo quietly leans on.)

So I re-ran it with an informational-only fact: it states that an active internal package exists, with no "must use," no "don't build custom." Then I let the agent use its own judgment.

With no facts, the agent reaches for build custom on both — including a hand-rolled, unaudited auth layer, the textbook tech-debt-and-security liability in one object. Given only the information that an active internal library exists — with no instruction to prefer it — it chooses the internal library over building custom, 2/2, on its own judgment.

That's a hand-rolled module that never gets written: debt avoided at the exact moment it would have been created, plus consistency with whatever the rest of your team already ships. And it's the case the model structurally cannot recall — it has never seen your private @acme/* packages. Facts are the only way it learns they exist.

The public side, honestly

Public packages are a weak venue for this — and saying so is more useful than hiding it. Claude's public recall is genuinely good, so most of the time the facts just agree with what it already knew:

The one clean, information-carrying public change is posthog-node: a supply-chain pin from after the training cutoff. That's the thesis in one row — facts matter precisely where recall can't reach. And the decoys didn't flip, so the agent isn't just rubber-stamping whatever the tool says.

Honest by design

The thing I'm proudest of is node-cache not counting as a win. The fact ("maintenance-only") is ambiguous, there's no ground truth, so it doesn't go in the tally. A tool that books every change as a victory is lying to you. Same reason starlog facts some-unknown-pkg returns an honest "no facts on file" instead of a confident guess — telling the agent "I don't know this one" is a feature, not a gap.

The bigger number behind the demo

The before/after above confirms the mechanism on real model calls. The statistical backbone is a prior powered benchmark across four model vendors, measuring the one thing that drives all four payoffs — decision correctness: correct adopt/avoid decisions moved from ~20% to ~78%, with 100% unprompted adoption — when the facts are available, agents reach for them every time. They want this signal; they just don't have it by default. Every correct decision is debt not taken on, rework not paid for, and the occasional CVE caught.

Honest limitations

• The curated corpus is 42 packages today — a foundation, not all of npm. Out-of-domain lookups return an honest miss, not a forced answer.
• The before/after is a single-rep confirmation of direction; the statistical claim is the prior powered benchmark, not re-run here.
• Token and tech-debt savings are argued from mechanism, not separately benchmarked. A wrong pick demonstrably costs rework to reverse; I haven't put a controlled number on how much Starlog saves there. The measured claim is decision correctness — treat the cost savings as the logical consequence, not a tested figure.
• Public packages are the weak case — by design. The value lives where the model can't recall: your private libraries, and anything that happened after the cutoff.
• The install hook is advisory. If you want a hard PreToolUse approval gate, that's a deliberate non-default — nudging beats blocking for adoption.

Try it

# vet a package — nothing installed, no account
npx starloghq facts event-stream

# wire facts into your agent (Claude Code, Cursor, Copilot, Codex)
npx starloghq init

Source-available under BUSL-1.1 (free to use, modify, and self-host; converts to Apache-2.0 in 2030), listed in the official MCP Registry as io.github.starloghq/starlog.

Repo, the 42-package corpus, and the full validation runbook: https://github.com/starloghq/index

If you build agents, the takeaway generalizes past dependency choice: anywhere the model is doing recall where it should be doing evaluation — anything time-sensitive, anything private — a small local index of dated, honest facts (one willing to say "I don't know") beats asking the model to try harder. The debt it never takes on, and the rework you never pay for, is the quiet win sitting right next to the CVE it catches. It can't recall what it never saw.