Every business past a certain size runs on systems that were each excellent choices individually and were never designed to know about each other.
The job today
A person is the integration.
The job is won in one system and typed into another to be scheduled. The hours are captured in a field app and rekeyed into payroll. The customer updates their address on the website and somebody updates it in the accounting system, next week, if they remember. The quote lives in one place and the invoice in another and the two are related by somebody having done it correctly.
This is tolerable at first and gets worse in a specific way: not more expensive, but less reliable. The retyping still gets done, mostly, but the two systems drift. A record updated in one and not the other. A job closed here and open there. Eventually nobody knows which system is right, so people check both, which is more work than the retyping ever was.
Then the question arrives — how many open jobs do we have, what did we bill this customer, are these hours in payroll — and the honest answer is that it depends which system you ask.
What the agent does
It moves records between the systems, on a schedule or as things happen, in both directions where both directions make sense.
The part that makes it worth building rather than buying off the shelf is that it works to your rules. A standard connector maps their fields to their fields. Yours has fields that mean something specific to your business, statuses you invented, a customer numbering scheme with history in it, and rules like a job does not go to accounting until the sign-off photo is attached. A custom connector encodes those. That is the difference between an integration people trust and one that has to be checked.
It decides, per field, which system is the authority. The field app owns the hours. Accounting owns the invoice. The CRM owns the contact details. That sounds obvious written down and is almost never written down, and the moment it is, half the disagreements between your systems stop being possible.
And when a record cannot go across — a required field missing, a customer that does not exist on the other side, a value the destination refuses — it says so, to a person, with what it was trying to move and why it could not. This is the line between a connector that is trusted and one that is not. Silent failure is the standard behavior of cheap integrations and it is worse than no integration at all, because you stop checking and the gap grows unseen.
What changes
The retyping stops, which is the visible win and the smaller one.
The systems stop disagreeing, which is the real one. When the same question gets the same answer from either system, people stop maintaining private spreadsheets to reconcile them — and those spreadsheets are usually where the actual reporting was happening.
And the drift becomes visible. Instead of discovering in March that two systems have disagreed since November, somebody sees the failed record on the day it fails.
What it connects to
Both systems, properly. Most modern platforms have a real interface for this. Older ones may offer a nightly file, or nothing but a login — which is workable but changes the shape of the project, so it is worth confirming what each end actually exposes before anything is scoped.
A written decision about direction and authority. Which way each piece of information flows, and which system wins for each field when they differ. This is an hour of conversation and it is the whole design.
Your rules about when a record is ready to move. Almost every business has these and almost none have written them down. They are the reason an off-the-shelf connector gets installed, produces a mess, and gets switched off.
And somewhere for failures to land — a queue a named person actually watches. An error log nobody opens is the same as no error handling, and it is the most common reason an integration that worked in January is quietly wrong by June.