Make Your Systems Talk To Each Other

You keep tasks in one tool, invoices in a second, customer notes in a third, files in a fourth. On Tuesday a client changed their address, and you typed the new one into three different places. On Thursday you noticed the fourth still had the old one. Nobody decided to build it this way. It accumulated, one reasonable subscription at a time.

What that condition costs you, why the standard fix has quietly changed underneath everyone, and what it concretely means for two systems to "talk" — those are the three things worth knowing. The adversary is the condition itself: scattered, half-overlapping services, each holding a fragment of your working truth EV-EQ1-INT-02.

The disconnect tax

Fragmented tools don't send an invoice, which is why the cost survives. But it is checkable. Watch a normal week and you will find it in three forms EV-EQ1-INT-01:

Re-entry. The same fact typed into more than one system. A new client, a price change, a corrected date — entered here, then again there, then once more somewhere else. Each entry is small; the habit is a permanent tax on every fact you handle.

Drift. Copies diverge because nothing owns the shared truth. The address that's current in one tool and stale in another isn't a data problem yet — it becomes one the day you act on the wrong copy. Drift is re-entry's compound interest: the cost of the entries you didn't repeat.

The work that falls between. Handoffs with no owner. The order that's confirmed in one system but never became a task in another. When work lives in the gap between two services, no tool shows it as overdue, because no tool knows it exists.

This is the ordinary condition of a working stack. Organisations run application portfolios in the hundreds, a majority of those apps adopted outside any formal oversight, and new AI tools mostly layer on top of what's already there rather than replacing it EV-EQ1-EXT-01. App counts are rising again after years of consolidation attempts, and roughly nine in ten organisations still have no true cross-app orchestration — most of what gets called automation stops at account chores rather than linking actual work EV-EQ1-EXT-02. A large share of paid licences goes unused, surprise consumption and AI charges are common, and most of the spend sits outside the team nominally responsible for the stack EV-EQ1-EXT-03.

Those are enterprise figures from vendors' own research, describing organisations far larger than a small studio, and they are not a measurement of your stack. What scales down is the shape: more tools than anyone chose deliberately, connected mostly by a human retyping things EV-EQ1-INT-02. The retyping human is the integration layer. That's the disconnect tax.

The era changed

The standard answer to this problem, for over a decade, was to rent the connection. Trigger-action recipe services — when this happens over here, do that over there — made linking apps accessible to people who would never write code. When wiring two services together genuinely required a programmer, a five-minute recipe was the rational choice. The early services described themselves, accurately, as digital duct tape for non-programmers, and they were exactly that useful EV-EQ2-EXT-02.

What changed between roughly 2024 and 2026 is who can make the tool. The first era made linking accessible through catalogues of pre-built recipes; the current era makes building accessible, because AI systems now participate in workflows directly — they can listen for what happened, decide, act, and, critically, write the small program that connects two systems in the first place EV-EQ2-EXT-01.

That last part is the ground moving. The rented recipe was a workaround for the fact that you couldn't build the connector yourself. Once that fact stops being true, the recipe isn't wrong — it's just no longer the only reasonable option. The thing you used to rent, you can now own EV-EQ2-INT-01.

The pattern

Here is the pattern in one sentence: AI builds the connector; you own it; an agent operates it EV-EQ4-INT-01. Each clause carries weight, so take them one at a time.

AI builds the connector. Models write code to call tools and integrations directly — discovering an interface, generating the adapter, filtering data in the execution environment — because writing small adapters is something they are demonstrably good at EV-EQ4-EXT-02. A connector between your invoicing tool and your task list is a modest program: read an event from one side, transform it, deliver it to the other. That is squarely inside what an AI can draft in minutes and a human can read in one sitting.

You own it. Ownership here means something specific and checkable: the adapter is code you keep, running on a machine you control. It doesn't expire when a subscription lapses, and its behaviour doesn't change because someone else shipped an update. The infrastructure has moved the same way — there is now an open, widely adopted protocol for connecting AI systems to tools and data, governed under neutral foundation stewardship rather than by any single company, so the interface your connector speaks can itself be something you implement and keep EV-EQ4-EXT-01.

An agent operates it. A connector isn't only written once; it runs, retries, and occasionally meets a case nobody anticipated. The same class of AI system that drafted the adapter can supervise it — notice the failure, read the log, propose the fix — with you approving what changes.

