Your Integrations Will Break. The Question Is Whose Problem That Is.

There is a moment in every agent evaluation where someone asks about integrations and the vendor puts up a wall of logos. Workday. ServiceNow. SAP. Salesforce, and a count along the bottom.

A logo wall answers one question: does a connector exist. Most serious vendors pass that test. What it does not answer is whether that connector survives contact with your instance. The one customized in 2019. The one behind your firewall. The one whose API documentation was last accurate two major versions ago.

That is the last mile problem: everything between "we have a connector" and "it runs in production under our controls." It is the stretch buyers under-scope, because it only shows up after the contract is signed.

Across enterprises with tens of thousands of employees and dozens of systems of record, the failure modes are consistent, and they sort by phase. Most surface while you are building. The rest wait until you try to go live, or until the integration has been running long enough that nobody remembers why it was granted what it was granted.

One question runs through both phases, and it is the one nobody scopes: does your platform administrator automatically become an administrator for every integration you connect? If the answer is yes, pause and ask whether your organization understands the risk in that.

Build phase

• Network reachability. The application runs on-premises or in a private cloud, and exposing it publicly is not a conversation your security team wants to have. This one does appear in the POC, and that is the trap: it gets solved with an exception opened for a demo environment that was never meant to be production, and the real conversation with the network team has not started. Connect at the application layer or the network layer, whichever your teams prefer.
• API availability. Some applications were never designed to be integrated with. This rarely surfaces in a POC, because POC scope gets drawn around whatever is easy to reach, so the system is deferred and the value often goes with it. Every large estate has several, and they are rarely peripheral: the benefits portal, the background-check vendor, the regional payroll bureau, the internal app nobody will fund a rewrite for. Operate them the way a person would, with headless browser and computer-use agents. Not elegant, but often the difference between shipping and shelving a use case.
• Change notification. No webhooks or events, or triggers that do not fire as documented. Without change notification a platform can act inside the system of record but cannot react to what happens there, which removes half of what an agent is useful for. Nothing errors, either. The workflow simply misses records, and you find out from a human who noticed something did not happen. The workarounds are efficient rather than elegant: drive the workflow from observed state with scheduled polling and reconciliation against the system of record, narrowed by watermarks or change columns so each pass reads deltas rather than the whole table, and where an unreliable trigger does exist, run both and reconcile the difference.
• Customized instances. Custom objects and fields that standard connectors were never written against, and instances customized so heavily that the vendor's reference behavior no longer applies. The most common problem by a wide margin: the connector works, it just does not work here. It compounds by geography, because the same vendor product is often implemented by different teams in different years. One global manufacturer we work with runs materially different stacks per business unit for the same functions. Extend the integration rather than replace it, and run discovery against your real, customized test or sandbox instance.
• Incomplete or incorrect documentation. Missing sections, stale sections, and sections that are confidently wrong. A POC rarely catches it, because a POC runs against a sandbox in close to default configuration, the one instance the documentation describes. Treat observed behavior as the source of truth. If the two disagree, the instance wins.
• The build should never touch production data. Builders and partners should develop against a sandbox or a masked copy, and the platform should make that the default path rather than something a delivery lead has to police. Most breaches of this rule are convenience, not malice.
• Who can create an integration, and who approves its endpoints. Creation is a privileged operation: requested, approved where the risk warrants it, and carried out by someone who already holds the permissions on the source system side, rather than falling to whoever happened to build first. Nobody should be able to hand themselves that access. And approval belongs at the endpoint rather than the tool, which is the distinction the next section is about.

Deploy and operate phase

• Promotion is a re-approval, not a copy. Built artefacts, tools and their endpoint list should carry over, while connection details are rewired and the endpoints approved again by your own administrator against the real instance. That is what stops the exception opened for a demo environment from travelling into production.
• Getting the right people looped in. Network, security and application owners each have a queue and reasonable questions. Asked sequentially after the build, that is a quarter. Started in week one alongside the build, with the tooling and visibility a platform should provide, it is a footnote.
• A kill switch, configured before you need it. Stopping is urgent, starting is a decision: security or the integration's owner can disable it, only the owner can re-enable it.
• A standing integration access audit. Who holds the administrator hat, which endpoints are still on the allowlist, and which of those anything has actually called this quarter. Access accumulates: an endpoint allowed for a use case that shipped in March is still allowed in November, whether or not a single agent has touched it since. That review needs an owner and a date rather than an incident to trigger it, and the platform should answer all three questions as an out-of-the-box dashboard rather than a project.

Every item on both lists is something a platform should give you tooling for, rather than leave to a policy document and the hope that everyone reads it.

