Connecting an agent to a single system through a documented API — a CRM, say — is usually a few days of engineering work. What actually stretches a project into weeks is the number of systems you're connecting, the quality and availability of their interfaces, and whether the data the agent needs to work with is organized in the first place.
What "integration time" is really made of
When a client asks "how long will this take," they usually mean the time spent writing code. In practice, that's only one of four components:
- Engineering time — designing and writing the code that connects the agent to a given system's API.
- Access wait time — API keys, IT approvals, test accounts. This stage can outlast the code itself, especially at companies with a formal access-approval process.
- Testing time on real data — checking that the integration works correctly not just on a sample, but on real traffic with its irregularities.
- Edge-case handling time — situations where data is incomplete, the format varies, or the source system responds late or with an error.
What actually stretches out integration
- The number of systems involved. Every additional system doesn't just add complexity — it multiplies it, since you have to think through how data from one affects the other.
- The quality of the vendor's API documentation. Well-documented, widely used APIs (typical modern SaaS) move fast. Poorly documented or rarely used endpoints require trial-and-error.
- No REST API on the source system's side. If the only way data leaves a system is a manual CSV export or a click-through interface with no API, integration stops being a matter of days — you need to build an extra intermediary layer.
- Internal security processes and IT approvals. In regulated industries (finance, healthcare), the approval process for system access alone can take longer than the integration itself.
- Source-data quality. Data that's scattered, inconsistently labeled, or needs manual cleaning before use requires an added normalization step before the agent can work with it at all.
What actually shortens integration
- A modern SaaS system with well-documented REST APIs and webhook support.
- A dedicated point of contact on the client side with authority to grant access quickly.
- A clearly defined, narrow scope carried straight over from the prototype stage — no ambiguity about what data actually needs to flow between systems.
- Prior experience on the implementation team's side with that particular type of system (a specific CRM, say), which skips the discovery phase entirely.
A rough sense of scale
Without a fixed price list or a fictional timeline, it helps to have a general sense of order of magnitude:
| Complexity | Characteristics | Rough scale |
|---|---|---|
| Simple | One system, good REST API, data already organized | Days |
| Medium | 2–3 systems, some requiring extra access configuration | Weeks |
| Complex | 4+ systems, including legacy systems without a modern API, regulated industry | Weeks to months |
These are general ranges, not a promise for any specific case — real timelines always depend on the combination of factors above, which is why we only set a quote and timeline after a conversation about your actual systems.
How to prepare to speed things up
Part of integration time sits with the implementation team, but part depends entirely on client preparation — and that second part is usually the easiest to shorten at no extra cost. Before the first integration conversation, it helps to have a list ready of the systems that need connecting, along with whether each has API documentation and who in the company can reach it. It's also worth working out ahead of time who can grant test access quickly — if that approval only gets requested once work is underway, it's usually the actual bottleneck, not the code itself.
The second piece of prep is clarity on which data actually needs to move between systems. The technical team can propose an approach, but the client knows best which fields are critical and which are optional — and settling that before integration starts, rather than mid-build, removes one of the most common causes of slippage.
Questions worth asking an integration vendor
- Do you quote before or after checking our systems' API documentation?
- What happens if it turns out mid-build that a system is missing an endpoint you need?
- Who on your side handles testing against real, not just sample, data?
- How are cases handled where the source system returns an error or incomplete data?
If you're still ahead of integration and wondering how the prototype stage that precedes it works, read What an AI Proof of Concept Looks Like Before You Commit to a Full Build. If you're still assessing whether your company is even ready for this stage, check Checklist: Is Your Company Ready for Its First AI Implementation. More on our process on the Orkestra Labs homepage.