Every integration used to be an engineering project.
Read the docs, handle auth, deal with pagination, write error handling, test, ship, debug, and maintain. Teams treated integrations as roadmap items and prioritized ruthlessly: Even a very large org might only have budget for 3-5 integrations a quarter.
AI coding agents are now good enough that this is changing rapidly.
They can read API docs, iterate, and produce a working integration more or less autonomously. With the right tooling, building and maintaining integrations is now 10x easier.
But we have seen some teams go even further: They generate integrations on the fly, as their customers request them in the product.
We call these just-in-time (JIT) integrations.
What are just-in-time integrations?
Just-in-time integrations are built when your customers need them. For example, a Salesforce integration tailored to your customer's schema and custom objects.
The most common implementation right now is a prompt box where the customer describes what they want the agent to do. If required, the agent will build a new tool to enable their use case.
Console, an AI-native IT helpdesk, recently published a demo of their implementation.
What changes with just-in-time integrations?
It turns out, quite a lot.
From integration to factory
The traditional model is to build each integration individually: Scope it, assign an engineer, ship it.
With JIT, the work shifts from building individual integrations to building the system that produces them. You stop building integrations one by one and start building the factory that can generate any integration on demand.
The marginal cost of one more integration drops to near zero
Once the factory is in place, adding the next integration is almost free.
That makes it realistic to cover hundreds of APIs instead of just the top 20. And because each integration can be generated fresh for a specific customer, integrations can become hyper-custom. Instead of one Salesforce integration that every customer shares, each customer gets one that matches their specific setup with their custom objects, their fields, and their workflows.
Customers can self-serve most integrations
When the cost of building an integration drops far enough, you don't need to gate it behind a product team's prioritization.
Customers can describe what they need, and the system builds it. This doesn't work for every case yet, but for a growing number of (relatively) straightforward integrations, customers can get what they need without waiting on anyone's roadmap.
Quality goes up
Both in terms of end-user experience (every user gets exactly what they want), and technical correctness.
Improved correctness might be counterintuitive. You'd expect generated integrations to be lower quality. But today, most integrations are built once and maintained only when something breaks. They get stale as APIs evolve. With JIT, an agent can monitor API responses and exceptions continuously and improve the integration. That's closer to 24/7 maintenance than a human checking in periodically.
Just like code compiled with a just-in-time compiler, JIT integrations become better the longer they run and the more they are used.
The new bottleneck: Building the factory
If just-in-time integrations shift the work from building integrations to building the system that produces them, the question becomes: How do you build a factory that reliably produces JIT integrations?
From what we've seen, there are three key ingredients.
Build: A coding agent in a sandbox, with an integrations harness
The agent needs a controlled environment where it can write and test integration code without affecting production data.
And it needs a harness: The scaffolding, SDK, API auth, and conventions that guide how integrations are structured, tested, and deployed. Without this, every generated integration is a one-off.
Good context is another ingredient: Access to API documentation, and, ideally, examples of working integrations with that API. Just as important, it needs a way to actually test what it built against the external API, with real (or realistic) credentials and data, so it can iterate on the API requests and parameters.
Run: A secure and scalable runtime with purpose-built primitives
A generic sandbox isn't enough. Integration code has specific infrastructure needs that a general-purpose runtime doesn't solve well: managed API authentication with automatic token refresh, durable execution for syncs that run for hours across millions of records, webhook ingestion that handles traffic spikes without dropping events, rate limit handling and retries per API, and tenant isolation so one customer's integration can't affect another's.
Since the integration code is now agent-generated, the security model also changes. Isolated execution, no direct exposure to credentials, and per-run resource limits become essential.
Maintain: Observability and a robust debug loop
JIT integrations need continuous monitoring, not just at build time. That means comprehensive logging of every API interaction, detailed error messages and exception traces, and execution metrics per integration and per customer. Critically, this observability data needs to be structured so that agents, not just humans, can read it. When an integration fails at 2am, the agent should be able to inspect the API response, understand the exception, and fix the issue without waiting for an engineer to wake up. The tighter this feedback loop, the more reliable JIT integrations become over time.
The path to just-in-time integrations
Not every integration in every product will be just-in-time right away.
In practice, we see three levels:
Level 1: Manual integrations
Engineers build each integration by hand. This is how most teams have worked for years.
Level 2: AI-assisted integrations at build time
Engineers use coding agents to build integrations during the product development process. Skills and specialized harnesses enable this.
The agent does most of the work, but a human initiates and reviews it. This is where most teams using AI for integrations are today, and the gains are already massive.
Level 3: Just-in-time integrations at runtime
Integrations are generated on demand, triggered by customer requests in the product.
The developer is largely removed from the build process for individual integrations and instead focuses on the factory.
Level 2 is already practical and delivering real results. Level 3 is more experimental, but it's happening in production with some products today. As models and agent harnesses improve over the coming months, we expect this to mature quickly.
With Nango we are working on the open-source factory for just-in-time integrations. If you are already using them in your product, we would love to speak with you!
