The chart was right the day it was printed

On a ship's bridge, there's a paper chart, and it was right the day it was printed. After that, the sea kept moving. Sandbanks shift. Buoys get moved. A wreck settles where open water used to be.

So every week, hydrographic offices publish Notices to Mariners, a list of corrections for the charts already out there. Someone on board goes through them and fixes the chart by hand, noting each correction in its margin. Nobody thinks of this as extra work. It's the job. A chart nobody corrects will put you on the rocks, slowly and with total confidence.

This isn't a sailing story. It's a story about information that was true once and kept being trusted after it stopped being true.

Software has its own notices

Software has its own Notices to Mariners. Many APIs use a numbering rule called semantic versioning: three numbers, like 2.4.1. Change the first number, and you're telling everyone who depends on you that something will break. Change only the second or the third, and you're promising it won't. It's a small, polite system. The version number is the notice.

The question is whether anyone sends it.

Two in three don't send it

In 2024, two researchers at the Software Institute in Lugano, Souhaila Serbout and Cesare Pautasso, went and checked. They mined published descriptions of 3,075 web APIs from more than 2,000 open-source repositories, tracked over 16,000 new versions, and classified half a million individual changes as breaking or not. Then they compared each change with the version number it shipped under.

Only 517 of those APIs consistently bumped the first number when they broke something. 1,970 of them, about two in three, shipped breaking changes at least once under a version number that said nothing would break.

Teams track changes, few announce them

The industry survey numbers point the same way. In Postman's 2025 State of the API report, 60% of teams said they version their APIs, but only 26% use semantic versioning. Most teams track their changes. Far fewer tell anyone what those changes do to downstream users.

Agents don't read changelogs

Here's where it gets uncomfortable for anyone building with AI agents.

When an integration breaks on a person, they usually find out. Something errors, a customer complains, someone opens the changelog and swears a little. An agent calling the same API is in a different position. Often nothing errors. The request goes through, the response comes back, and a field is empty, renamed, or holds a slightly different kind of value than it did last month. The agent doesn't read changelogs. It has no colleague to ask. It takes the answer and keeps going, like a navigator who's never had anyone correct the chart.

What we found when we started

I'll be honest about what surprised me when we started running real questions through real data sources at Gecko. I thought the hard part would be connecting to them. The hard part turned out to be that connecting is never finished. In our first weeks of live runs, one source started answering "not found" for records that exist. Another stopped being able to take payment. Neither one announced it. We found out because we were looking.

Nobody's reading the notices

That's the part I keep coming back to. The sources aren't careless. Most of the APIs in that study changed for good reasons, and 927 of them never broke anything at all. The problem is structural. Everyone downstream assumes someone else is reading the notices, and an agent, by design, isn't.

Correction as a habit

Ships solved this by making correction part of the routine, every week, forever. Not a project with an end date. A habit with a log.

That's what we're building at Gecko: a way to get the data your agent asks for from the sources that know it, keep those sources working as they change, and record where every value came from. A chart someone keeps correcting.

So here's the question I'd leave you with. For the data your agents rely on today, who's reading the notices?