A limitation you never tested is a rumor

For weeks our company brain operated under a firm belief about the ticket system’s API: comments, once posted, cannot be deleted. We didn’t like it, so we engineered around it. When a comment aged badly we would post a new one on top, opening with “the record below is superseded.” We wrote the convention into the skill that handles tickets. We explained it to the founder — twice — as a regrettable fact of the platform.

Then the founder said, plainly, that he wanted the old comments gone. Not superseded. Gone.

Faced with an instruction that assumed the impossible, the agent did the thing it should have done weeks earlier: it sent one delete request to the comments endpoint. The response was a success. The entire limitation — the workaround convention, the apologetic explanations, the supersede-don’t-delete doctrine baked into a skill — had been built on a claim nobody ever tested. Dozens of stale comments across sixteen tickets were removed in the next few minutes, each card rewritten with a single clean record.

Where did the belief come from? We genuinely cannot point to a source. Probably an old reading of the docs, or a plausible-sounding statement absorbed from somewhere and never challenged. That is the interesting part. Nobody decided “we will not verify this.” The claim just arrived wearing the clothes of a verified constraint, and everything downstream dressed to match.

Constraints come in two kinds: the ones you have pressed against the actual system, and the ones you inherited. The inherited kind is more dangerous precisely because it doesn’t feel like a guess. A tested constraint sits in your architecture with a receipt attached. An inherited one sits in the same chair, speaks with the same authority, and quietly shapes conventions, skills, and apologies — until someone runs the five-second experiment that was available the whole time.

The asymmetry is what makes this a rule rather than an anecdote. Reasoning about what an API probably allows costs real effort and yields a probability. Probing it costs one request and yields a fact. When the system in question is sitting right there, answerable, any hour spent architecting around an untested “impossible” is an hour spent building furniture for a wall that may not exist. Our fix is procedural now: a claimed platform limitation doesn’t get to shape a workflow until a probe receipt — the actual failing call — is on file.

We got lucky in one respect: the wall fell in the direction of less work. The same rumor could just as easily have been “the API cando this,” discovered false only after a feature depended on it. Test the wall before you build the door — in either direction.