External calls as a primitive, not an exception.

Connecting two systems the first time is finite, estimable work. What nobody estimates correctly is what happens afterwards: the provider changes a field, adds a mandatory parameter, changes a date format, introduces a new version.

In the traditional approach every integration is hand-written code: when something changes, someone has to find it, understand it and modify it — and meanwhile the flow stops. Worse, that code was often written by someone who has since left, so the change begins with a phase of archaeology.

When an external service is declared — which calls it exposes, which fields it wants, what it returns, what to do on error — the adjustment is an edit to that declaration. It doesn't eliminate the work, but it reduces it to an afternoon instead of a week, and above all it doesn't require touching anything else.

• Direct service call: the best form where the target system exposes interfaces. Synchronous, verifiable, with explicit error handling and a circuit breaker.
• Structured file exchange: the most common reality with systems of a certain age and with many logistics or public sector counterparties. It works well, provided you carefully design frequency, discrepancy handling and what happens when two worlds diverge.
• Inbound webhooks: when the external system wants to notify an event. The webhook becomes a declared entry point feeding a pipeline, with the same authorisation checks as every other path.
• Dedicated microservice: when processing is needed that doesn't belong in a pipeline — document reading, conversions, specialised computation. It lives as its own component with its own queue, and is invoked like any other declared resource.

What we never do is write directly into an external system's database bypassing its application logic. It's the shortcut that seems to solve everything and produces the worst damage, months later and in forms hard to trace back.

In projects using AI, the choice of model provider is a decision that changes over time: prices change, performance changes, regulatory constraints change, and sometimes the organisation's view on where data may travel changes.

So the model is treated as a declared, interchangeable resource, not an embedded dependency: replacing it is a configuration change, not a rewrite of the automation. That includes the option of models hosted within a perimeter you control, which is the choice for anyone with strict confidentiality constraints.

It's also why it's worth separating, in evaluations, the question "which model do we use" from the question "how do we govern what the model does". The second is architectural and has lasting consequences; the first is a choice you'll make again more than once.