Connecting Two Systems Is Easy. That's only part of the story.
Notes from a weekend in Düsseldorf, and a problem every integration eventually runs into.
I travelled to Düsseldorf this past weekend for a festival with people from a few different groups of friends. Organising each group was straightforward enough, but bringing the separate plans together was where it became more complicated.
There were different group chats, calendars, travel arrangements, dinner plans and ideas about where everybody needed to be. A change could be completely clear in one conversation but never reach another. Nobody had necessarily failed to communicate. Each group simply had its own version of the plan, and those versions did not always remain aligned.
It felt familiar.
This is one of the problems we regularly underestimate when connecting business systems. Getting information from one platform into another is usually the easy part. Keeping both platforms in agreement after people, processes and circumstances begin changing that information is much harder.
Connectivity is not the same as integration
There is often a point in a technology project where somebody says that two systems are now integrated because a webhook has been added or an API request has worked.
Technically, they may be right. A customer performs an action, one system creates an event and another receives it. The request returns successfully, the data appears in the expected place and the integration ticket can be closed.
That proves the connection works. It does not prove that the wider business process will continue working afterwards.
The more important question is what happens when somebody changes that information in the receiving system. Does the original platform need to know about the change? Is it allowed to overwrite it later? Which system owns the current version, and what happens if both believe that they do?
A successful API call only confirms that information reached its destination. It tells us nothing about whether both systems will still describe the same reality ten minutes, ten days or six months later. Two systems can be connected perfectly and still become completely out of sync.
Ownership needs to be decided before data starts moving
Not every integration needs to operate in both directions. In many cases, one system should deliberately own a particular piece of information while the others consume it.
A CRM might own the commercial stage of an opportunity. A billing platform might own payment status. The product itself might own the customer's plan and entitlements, while an operational platform owns production or fulfilment status.
That can work very well, provided the ownership is clear.
The problems begin when two or more systems allow the same information to be changed, but nobody has decided which change should take precedence. One person updates the CRM, another changes the customer record in the product, and an automated process later copies an older value over both of them.
At that point, the technical integration has not necessarily failed. Every request may have been accepted and processed correctly. The failure is in the operating model behind it. Saying that both systems can edit something is not a source-of-truth strategy. The design needs to explain which system owns each important state, which other systems may influence it and how disagreements are resolved.
Without those decisions, connecting the platforms can simply make inconsistent information move around the business more efficiently.
Sending the first update only solves half of the problem
We ran into this while designing a commercial activity capability in one of our own products.
The initial requirement was straightforward. When somebody expressed interest in an upgrade, the product needed to record that activity and send it to a CRM or another commercial platform. That gave the commercial team visibility of the opportunity without requiring them to work directly inside the product.
Sending that event was not the difficult part. The more important question was what should happen after the commercial team had spoken to the customer. They might qualify the opportunity, mark it as converted, close it or decide that it was not worth pursuing.
If those changes only existed in the CRM, the product would continue showing the original status. The CRM might say the customer had converted, while the product still described them as merely interested. Billing or analytics could then introduce their own interpretation of the same customer state. Every platform might be behaving exactly as designed, but the business would no longer have one coherent version of what had happened.
The outbound webhook had worked. The integration had not.
The obvious response is to make the integration bidirectional, so System B sends its changes back to System A. That is often necessary, but two-way communication describes how messages travel, not how the systems behave when those messages arrive. A reliable integration also needs stable identifiers, clear record mapping, duplicate handling, retry behaviour, audit trails and rules for updates that arrive late or in the wrong order. It needs to know what should happen when two people change the same record at roughly the same time, or when an automated update conflicts with a manual decision.
Without that thinking, adding another webhook can make things worse. One system receives a change, treats it as a new event and sends it back. The other receives that event and does the same. Both systems can end up repeatedly overwriting each other because each believes its own version is authoritative. The hard part is not moving the data in both directions. It is preserving the meaning, ownership and history of that data while it moves.
Silent disagreement is more dangerous than a visible failure
When an integration breaks completely, it is usually inconvenient but obvious. An API returns an error, a queue begins to back up or an expected record never appears. Somebody notices and investigates.
Silent divergence is much harder to spot. The CRM can say that a customer has converted while the product still treats them as a prospect. Billing can show an active account while the analytics report excludes it. Each platform remains available, every dashboard continues loading and nobody receives an error.
The problem only becomes visible later, usually when somebody asks a question that should have been simple. How many customers converted? Why does this account have the wrong access? Has the order been paid? Which team is expected to act next?
Instead of answering the question, people begin comparing systems and debating which one should be trusted. The business decision is delayed because the underlying platforms no longer agree on the facts.
This is why some of the most damaging integration failures are the ones that return a successful response. The technology appears healthy while confidence in the information gradually disappears.
Reconciliation is part of the design
Good integrations should assume that messages will occasionally be delayed, duplicated, missed or processed in the wrong order. Services become unavailable, users make manual changes and systems are upgraded independently of one another.
That does not automatically mean the architecture is poor. It means the integration is operating in a real business rather than inside a controlled demonstration.
A reconciliation process periodically compares the systems and checks whether they still agree. It can identify records that have become disconnected, updates that never arrived and states that no longer match.
This is normal practice in financial systems. We do not assume that every individual transaction guarantees the final position. We periodically prove that the records reconcile.
The same principle applies to operational software. Reconciliation is not a repair added after an integration has failed. It is one of the things that makes the integration dependable in the first place.
AI agents make the problem more urgent
This matters even more as AI agents move beyond answering questions and begin taking actions across multiple platforms.
An agent may update a CRM, create a support ticket, change an account setting, trigger a workflow or initiate a payment process. Giving it access to several APIs allows it to perform those actions, but it does not define which system owns the result.
If the agent changes a customer record in one place, other platforms may need to know. A person might then make a different change somewhere else. The organisation needs to understand which update takes precedence, how the action is audited and what happens if the agent was working with incomplete or outdated information.
Connecting an agent to several systems does not create a coherent operating model. Without clear ownership and reconciliation, it simply gives the agent several more places where inconsistency can be introduced. As software becomes capable of taking more action independently, the decisions around authority, conflict and recovery become more important, not less.
Integration architecture is really ownership design
The real design question is rarely the endpoint, the payload or the authentication. It is who owns each piece of information, who is allowed to change it and what should happen when reality changes.
That requires input from product, operations, commercial teams and engineering, because the answer reflects how the business is intended to work. A developer can make two platforms exchange information, but they cannot decide alone whether the CRM, billing platform or product should own the customer's current status. This is why integration discussions so often become arguments about APIs when the underlying disagreement is really about ownership.
Connected software does not automatically create a connected business
Back in Düsseldorf, the separate groups and plans worked because people eventually compared what they knew and made sure everybody was heading to the same place. Changes had to move between conversations, somebody needed to know which plan was current and conflicting versions had to be resolved.
Business systems require the same clarity, although relying on one person to compare several group chats is not a particularly scalable architecture.
An integration is not complete simply because one platform can send another a payload. It becomes dependable when a change made in the right place reaches the systems that rely on it, failures can be detected and recovered, and everybody understands which system owns the decision.
That is a much higher bar than saying that two systems have an API between them.
It is also the difference between connected software and a connected business.