# The Deterministic Integration Layer Is Being Built From Both Ends

**Published:** 2026-09-02  
**Author:** Kin Lane  
**Canonical:** https://apievangelist.com/2026/09/02/the-deterministic-integration-layer-is-being-built-from-both-ends/

My post arguing that [agents should write code to integrate, not infer it at runtime](https://apievangelist.com/2026/09/01/agents-should-write-code-to-integrate-not-infer/) got a lot of agreement, which is pleasant and not very useful. Two of the responses were useful, and both came from vendors who have been living in this problem for years — Adam Altman at [Redocly](https://redocly.com) and S. Adeel Ali at [APIMATIC](https://www.apimatic.io). Adam builds documentation and contract tooling. Adeel builds SDK generators. They came at my argument from opposite ends and landed on the same correction, which is the part worth writing down: I said let the agent write the integration code, and both of them said, in their own way, do not let the agent decide the *shape* of the integration at all.

Adam's version is a pipeline, and it is refreshingly specific. Take the OpenAPI, optionally bundle it through the `filter-in` decorator to extract only the operations you actually care about, generate a typed TypeScript client or a CLI client and docs with [`redocly generate-client`](https://redocly.com/docs/cli/commands/generate-client), then instruct the agent that it may only use that tool. Adam applies this even to ad hoc and non-production work, which is the part I would have skipped. Read what that generated client actually carries: no runtime dependencies, one async function per operation, auth for every scheme the description declares, opt-in retries, timeouts, middleware, pagination iterators, typed server-sent events. That is the entire category of work nobody writes correctly at two in the morning, and it comes out of a generator that produces the same thing every time you run it. The determinism has moved one layer earlier than I put it. In my framing the agent is the author and the code is the deterministic artifact. In Adam's, the *generator* is the deterministic thing, and the agent never authors the client at all — it just calls a small, scoped, typed surface that a compiler will yell about.

The `filter-in` step is the part I keep turning over. Scoping an OpenAPI down to a handful of operations before you generate is nominally a build convenience. What it is really doing is bounding the surface the agent is allowed to reason about. Hand an agent a client with nine hundred operations and you have quietly handed the inference problem back to it — now it is guessing which of nine hundred functions to call, which is a smaller guess than parsing a raw HTTP response but the same species of guess. Filter down to the six operations the workflow needs and the guessing mostly stops. That is a governance move wearing a build-tooling costume, and I do not think the agent tooling world has noticed yet that surface reduction is the safety mechanism.

Adeel came at it from the other end, which is measurement, and his post [*A Working API Call Is Not a Production-Ready Integration*](https://www.apimatic.io/blog/working-api-call-is-not-production-ready-integration) is the empirical companion to the thing I asserted. He benchmarked what coding agents actually produce when you point them at an API and let them work. They get to a working call. They also burn fifty-plus probe calls reverse-engineering the API through guesswork and web searches, hard-code endpoint paths and auth headers into the implementation, couple the design to whatever they inferred about the API's internals, and stop the moment something returns a 200. The diagnosis is the sharpest line in the post: the agent has no definition of done beyond *it worked once*. Rate limits, timeouts, retries, idempotency, pagination, enum validation, malformed JSON, schema drift — none of those are in scope for an agent whose success criterion is a successful response. With the API's real context supplied up front, his readiness scores went from 74 to 97 and the agents wrote hundreds more lines of test code per run. Same model, same task, different definition of done.

Put the two together and they are the same correction from opposite directions. Adam removes the decision by generating the client, so the agent never gets to invent an integration shape. Adeel supplies the definition of done, so when the agent does write code it knows what production actually requires. Both are compensating for the same defect, which is that the authoring step in my original argument is *itself* an act of inference. I moved the nondeterminism from runtime to authoring time and declared victory, and authoring-time nondeterminism is genuinely better — it happens once, you can review it, your tests pin it — but "you can review it" is doing a lot of load-bearing work in that sentence, and most teams will not review a four-hundred-line generated integration with the care they would give a pull request from a colleague. Shrinking what the agent gets to invent is the more honest fix than promising to review harder.

Here is where I think it actually gets hard, and where neither vendor's answer is finished yet: everything above is a single-provider story. One OpenAPI, one generator, one typed client, one filtered surface. That is the tractable half. The integrations that matter in most businesses span five or eight providers, and the seam between them is where the work lives — five auth models, five pagination idioms, five error taxonomies, five opinions about what idempotency means, and a mapping layer that turns one provider's customer into another provider's contact. No generator emits that. Generate all the clients you want and you still have an unspecified, hand-written, agent-inferred layer sitting on top of them doing the part that actually encodes your business. [Arazzo](https://spec.openapis.org/arazzo/latest.html) is the only specification I know of pointed squarely at that seam, describing multi-step workflows across operations as a contract rather than as prose, and it is still early and thinly adopted. If the single-provider client is becoming a generated artifact, then the multi-provider workflow is the next thing that has to become one, and the agent's real job moves up a layer — not writing the HTTP call, writing the seam. I would rather see that seam expressed as a declared workflow an agent fills in than as bespoke glue an agent invents fresh in every codebase.

Which brings me to the question Adeel puts to API providers, and it is the one I would tattoo on the industry: if a coding agent had access to nothing but what you publish today, would it produce an integration you would be willing to support? Notice that both of these pipelines — Adam's and Adeel's — begin at a real, complete, machine-readable contract. That is the input. Running the [APIs.io](https://apis.io) catalog is a daily reminder of how few providers supply one worth generating from, and how many of the OpenAPIs that do exist are partial, stale, untagged, missing security schemes, or reverse-engineered by a third party rather than published by the company whose name is on them. Every argument in this post is downstream of that. The deterministic integration layer people are building right now — generated clients, scoped surfaces, supplied context, workflow contracts — is only as good as the contract at the bottom of it, and for most of the API landscape there is no contract at the bottom of it at all. Agents will integrate with those APIs anyway. They will just do it by guessing, and the guess will look like it worked.

So the direction I now see is not inference leaving the stack. It is inference moving up it, one layer at a time, as each layer below gets a contract and a generator. Runtime response parsing was the first thing to fall, and my last post was about that. The client itself is falling now, to Adam's generator. The definition of done is falling, to Adeel's context. The multi-provider seam is the next one on the block and nobody has taken it yet. What is left for the agent at the top, after all of that, is the genuinely ambiguous work — what does this business want, which of these providers, what should happen when the thing that should not happen happens. That is the work I actually want a model doing. Everything under it should be code that runs the same way every time, and increasingly it should be code we generated rather than code anybody wrote.