In this article
An AI agent can write a working integration at runtime, but only in the narrow conditions where no one has to trust the result. When a user asks for a connection and the agent reads the docs, generates the client code, and makes a call, that loop works for a one-off data pull, an internal prototype, or anywhere a human reviews the output before it matters. It breaks the moment the integration has to live inside a customer-facing product, where someone else's account, someone else's data, and your audit trail are on the line. This article separates the two cases honestly, because the gap between them is where most "the agent will just build it" plans fail.
Albato Embedded is a white-label embedded iPaaS that gives SaaS companies a runtime layer of 1,000+ maintained connectors their AI agents can call instead of generate. The distinction matters: generating an integration on demand is a coding task with no owner, while calling a ready action is a predictable operation someone already maintains. This guide is written for product and engineering leaders evaluating "just-in-time integrations" as a strategy, not a demo.
Key takeaways:
- Agent-generated integrations at runtime work for one-off pulls, internal prototypes, and human-in-the-loop flows where a person reviews output before it counts.
- They break in customer-facing products on account ownership, OAuth, code ownership after launch, idempotency, auditability, and context cost.
- A Stripe benchmark published in March 2026 found frontier coding models scored around 92% on full-stack integration tasks but failed most on validating whether their own code actually worked.
- The reliable pattern is an agent that calls maintained actions through a runtime layer, not one that writes integration code live. Albato Embedded provides that layer with virtual keys that keep tokens out of the prompt.
What "just-in-time integrations" means
Just-in-time integrations are integrations an AI agent writes at runtime, on demand, instead of connectors a team builds ahead of time. The term was coined by Nango to describe a pattern where a user types what they want into a prompt box, the agent reads the target API's documentation, generates the integration code, and a human reviews it before it runs. It matters because it promises to collapse weeks of connector work into a single request. It differs from a traditional connector in one critical way: no one maintains the generated code, because it did not exist until the moment it was asked for.
That is the honest definition, and it sets up the real question. The pattern is not fake. Open-source tools like Superglue let an agent translate between APIs at runtime, and the approach genuinely removes build time for throwaway work. The disagreement is not about whether an agent can produce integration code. It can. The disagreement is about what happens to that code, and to the user's data, after the agent moves on.
Where runtime agent-generated integrations already work
Agent-generated integrations work well wherever the output is disposable, private, or checked by a human before it counts. In these cases, the lack of a maintainer is not a problem, because nothing depends on the integration surviving past the task in front of it.
Three situations fit cleanly:
- One-off data pulls. You need to grab records from an API once, reshape them, and move on. An agent can write that script, run it, and the code can disappear afterward. No one has to own what never ships.
- Internal prototypes. An engineer explores whether an integration is feasible. The agent scaffolds a rough version against test credentials, the team learns what they needed to learn, and the prototype gets rewritten or thrown away before any customer touches it.
- Human-in-the-loop flows. A person sits between the agent and execution. The agent drafts the integration or the action, a reviewer approves it, and only then does it run. The human carries the judgment the model lacks.
The common thread is accountability. In each case, either the result does not matter past one use, or a person is responsible for checking it. That is exactly the setup the Nango pattern describes: the agent writes, the human reviews. For personal productivity or an engineer's own exploration, this is a real productivity gain, and dismissing it would be wrong.
Where it breaks in a customer-facing product
Runtime agent-generated integrations break the moment the integration runs inside your product, for your customers, without a human checking each one. The conditions that made the pattern safe (disposable output, private scope, a reviewer) all disappear at the same time. What is left is generated code touching a stranger's account with no one accountable for it.
Here is where the pattern falls apart in production:
- Whose account and whose OAuth. When your agent connects to a customer's CRM, it acts on that customer's account under their OAuth grant. The agent did not design your consent flow, your token storage, or your refresh logic. Generating a connector on the fly does not solve who holds the credentials or what happens when a grant is revoked. Credential handling is its own discipline, which we cover in AI agent security for SaaS.
- Who owns the generated code a month later. The agent writes the integration today and moves on. When the third-party API changes a field next month, there is no connector in your codebase to patch, no owner, and no test suite. The code that looked finished in the demo is now an orphan touching live customer data.
- Idempotency and retries. Real integrations duplicate events, drop them, or deliver them out of order. Generated-on-demand code rarely builds the idempotency keys, dead-letter queues, and backoff logic that keep a dropped webhook from silently losing a record. The agent optimizes for a working call, not for what happens on the second, failed, or replayed call.
- Audit of actions. In a customer-facing product you must answer which action touched which record, for which customer, and when. Code generated at runtime leaves no stable, reviewable trail unless something outside the agent records it.
- Context cost. Handing an agent enough API documentation to generate a correct integration bloats its context, which degrades its reasoning and raises the odds it hallucinates a field or an endpoint. We break this failure mode down in how too many MCPs break your AI agent.
None of these are edge cases. They are the default conditions of any integration that ships to real users, and they are precisely the parts an agent writing code at runtime is worst at. Mapped onto a single surface, the six failure modes look like this.
What the benchmark data actually shows
The best public evidence on agent-written integrations comes from Stripe, not from a vendor selling the pattern. In March 2026, Stripe's API Standards team published a benchmark testing whether AI agents can build real Stripe integrations across 11 reproducible environments spanning backend, frontend, and browser-based checkout flows. Carol Liang and Kevin Ho ran frontier models through full integration tasks, not toy snippets.
The headline numbers look strong until you read the failures. Frontier coding models scored around 92% on full-stack API tasks and about 73% on the harder problem sets. The telling part is how they failed. In one common mode, an agent saw an error response, treated it as success, and never validated the result, so the integration looked done while it was quietly broken. In another, the agent got stuck inside a browser flow it could not recover from.
The limit the Stripe benchmark exposed is not code generation. Frontier models write plausible integration code quickly. What they do unreliably is confirm that the code produced the right result in a live, stateful system, and recover when a step fails. A customer-facing integration demands exactly that validation and recovery, which is why code that passes a demo can fail in week three when real accounts and real state expose the gaps the model never checked. An InfoQ recap in July 2026 framed the same finding as a validation gap, not a generation gap.
This is the structural reason the pattern breaks in production. The failure is not that the agent cannot write code. It is that writing code is the easy half, and the half the model is weakest at is exactly the half a shipped integration lives or dies on.
Generate on the fly vs call a maintained connector
The choice is not "agents or no agents." It is whether your agent generates integration code at runtime or calls an action someone already maintains. The table below compares the two across the criteria that decide reliability in production.
| Criterion | Agent generates at runtime | Agent calls a maintained connector |
|---|---|---|
| Reliability | Varies per run; depends on the model validating its own output, which benchmarks show it does poorly | Consistent; the action is tested and versioned before the agent ever calls it |
| OAuth ownership | Undefined; the agent must improvise consent, storage, and refresh per customer | Handled by the platform; white-label OAuth and per-user credentials are built in |
| Auditability | No stable trail unless something external records each generated run | Every action logged with permissions and full action auditing |
| Maintenance | No owner; when the third-party API changes, the generated code silently breaks | The platform updates connectors when third-party APIs change |
| Latency | High; the agent reads docs and writes code before it can act | Low; the action is a direct call with no generation step |
| Context cost | Heavy; full API docs loaded into context risk bloat and hallucination | Light; the agent sees a standardized action, not raw documentation |
The pattern that scales is on the right. The agent still makes the decision about what to do. It just does not have to invent the plumbing to do it. The same decision, drawn as two runtime paths, makes the ownership difference concrete.
The runtime layer agents should call, not generate
The reliable architecture gives the agent a layer of ready, maintained actions to call, and keeps code generation out of the live path entirely. The agent reasons about the task. The runtime layer carries out the action against the right account, with credentials the agent never sees. This is where an embedded iPaaS fits an agentic product.
Albato Embedded is a white-label integration platform that exposes 1,000+ apps as actions an AI agent can call through a single MCP endpoint. The agent does not read a target API's documentation or write a connector. It calls a standardized action, and Albato runs it against the customer's connected account. This is the difference between an agent that calls HubSpot, Slack, Notion, or Stripe through a maintained connector and one that tries to write that connector live.
The security model is the part that makes this safe for a customer-facing product. With Albato's Secure Credential Proxy, tokens never enter the prompt or reach the model. The agent works with a credential ID, and Albato holds the actual tokens. Albato Embedded is also model-agnostic, so each workflow can run on OpenAI, Anthropic, the partner's own model, or the built-in Albato AI, whose underlying model is proprietary and not disclosed. The agent gains breadth across 1,000+ apps without any individual API keys or schemas to manage.
This complements, rather than replaces, the broader question of embedding agents that take action in your product, which we cover in how to embed AI agents that act in your SaaS product. The point specific to just-in-time integrations is narrow: let the agent decide, and let a maintained layer act. Seeing that runtime layer resolve a real connector call is usually faster than reasoning about it in the abstract.
When agent-generated integrations are the right call
Agent-generated integrations are the right call when the output is disposable or a human owns the result. If you are pulling data once, prototyping internally, or running a flow where a reviewer approves every integration before it executes, writing code at runtime is a genuine shortcut and you should use it. The absence of a maintainer is fine, because nothing depends on the code surviving.
Choose a runtime layer of maintained actions when the integration ships to customers, runs without a human in the loop, or touches accounts you do not control. At that point you need predictable reliability, defined OAuth ownership, a clear audit trail, and a maintainer for the day a third-party API changes. That is a platform decision, not a generation task. For the dev-time version of this same tradeoff, where your engineers build connectors with AI coding tools rather than an agent generating them at runtime, see building SaaS integrations with AI coding tools.
Frequently asked questions
Can an AI agent write an API integration on the fly?
Yes, an agent can read an API's documentation and generate working integration code at runtime. It does this reliably for one-off pulls, internal prototypes, and flows where a human reviews the output. It does it unreliably for customer-facing integrations that need defined account ownership, auditing, and a maintainer after launch.
What are just-in-time integrations?
Just-in-time integrations are integrations an AI agent generates at runtime in response to a user request, instead of connectors a team builds in advance. The term was coined by Nango. The core limitation is that no one maintains code that did not exist until it was requested, so it breaks when a third-party API changes.
Why do agent-generated integrations break in production?
They break because generating code is the easy half and validating that the code worked in a live system is the half models do poorly. A Stripe benchmark found agents often mistook an error for success and never checked the result. In a customer-facing product that gap shows up as silent data loss, broken OAuth, and no audit trail.
Is it safer for an agent to call a connector than to write one?
Yes. Calling a maintained connector gives you tested, versioned actions, built-in OAuth, full auditing, and an owner who patches the connector when the API changes. With Albato Embedded, the agent calls actions through an MCP endpoint and never sees the underlying tokens, which the Secure Credential Proxy holds.
Does Albato Embedded generate integrations with AI?
No. Albato Embedded gives agents 1,000+ maintained connectors to call, not code to generate. The agent decides what to do and Albato runs the action against the customer's connected account, keeping credentials out of the prompt. Agents are model-agnostic and can run on OpenAI, Anthropic, a partner's own model, or built-in Albato AI.
The bottom line
Agent-generated integrations are a real capability with a narrow safe zone. For disposable work and human-reviewed flows, letting an agent write an integration at runtime is a genuine productivity gain. For anything that ships to customers, the pattern inherits every hard problem of production integrations (account ownership, OAuth, idempotency, auditing, maintenance) and solves none of them, because the generated code has no owner the moment the agent moves on.
The architecture that holds up gives the agent judgment and gives a runtime layer the work. Let the model decide what to do. Let a maintained platform carry out the action against the right account, with tokens it never sees. That split is what turns an impressive demo into something you can put in front of real users.
If you are designing an agentic feature and weighing "the agent will just build it" against a maintained runtime layer, a short walkthrough is usually faster than another architecture doc. We'll show how Albato Embedded gives your agents 1,000+ actions to call, with credentials held at the proxy.
