How we connect AI agents to the tools a business already uses

Before writing extraction logic or choosing a model, we work out how the automation will talk to the systems that already hold the data. This is usually where a project's real difficulty lives.

Check for a real API first

A documented API with authentication, pagination, and rate limits is the best case. We read the rate limits before designing anything, because a limit of 60 requests per minute changes the architecture of a high-volume process.

The questions that matter:

• Does it support the write operations we need, or only reads?
• Are there sandbox credentials, or are we testing against production?
• What happens on a partial failure mid-batch?

Prefer webhooks to polling

Polling a system every minute for changes is simple and often wrong. It burns rate limit, misses the exact order of events, and makes near real-time behavior expensive.

Where the platform supports webhooks, we subscribe and verify signatures. Where it does not, we poll on a schedule sized to the business need, not to our impatience.

Assume the system of record stays the system of record

A common failure mode is building automation with its own private version of the truth. Then a customer updates their address in the CRM and the automation keeps using the old one.

Our default is that the existing platform remains the source of truth. The automation reads from it, writes back to it, and keeps local state only for what the platform cannot hold, such as processing status and audit history.

Handle the platforms that only speak email

Plenty of small business software has no API. The interface is a person receiving an email and typing into a screen.

There are three options, in order of preference:

1. A supported import path. Many systems accept a CSV or a structured email template. Ugly, stable, and supported by the vendor.
2. Browser automation against the vendor's own interface. Effective but brittle. We only use it with explicit permission, a change-detection alert, and a manual fallback.
3. A person keeps the last step. The automation prepares everything and a human pastes it in. This is a legitimate end state, not a failure.

We say no to writing directly into an undocumented database that belongs to a vendor. It breaks on their next release and it is not our data.

Model the data once

Integrations get expensive when every system is treated separately. We define a single internal shape for the core objects, such as a customer, an order, or a request, and write one adapter per external system.

When a new platform is added, the work is a new adapter rather than a new pipeline. This is the difference between adding a system in two days and in three weeks.

Test with production-shaped data

Integration bugs come from real payloads: the empty optional field, the customer name with an ampersand, the timestamp in a local timezone, the 4,000-character note field.

We keep a redacted library of real payloads and run every adapter against it before go-live. Synthetic test data passes too easily.

What we tell clients up front

Integration work is usually 60 to 80% of the effort in an automation project, and it is the part that does not demo well. It is also the part that decides whether the system still works in six months. Budget for it honestly and the rest of the project gets much easier.