Most platforms blur one distinction, and blurring it is how estates become ungovernable. An integration is a set of endpoints, and that is administrator territory. Which endpoints exist and who may reach them belongs with the people accountable for the systems. A tool is composed from allowed endpoints, and that is builder territory. The relationship is many-to-many, and the direction of authority is what matters: a builder composes from what an administrator has allowed and cannot compose past it.

Two consequences follow. Approve endpoints, not tools, because twenty tools built on two endpoints is two decisions rather than twenty, and a per-tool approval queue gets rubber-stamped by the third week. And the endpoint set is not only APIs: a web-only application sits under the same allowlist, scoping, kill switch and audit trail, because how an endpoint is reached is an implementation detail rather than a different governance regime.

A good tool also absorbs instance-specific mechanics rather than passing them to the agent. Closing a Jira ticket needs a transition ID that differs by project and by workflow inside the same instance, and an agent asked to reason about transition IDs will guess differently next week.

Every failure above is real for any vendor. The difference between programs that ship and programs that stall is not who encounters them, but who owns them. Ema owns the last mile problem end to end. Where your instance has been customized, adapting the integration is our responsibility, scoped against what we observe in your instance rather than what the vendor documents, so customization is priced in at design time rather than raised as a change request later. A browser-driven endpoint is the one place we qualify that: portals change with no deprecation notice, so we prefer an API wherever one exists, write down the trade-offs at design time, instrument the flow so a change surfaces as a detected failure, and work through the break with you rather than hand it back as a ticket. What stays with you is what only you can decide: credentials, data residency, approval policy, and who holds the administrator hats.

We built this into the platform rather than into individual projects. More than 250 pre-built connectors, authored as governed artifacts rather than bespoke code. Discovery against your own test or sandbox instance before design is committed. Endpoints allowlisted by administrators, tools generated from that set and published by builders. Headless browser and computer-use agents for systems with no usable API, under the same controls as API endpoints. Application-layer and network-layer connectivity, and scheduled polling for systems that publish nothing. Separate administrator hats for the tenant, for security and for each integration, with creation and promotion as governed operations. Permissions resolving to the individual permitted action, one immutable audit trail that answers who reached what as a query, and a kill switch that stops one tool, one integration, or every agent.

The proof that matters: A global IT services firm runs this across 250,000 employees in 65 countries and more than 50 fragmented systems with inconsistent API coverage and documentation, having cut HR response times from five days to seconds. Nothing about that landscape was clean, and cleanliness was never the precondition.

The evaluation question is not "do you have a connector for our HRIS." It is:

1. Our instance is heavily customized. How do you scope that, and what happens when it behaves differently from the documentation?
2. What do you do with a system that has no usable API?
3. What happens when a system publishes no events, and how would we know if you were silently missing records?
4. During the build, what data do your builders and partners actually work against?
5. Who decides which endpoints an agent may reach, and what stops a builder composing past that list?
6. Does our agentic platform administrator become an administrator for every integration by default, can they grant themselves more, and how would we review what access has accumulated a year in?
7. When our POC becomes production, do connection details and endpoint approvals carry over, or does our administrator approve them again?

Ask any vendor to answer those in writing. Connector lists win evaluations. Ownership wins production.

Next in this series: the trust loop, and why trust in an agent is re-earned every day rather than granted at go-live.

Header image concept: a wide industrial scene at dusk, a single well-lit bridge span crossing from a cluster of enterprise buildings toward one governed gateway, with the unfinished last section of the span picked out in warm light.

Graphic ideas:

1. Build, then deploy and operate, with one band running through both. Two columns for the two phases with their items beneath, and a permissions band drawn across both rather than sitting inside either. The visual argument is the band that does not stop at the phase boundary.
2. Does your platform admin become admin for everything it touches? The dangerous default on one side: platform administrator with an arrow into every connected system. The separated model on the other: nominated integration owners, no self-grant, security administrator holding the audit trail. The argument is the arrows that are absent.
3. Access accumulates. A timeline of one integration's allowlist over four quarters, endpoints added for use cases that shipped and never removed, with the ones nothing has called greyed out. The last frame is the same allowlist after a review that had an owner and a date.
4. Twenty tools, two decisions. Twenty tool cards fanning into two endpoint approvals. Beside it, the counter-example: twenty approval tickets in a queue, most stamped without reading.
5. Promotion is a re-approval. Build environment on the left, production on the right. Built artefacts, tools and the endpoint list cross the boundary. Connection details and approvals do not, and are re-issued by your own administrator. The POC exception is drawn stopping at the line, as is the production data that never entered the build environment.
6. What a tool hides. The raw endpoint call on one side, with a Jira transition ID that differs by project and workflow. The tool on the other: "close this ticket with this resolution." Only one of the two is legible to an agent or an auditor.