The model is the easy part now. The model has been the easy part for about eighteen months, and it’s getting easier. What kills most AI projects in Australian SMBs has nothing to do with the model. It has to do with the last mile: connecting the smart thing to the actual systems, in the actual business, in a way that survives the Tuesday morning when SharePoint changes its API and nobody noticed.

We call this the integration tax. It is roughly 70% of the work and 100% of the reason for projects that miss their date.

Here’s what it looks like in practice. A Score identifies a high-impact opportunity: an agent that triages incoming claims, classifies them, drafts a response, and updates the case management system. The model layer for this is straightforward. The prompt engineering is half a day. The retrieval setup is a week. The actual agent loop is maybe three weeks.

Then the integration tax begins.

The case management system is a 2017 Salesforce instance with custom objects nobody’s documented. The customer authentication uses a SAML provider that was set up by a contractor who’s no longer reachable. The email comes in via a shared mailbox that’s also being read by three humans who occasionally pull messages out before the agent sees them. The compliance team needs an audit trail in a specific format they invented in 2021. The ops manager wants the agent’s confidence score visible to the team but hidden from the customer. The CFO wants a monthly cost report by department, which means tagging every API call with the department it served.

None of this is in the model. All of it is required for the model to be useful.

The teams that ship pay this tax explicitly. They scope it in the Compose phase, they staff for it in Rehearse, and they don’t pretend the demo is the product. The teams that don’t ship spend three months building a beautiful agent that works perfectly in isolation, then six months trying to connect it to anything, then quietly reassign the budget.

The integration tax has a few characteristic costs that are easy to underestimate.

Authentication and authorization

Every system has its own quirks. Service principals expire. OAuth tokens need refresh logic. Permissions need to be granted, audited, and rotated. If you’re connecting to four systems, you’re doing this four times.

Rate limits and quotas

The model has them. The downstream systems have them, often less generously. The integration layer has to handle backoff, queuing, and the occasional total failure of a third-party.

Schema drift

APIs change. Salesforce updates fields. Microsoft renames a property. Your CRM vendor introduces a “minor” breaking change in a Tuesday release. The integration has to either be tolerant or watched.

Observability

You can’t debug what you can’t see. Every step of the agent, every external call, every retry, needs to be logged in a way someone on your team can search next month when the customer complains.

Fallback behaviour

What does the agent do when the case management system is down for an hour? When the auth provider is slow? When the model returns an unexpected output? “Crash” is not a fallback strategy. Defining the fallbacks is often the longest single conversation in a project.

The honest version of an AI roadmap budgets for this from day one. Our Compose deliverables include integration architecture before they include prompt design. Our Rehearse phase explicitly includes the boring tests: what happens when X is down, what happens when Y rate-limits us, what happens when the data is malformed.

If you’re being shown a beautiful demo and the conversation about integration is “we’ll handle that during rollout,” the project’s already in trouble. The orchestra doesn’t tune in front of the audience.