Experience Earned Through Tools Is Lost When the Tools Are Renamed

An agent that works something out writes it down in the names of its own tools. Rename them and the learning is gone, unless something matches on what the tools actually do.

Almost no agent in production learns anything. It keeps a log of what it did, which is a different thing entirely, and tomorrow it starts as ignorant as it started today. Hyperstruck agents do learn, and building that bought us a problem nobody else has had to solve yet: an agent that works something out has only one vocabulary to write it down in, the names of its own tools.

Say one of yours establishes that the schema check has to run before the loader, because the loader drops rows without complaining and you find out four days later from a customer. That learning cost a real incident, and it is written in terms of schema_validator and db_loader. Then the platform team renames those two tools. Or the group next door builds the same pipeline behind an MCP server that calls them check_schema and ingest. Or you stand up a second agent with its own registry. The learning is still there, still correct, still describing exactly the failure that is about to happen again, and it will never fire.

That is the difference between an experience layer and a filing cabinet. Experience that cannot move is not an asset, it is a side effect of one agent's configuration. So a learning in Hyperstruck asks whether you hold an equivalent tool, not an identically named one, and what one agent earns reaches an agent whose tools are named nothing alike.

The obvious fix recovers nothing

Match on names and see how far you get. Hyperstruck keeps that matcher and reports it beside the real one as a control, scored over a corpus where every domain holds a role-for-role equivalent of every other domain's tools under completely different names. It gets zero. Not weak, not noisy: zero by construction, because the thing it compares is the one thing two teams never agree on.

Fuzzy matching does not rescue it either. check_schema and schema_validator happen to share a word, so string similarity flatters itself on the easy pair and still tells you nothing about ingest. The failure was never spelling. A name is a local convention, invented once by whoever registered the tool, and it carries no information about that tool outside the registry it was typed into.

Two panels. On the left, a hard-won learning naming schema_validator and db_loader is matched against another team's tools named check_schema and ingest; the route dead-ends at a red cross and the learning is stranded. On the right, the same learning is matched on what each tool declares it does, lands on the equivalent tools, and arrives written over the reader's own tool names.

The catch

Being careless here would be worse than doing nothing. Two tools can look alike and do opposite things, and a learning about clearing out old records must never land on the tool that drops a database. So Hyperstruck matches two tools only when they are clearly doing the same job, and refuses everything else. On the hardest test we could build, where two teams share nothing but the shape of their data, that carries across 56% of the learnings and puts none of them on the wrong tool. What happens to the other 44% is the useful part: most of those tools say almost nothing about themselves, so there is nothing left to match on but their names. How far your agents' experience travels comes down to how well your tools describe what they do, and that was decided by whoever wrote them, long before any agent learned a thing.