API modernisation for agents: build, buy, or wait

Your APIs can't support what your agents need to do. You know this. The question you're actually trying to answer is: what do we do about it?

There are three real options. Each is the right answer in specific circumstances. None is right for everyone. This guide works through each honestly — what it costs, how long it takes, and what it leaves unsolved.

The context: why you're choosing now

The choice is urgent because the gap between your API surface and what your agents need is blocking an agent project that has already started. This isn't a theoretical architecture decision — it's a live problem with a timeline attached.

That context matters for evaluating the options. An option that's architecturally correct but takes 18 months to produce working agents is a different risk profile than an option that's less clean but delivers capability in six weeks.

Option 1: Rebuild the API layer

Build the API surface your agents need from scratch. Expose every workflow, every permission check, every piece of business logic that currently lives only in the UI layer. Make the full product surface callable.

What it costs: This is a multi-year project for any product of meaningful complexity. Estimates from teams who've priced it range from two to five years of engineering time, competing directly with the product roadmap. The work is foundational — it touches auth, validation, business logic, and data models across every product in the portfolio.

What it delivers: A clean, well-designed API surface that agents can use reliably, that's maintainable long-term, and that can also serve other use cases (partner integrations, customer-facing APIs, future products). The architectural benefit is real and lasting.

What it leaves unsolved: The agent project is blocked for the duration of the rebuild. In a two-to-five-year window, the agent ecosystem will have evolved significantly. You may be rebuilding for requirements that look different when you finish.

When it's the right answer: When leadership is willing to fund it, when the product is early enough that the rebuild can happen alongside initial development rather than against accumulated legacy, and when there's no agent project urgency that can't wait. This describes few established SaaS companies.

Option 2: Build bespoke connectors product by product

For each product in the portfolio, build a connector: a thin layer that wraps the existing codebase and exposes the specific capabilities the agent project needs. Don't rebuild the API; wrap it.

What it costs: The build cost per product is lower than a full rebuild — typically two to four weeks per product for the initial connector. The real cost is in maintenance. Each connector is a dependency on the shape of the underlying product. When the product changes, the connector needs updating. Across a portfolio of ten products, each changing at the pace of an active development team, maintenance becomes a significant ongoing engineering commitment.

What it delivers: Agent capability faster than a full rebuild, with a narrower scope. You can ship agent access for the first two or three products in months rather than years.

What it leaves unsolved: The bespoke approach doesn't compound. Each connector is an independent artefact. The work on connector one doesn't reduce the cost of connector ten. The maintenance burden grows linearly with the number of products and the rate of change. Teams that pursue this approach often find that by the time they've shipped connectors for their full portfolio, the first connectors need significant rework.

When it's the right answer: When the portfolio is small (two to three products), when the products are relatively stable, and when the agent use case is narrow enough that the connector surface stays manageable. It's also a reasonable starting point if you need to demonstrate agent capability quickly and plan to migrate to a more systematic approach.

Option 3: Use a generation and runtime platform

Use a platform that generates tool definitions from the existing codebase, maintains them as the product changes, and runs them through a managed runtime. You don't rebuild the API and you don't write bespoke connectors — you onboard to a platform that handles the generation, maintenance, and execution.

What it costs: There's a platform cost (licensing or subscription), an onboarding investment, and a dependency on a third-party vendor. The onboarding investment is lower than either of the first two options; the ongoing cost is predictable rather than scaling with the number of products or the rate of change.

What it delivers: Agent capability faster than either alternative, with lower ongoing maintenance burden. The generation layer handles new products at lower marginal cost than bespoke connectors. The managed runtime handles auth, rate limiting, failure handling, and observability without requiring per-product engineering work.

What it leaves unsolved: Vendor dependency is a real concern. The right questions to ask: what happens if the vendor is acquired or shuts down? Can you export the generated tool definitions and run them independently? Is the tool generation output portable? These questions don't have universal answers — they depend on the specific vendor and contract.

When it's the right answer: When the portfolio is large or heterogeneous, when engineering capacity for bespoke connector work is constrained, and when the agent project has a timeline that doesn't accommodate multi-year infrastructure work. For most established B2B SaaS companies actively building agents, this is the option that fits.

The honest trade-off matrix

Making the decision

The decision framework is simpler than it looks:

If you have two to three products, a stable codebase, and six months of runway before the agent project needs to ship — bespoke connectors are viable. Track the maintenance cost carefully from the start so you can make the migration decision before it becomes a crisis.

If you have five or more products, a heterogeneous tech stack, or an agent project timeline measured in weeks rather than months — the generation platform option is worth evaluating seriously. The vendor risk questions are worth asking, but so is the alternative: what does five years of bespoke connector maintenance cost, and what doesn't get built while that work is happening?

If you have the engineering capacity, the time, and leadership commitment for a full rebuild — do it. The architectural benefit is real. But be honest about whether those conditions actually exist.