When a tool cannot do something, a person using an SDK works around it.

A diagram had a hide-on-mobile flag and no way to unset it, because the update tool took only data. A person deletes the block and re-inserts it without the flag, gets on with their day, and never reports anything. The gap is real and it stays invisible, because the workaround is faster than the complaint.

The agent did not work around it. It stated the tool could not clear the field, said which call and which parameter, and carried on with the next post. Then it did that again, and again, all morning, on a growing list.

That is reasoning applied to a surface while using it, which is what a person stops doing the moment they find a workaround. I would have hit that flag, shrugged, and shipped fifty-nine posts without ever writing it down.

Reasoning about a surface needs somewhere to point.

Changing a heading on post fifty failed with a validation error. The section held a code block whose language the schema had stopped accepting. That block rendered fine on the live site and failed only on write, so the heading could not be edited until the block was fixed.

No test pairs changing a heading with this post contains a block written before the schema moved. A real editorial pass pairs them on post fifty of fifty-nine, because that is where the combination happens to live. A test suite would have to anticipate the combination. The work found it by walking into it.

The most productive rule was to stop reading the stored structure and look at the page.

The structure showed nothing wrong. The page showed six image blocks with no image, each caption rendering alone as a stray line mid-paragraph. Four sections with a role and no heading, so the post ran as one wall of prose. Seven captions describing pictures that were not there, including one promising a screen mid-verification over a screenshot of two domains already connected. And a card linking to a code repository with every field set except the address, which rendered, looked clickable, and went nowhere.

Same principle at the other end of the work. The agent checks what it wrote against what a reader sees rather than against the structure it just produced.

The sharpest one came from the method rather than from any single call.

Creating a post accepts the whole content tree in one request. It works, and it is the fast path. A post created that way stored its sections, columns and blocks without generating identifiers for any of them, so it rendered perfectly and could not be edited, because every tool that changes a block needs an identifier to aim at and every one of them was empty.

A test that creates a post and checks the response passes. Only creating a post and then editing it finds this.

This post is the proof it is fixed. It was written through the same fast path, and every block came back with an identifier.

Working alone, this is the review a second engineer would have given the surface, done by the thing that was going to use it anyway.

It is slow, and tangled up with other work. The agent was not auditing. It was editing a blog, and every finding came from something being harder than it should have been.

If you ship a tool surface for agents, have an agent do a long piece of real work through it before deciding the surface is finished. Not a test pass. A job with a deliverable, long enough that awkward combinations come up on their own. Watch what it reaches for and cannot find. And make it render what it writes, because a structure that validates is not the same as a page that reads.