Why I Bet On Building an Integrations Platform Before Features

4 MINS

When we kicked off the AI Agent integrations work at Cisco, the obvious path was to ship a few hand-built integrations to the loudest customer asks — Salesforce, ServiceNow, the usual suspects. We didn't. We spent the first cycle building a platform that lets developers create pre-built actions on top of third-party systems. It was the slower-looking choice. It turned out to be the faster one.

The "ship one more integration" trap

Every AI agent product I've seen falls into the same gravity well: a customer asks for an integration, the team builds it, the next customer asks for a different one, and within a year you have 14 bespoke integrations that nobody on the team fully owns.

That model breaks at scale. Each new integration takes about a week of engineering effort, and worse, each one ages independently. You wake up one morning to find five of them broken because a vendor changed an auth flow.

The platform bet is essentially: pay the upfront cost once, and turn integrations into a multiplication problem instead of an addition one.

The LLM unlock

The breakthrough wasn't the platform itself. It was the moment we realised that an LLM pipeline could automate action configuration. What used to be a week of engineering — reading API docs, mapping fields, writing the action handler — became roughly two hours.

That's a 20x speedup. It's the difference between an integrations team and an integrations factory. Once that pipeline existed, our calculus shifted entirely:

Coverage became cheap. Adding the long tail of niche integrations was suddenly viable.

Deprecation became cheap. We could regenerate an action when an API changed instead of patching it by hand.

Partner-led integrations became possible. Third parties could plug in without our team being a bottleneck.

The product question hidden inside

What I didn't expect was how much this work would expose a deeper product question: what is an "action," really? Is it a literal API call? A user-intent the agent fulfils? A reusable building block other agents can compose?

We wrestled with this for weeks. The eventual answer — that an action is a *contract*, defined by inputs and outputs and guardrails — turned out to be the design choice that made the rest of the system coherent.

That decision is the one I'd tell anyone copying this approach to make first. Not what tech to use. Not which model. The contract.

What I'd repeat next time

If I were starting from scratch:

Define the action contract on day one. Don't let it emerge from the first integration; design it as the first thing.

Build the LLM pipeline before the third integration, not after the tenth. The pain doesn't get smaller with scale, it just gets more expensive to fix.

Treat "actions added per week" as your North Star. It captures both the platform's leverage and the business outcome cleanly. Platforms feel slow. They're not — they're just compounding. The first month is the hardest. Month six is when the curve flips.

The Real Bottleneck in Digital Lending Isn't Technology

Shivani skipped presentations and built real AI products.

Shivani Kolala was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.