AI Agent Integration Services

What the Work Depends On Before Anything Is Built

The integration work has dependencies that sit on your side of the line, and they shape the sequence of the work more than the engineering does. Most of them are access and ownership questions rather than technical ones, which is why they are worth settling before a tool contract is written rather than discovered halfway through it.

• A system with a programmatic interface, an account that can be granted rights within it, and a person with the authority to grant them.
• A non-production instance to build against, or an explicit decision that early work runs read-only against production because no test instance exists.
• Network access to anything not reachable from the internet: a VPN path, an allowlisted egress address, or a proxy that sits inside your network.
• The identity model. One service account for the agent, or per-user delegation so the agent inherits the rights of whoever asked. This decides how the audit log reads later.
• Somewhere for audit logs to be written and a retention period, decided by whoever will eventually be asked to produce them.
• System owners who can say what a field actually contains, because column names and real meaning drift apart in any system that has been in use for years.

The Tool Surface Is a Prompt, Not Just an API Contract

A tool definition is read by the model before it is ever called. The name, the description and the parameter schema are the only information available when the model decides whether this tool is the right one for the request in front of it, so they do double duty as an interface contract and as instructions. Two tools whose descriptions overlap produce wrong selections that look like model failures and are actually naming failures.

The schema is also where a whole class of silent errors is prevented. A parameter typed as an enum of six known values cannot be filled with a plausible invention; the same parameter as free text can, and the result is an empty response rather than a rejected call, which is much harder to notice.

• Name tools for the operation and the object rather than the outcome, so add_invoice_note and update_invoice cannot be confused by description alone.
• Constrain what can be constrained: enums for status values, an explicit format for dates, a bounded range for result limits.
• Take identifiers, not labels. A tool that accepts a customer name will be given one, and the ambiguity then lands in your matching logic where it has to be resolved.
• Return failures as structured results the model can read and act on (no record matched, required field missing), since an unhandled exception reaches the agent as a call that failed for no stated reason.
• Say in the description what the tool does not cover. That is the sentence that keeps it from being chosen for the adjacent job.

What a Tool Returns Is Part of the Design

The response shape decides how much of the context window each call consumes and how reliably one call can feed the next. A tool that returns a complete record for every match fills the context with fields nobody asked about, and the practical consequence is that earlier turns get dropped to make room for them.

Result size is a correctness problem as well as a cost one. Where an API paginates, something has to decide whether the agent sees page one and treats it as the whole answer or is told explicitly that more exists. Truncation that happens quietly is the version of this that produces wrong answers with no visible failure anywhere.

• Return the fields a decision needs, plus a stable identifier for whatever the next call will act on.
• Report how many records matched, not only how many were included, so a partial answer can be described as partial.
• Use absolute timestamps with an explicit time zone. Relative dates in a result get reinterpreted against whatever the model believes the current date to be.
• Resolve codes into their meaning where the underlying system stores status as an integer, rather than leaving the model to guess what 3 means.
• Set a size ceiling per response and fail loudly above it instead of trimming the tail.

Rate Limits, Timeouts and Retries That Do Not Duplicate Work

Agents generate call patterns that human-driven clients do not. One question can fan out into a dozen lookups in a second, and a loop that decides it needs more context will do that again. Vendor limits that were generous for a UI get consumed quickly, the response comes back as HTTP 429 with a Retry-After header that something in the path has to honor rather than retry straight through, and limits are usually counted per credential, so several agents sharing one service account compete for the same budget.

Timeouts are the harder case. A request that timed out is not a request that failed: the connection ended and the write may well have landed. The mechanism that makes a retry safe has to be chosen per operation, before the first write tool goes live.

• An idempotency key generated per intended action rather than per HTTP attempt, so the server recognizes a retry of the same intent as the same action.
• Conditional writes where the API supports them: If-Match with an ETag, so a second attempt against a record that has since changed returns 412 instead of overwriting.
• A natural unique key in the target system, such as an external reference field, so a duplicate insert fails at the database rather than succeeding twice.
• Read-before-write as the fallback when none of those exist, understood as a narrowed race rather than a guarantee.
• A dead-letter path for actions that exhaust their attempts, so a lost write is a queue entry someone can see rather than a gap nobody noticed.

When This Is Not the Work You Need

Some of what gets scoped as agent integration is not an agent problem at all. If the trigger is deterministic and the steps are fixed (a record reaches a status, three systems get updated), a scheduled job or an integration platform flow does the same work with fewer moving parts and is far easier to reason about when it breaks. The reason to put a model in the path is that the next step depends on judgment about unstructured input, not that the sequence has many steps.

The other common case is a data problem wearing an integration costume. Where the answer people need spans four systems that disagree about which customer record is authoritative, connecting an agent to all four produces confident answers drawn from whichever one it happened to query. Reconciliation has to happen somewhere, and inside an agent is a poor place for it, because the resolution is not reproducible from one run to the next.