Forgiving APIs Are a Hazard Now: Interface Design Is Becoming a Governance Surface

On July 9, 2026, Ben Swerdlow, founder and CEO of Freestyle, published four design principles for agent-facing APIs. Every one of them contradicts advice that has governed interface design for decades: require every field, refuse to coerce malformed input, avoid generic names like name, and expose fewer conveniences rather than more. Read together, the four principles form an audit checklist disguised as API advice.

The doctrine they invert was built for a specific consumer. A human integrator reads documentation once, writes the client by hand, and debugs by stepping through code. For that consumer, forgiveness was kindness. Optional fields with sensible defaults meant faster onboarding. Silently coercing "5" into 5 meant fewer support tickets. A tolerant API was a polite API, and Postel’s law (“be liberal in what you accept”) was the professional consensus.

Agents changed the consumer, and with it the cost structure of every one of those kindnesses. An agent does not read the docs once; it regenerates its understanding of your interface on every call. It does not debug by stepping through code; it retries with variations until something passes. Every place your API quietly fills in, coerces, or guesses is a place where behavior happens that nobody requested and nobody can reconstruct later. Forgiveness became the exact surface where agent behavior turns unobservable.

A Default Is a Decision Nobody Made

Swerdlow’s first principle is the bluntest: require every field. His rationale is economic. Verbosity is cheap for agents and debugging is expensive. A human integrator facing twelve required fields feels friction. An agent generating twelve explicit values spends microseconds.

The governance reading is stronger than the economic one. An optional field with a default is a decision made by the vendor at design time, invisible in the request log. When something goes wrong and the review asks “why did the system charge in USD,” an explicit currency field answers from the request payload alone. A defaulted one requires archaeology: which API version, which default, which deploy. Requiring the field moves the decision into the request itself, where it is captured and diffable across runs.

That is the general form of the shift. What the interface forces to be explicit is what the audit trail contains.

Errors That Teach Beat Tolerance That Hides

The second principle: return precise, instructive errors instead of silently coercing bad input. Swerdlow’s argument is that tolerance creates inconsistency. The same agent sends a quoted number on Monday and a bare one on Wednesday; both pass, each coerced through a different code path, and the two runs are no longer comparable. Multiply by thousands of calls per hour and your logs describe traffic that never happened as written.

An instructive error does two jobs at once. It is a feedback loop the agent can act on immediately: “expected integer for retries, got string” is a correction the model applies on the next attempt. And it is an observability record. A rejected request with a precise reason is evidence you can review. A coerced request is a silent rewrite of history.

Specific Names Are a Defense Against Hallucination

Third: name fields for what they are. displayName, externalId, slug. Never a bare name. The reasoning here is specific to how models fail. An agent that has seen ten thousand APIs during training will pattern-match an ambiguous field to whichever system it resembles most. name could be a username, a display label, or a unique key, and the agent’s guess will be plausible enough to pass validation while carrying another system’s semantics into your database.

Specificity pins the meaning to the field itself, so the interface carries its own contract. This is cheap insurance. Renaming a field costs a migration. An agent writing the wrong semantics into production costs an incident review.

Expose Facts, Skip the Conveniences

The fourth principle draws the line on scope. An agent API should expose core capabilities, the facts and state changes of your domain: a bill was paid, a message was sent, a VM was provisioned. Convenience wrappers that bundle multi-step flows duplicate work that your documentation and the agent’s own reasoning already do, and each wrapper is another opaque path where steps happen out of view.

Freestyle applies this to its own platform with direct exec capabilities instead of a high-level package system. The agent composes the steps; the API records each one. The composition lives in the agent’s visible reasoning rather than inside a vendor’s convenience layer, which means the trace of what happened is complete by construction.

The SDK Layer Is Under the Same Pressure

The same logic is now being argued one layer up. A thread on X, summarized by TLDR, argues that AI has made tailored REST clients as cheap to produce as SDK integrations, and that companies will increasingly ship agent skills that teach agents the raw HTTP API instead of shipping SDKs at all. As described in the newsletter summary, the claimed payoff is unified observability: every call the agent makes goes through your HTTP layer, where you already log and trace requests.

Treat those specifics as unverified. The direction, though, matches what we have already documented from the vendor side. OpenAI’s Agents SDK shipped without governance surfaces, and the framework layer is where vendors are betting governance will live. Those pieces asked what the vendor did not build. This one is about what you build. An opaque client library and a forgiving endpoint fail the same way: both move behavior out of the channel you can inspect.

Explicitness Is the Control

Put the four principles together and they describe one property: an interface where nothing happens implicitly. Every value arrives because something sent it. Every rejection states a reason. Fields mean exactly one thing each, and each state change maps to one recorded call. That property has a governance name: auditability. The request log becomes a complete record of intent, and a complete record of intent is the input every incident review and compliance check actually needs.

This inverts how most teams currently think about developer experience for agents. The instinct is to make the API easier and more tolerant, because that is what worked for humans. For agent consumers, the well-designed interface is the strict one, because strictness is what makes ten thousand autonomous calls per hour reviewable by the humans who answer for them.

Run This Review This Week

Take one API that agents call today, internal or external, and walk it against four questions:

1. Which fields are optional? For each one, ask who decided the default and whether that decision appears anywhere in your logs. Promote to required any field whose answer would matter in an incident.
2. Where do you coerce? Find every silent type conversion, trim, and normalization. Replace each with a 400 and an error message a model can act on.
3. Which field names could belong to another system? name, id, type, status with no qualifier. Rename toward specificity in your next version.
4. Which endpoints are conveniences? If an endpoint exists to save a human three calls, decide deliberately whether agents should use it, because the steps it hides are steps missing from your trace.

An hour of this produces your first agent-interface audit. The teams that treat interface design as a governance surface will know what their agents did. The teams that keep shipping forgiveness will find out during the incident.

---

This analysis synthesizes Designing APIs for Agents (Freestyle, July 2026).

Victorino Group helps engineering organizations redesign agent-facing interfaces so every agent action is explicit and auditable. Let’s talk.