What you can check about a connector you own is narrower than what you might hope, and worth being precise about: you can read every line of it; you can run it entirely on your own hardware when a job's privacy calls for that; you can audit each step it takes EV-EQ4-INT-02. Whether it outperforms a rented recipe is a benchmark question, and we haven't run those benchmarks. What we have is pattern-level: TDA builds and operates its own systems this way, and that is what shapes this piece — not your stack, which we haven't seen (bounded experience).

What the pattern reframes is the lock-in question. What's sold as "integration — connect your systems" is often, structurally, a recipe you rent forever: the connector exists only inside someone else's platform, priced monthly, owned never EV-EQ4-INT-01. Rented versus owned is the choice actually in front of you.

What "talking" means, concretely

"Make your systems talk" collapses into hand-waving unless you can say what a conversation between systems is made of. At altitude, it's made of three primitives — and knowing which is which is most of the literacy you need EV-EQ3-EXT-01.

A queue hands each piece of work to exactly one consumer, then deletes it on acknowledgment. Use it when something must be done once — send the invoice, resize the image — and it matters that two workers never both do it.

Publish/subscribe fans a message out to everyone currently listening. Use it when one fact is interesting to several systems at once and whoever's subscribed right now should hear it.

An event stream is a durable, ordered, replayable log. Consumers read it at their own pace, and a system added next year can replay history it wasn't alive for. Use it when the record of what happened is itself the valuable thing.

These are genuinely different tools, and picking the wrong one buys operational debt without fixing the coupling you were trying to escape EV-EQ3-EXT-01.

Why route messages through an intermediary at all, instead of having system A call system B directly? Because direct synchronous calls couple the two systems' fates: both must be up, both must be fast, both must scale together, and a burst in one becomes an outage in the other. An asynchronous broker between them buys temporal decoupling — the producer and consumer no longer need to be available at the same moment — and load leveling, so bursts queue up instead of falling over EV-EQ3-EXT-02.

The shape that emerges is simple enough to hold in your head: producers emit facts when something meaningful changes; a broker buffers and distributes those facts; consumers subscribe and act on them, each at its own pace EV-EQ3-EXT-04. One concrete beat of it: an order is placed — that fact is published once. Billing hears it and raises an invoice. Inventory hears it and decrements stock. Neither called the other; neither waits on the other; neither knows the other exists. Next quarter, a bookkeeping system subscribes to the same events — without anyone rewiring billing or inventory.

One caution completes the vocabulary: pointing every tool at one shared database is a classic integration style, and it fails in a classic way — every system coupled to one schema, contention on every change, a bottleneck everyone writes into. Where systems do need shared state, the durable pattern is local stores or materialised views fed by the event flow, rather than one contested central store everyone edits directly EV-EQ3-EXT-03.

That's the whole vocabulary: events, queues, pub/sub, streams, and stores fed by events. It fits on an index card, and it's enough to specify a connector — or to evaluate, line by line, one that an AI drafts for you.

A next action, and a door

You don't need an architecture to start. You need the list.

For one week, keep a note of every moment the disconnect tax lands on you: each fact you re-enter, each pair of copies you catch drifting, each piece of work you personally carry across the gap between two services. At the end of the week, that note is your integration backlog — priced in your own time, in your own handwriting. Then pick the single seam that stings most and ask three questions of it: What is the event? Who needs to hear it? Where should the shared truth live? Those three answers are the specification of your first owned connector.

If you'd rather not think that seam through alone, that's the conversation TDA exists to have — bring the week's list, and we'll look at where the first owned connector belongs in how you work (proposal).

---

Sources and labels

Claims in this piece carry a bracketed evidence ID. Each ID resolves once here, to the kind of claim it is and the kind of published record behind it, with its date. Figures quoted above are as published by those records — they are not TDA measurements, and none is presented as a prediction about any particular reader's stack.

Label key. Sourced fact — traceable to published external material. TDA interpretation — our pattern-reading of that material. Bounded experience — the limits of what our own practice supports. Proposal — forward-looking invitation, not established fact.

Evidence pack as of 2026-08-20. Passages marked (bounded experience) and (proposal) carry no external record by design.