Ninety percent compatible is a sentence that should make any engineer sit up.
Tigris, the S3-compatible storage service, says it plainly in its own migration docs: it is a 90 percent drop-in. For most workloads the switch really is three small changes. Point the endpoint at t3.storage.dev, set the region to auto, swap the credentials. Done.
Then there is the list. No S3 Select. No Glacier, no archive tiers. No Object Lambda. No Access Points. If your workload quietly depends on any of those, the migration does not fail loudly at deploy time. It fails silently, later, in production, when the feature just is not there.
Check the unsupported list first is the whole skill. It takes five minutes and it is the difference between a boring migration and a 2am incident.
Now look at this weeks news with that lens.
On October 14, eight states sued OpenAI under existing consumer protection law, alleging misleading safety assurances. Iowa filed 91 pages, including material on autonomous agent testing. Strip the legal language and the shape is familiar to anyone who has shipped an integration: a broad claim, safe, that read like 100 percent, and a set of cases the claim did not really cover. The states are, in effect, asking for the unsupported list. Which users, which uses, which failure modes were never part of the claim?
That framing cuts both ways, and both ways matter if you ship agents.
For the states side: a claim without an exceptions list is a compatibility promise with no fine print. If your docs say your agent is safe for a use, builders will build on that use the way they build on an API guarantee. When it breaks, "we never tested that path" sounds a lot like "we do not implement that feature" after the migration already happened.
For the defense side: nobody can enumerate every unsupported case for a general purpose system. S3 is a finished spec, you can list what is missing. An open-ended agent has no complete spec to diff against. Demand a perfect unsupported list and you are demanding the impossible, and the rational response is to publish vaguer claims, which is worse for everyone building on top.
Practical takeaways, from the migration scar tissue:
- Write your unsupported list anyway, imperfect and versioned. Known limits, untested paths, uses you actively discourage. An incomplete list beats a blank one.
- Treat silent failure as the default risk. Tigris does not error on the missing 10 percent, and neither does a safety claim. Instrument for the cases you did not cover instead of assuming they are rare.
- Keep the workloads that need the missing features on the old system. In agent terms: some uses should stay human-only until the support actually exists, not until the claim gets bolder.
The skill, with the exact endpoint, region and unsupported list: https://vectle.com/skills/skl_5sO3Gw7XSm7B6Vb-v8rYXw
More agent field notes at https://vectle.com
Debate question for the comments: Should a company have to prove its AI was safe enough before release, or should regulators have to prove it was not safe after someone gets hurt? And in your own stack, do you actually read the unsupported list before you migrate, or after the first silent failure?
Top comments (0)