Build
A system integration that ends the double entry between two tools
Two systems in your company hold the same record, and a person keeps them in step by copying fields between them: that person is the integration today. Describe both sides to AgentCode, and the agent writes the connection that takes the job over.
You describe the work · the agent writes the code · your team reviews before anything goes live
In short
System integration means making two systems agree about the same data without a human in the middle. On AgentCode you describe what lives where: the record in the first system, the record in the second, the field that identifies both, and what should happen when they disagree. The agent writes the connection, the matching rules and the tests, then hands it over for approval. It runs from your workspace, keeps a log of what it moved, and stops for a person when a case does not fit the rules.
What the agent connects for you
- A record created in one system and mirrored in the other
- A daily export from one tool loaded into another without retyping
- Matching rules that decide when two records are the same record
- A queue of cases that do not match, waiting for a person
- A log that shows what moved, when it moved and what it changed
- A retry that handles the other system being briefly unavailable
A process from IT
The problem
Sales records a new customer in the CRM and somebody in billing types the same company into the invoicing system, with a different spelling about once a week.
What the agent builds
The agent builds a connection that creates the billing record from the CRM record, matches on the tax number, and refuses to guess when two candidates look alike. Ambiguous cases land in a short review queue.
What you end up with
One customer entered once, a log that says where every record came from, and a queue that is usually empty. IT stops being the place where copy and paste errors are reported.
What a connection actually does
People say integration and mean anything from a nightly file to a live link. In practice a connection made here is a small set of decisions, written down and turned into code.
- Which side is the source of truth for each field, so nobody argues later about which name is correct.
- How a record on one side is recognised on the other: a tax number, an order number, an email address.
- What happens when the systems disagree: overwrite, keep both, or ask a person.
- How often data moves: as it happens, on a rhythm, or when somebody presses a button.
The agent asks these questions before writing anything, because the answers are business decisions, not technical ones. You answer in ordinary language, the plan comes back in ordinary language, and only then does the code get written. The same pattern applies whether the other side is a spreadsheet or a large platform, see spreadsheet imports.
Keeping a connection honest
A connection that moves data silently is trusted right up to the day it is wrong. The parts that make one trustworthy are not glamorous, so the agent writes them in from the start.
- Every movement is logged with the record, the field and the moment it happened.
- Cases the rules cannot settle go to a queue instead of being guessed.
- A failed call is retried, and a run that keeps failing raises its hand rather than going quiet.
- Tests cover the awkward records: the duplicate, the missing field, the name with a comma in it.
None of this reaches your systems until a person approves the change. The agent proposes, tests and explains, and a colleague on your side signs it off. When the other system changes its format, you describe the change in the same conversation and the connection follows, which is the part that usually dies in a one off project.
Where integrations usually start
Almost nobody starts with a live link between two large platforms. The first connection is normally the boring one that hurts every week.
- A file somebody downloads from one system and uploads into another, described under spreadsheet imports.
- Bookkeeping records that are typed twice, described under accounting connections.
- A form on a website whose answers are retyped into an internal list.
- A report that is assembled by opening three systems and copying columns into one sheet.
Once the first one runs, the second is faster, because the matching rules and the log already exist and the agent reuses them. If the two systems also need a screen for the people in the middle, combine this with a web app, or let the steps run on their own with workflow automation.
Questions teams ask
Do you have a ready connector for our system?
The agent writes the connection for the systems you name, using whatever those systems offer: an interface for reading data, an export, or a file drop. That is why an unusual or in house system is not a blocker. We are not a partner of the vendors you connect to, and we describe their systems only as endpoints of your integration.
What if the two systems disagree about a record?
You decide the rule and the agent writes it. A common choice is one side as the source of truth for each field, with anything ambiguous parked in a queue for a person. The log always shows which side a value came from, so a disagreement is a question with an answer rather than an argument.
Does our data pass through you?
The connection runs against your systems with your credentials, and the records stay on your side. The agent works on the code in your repository. We do not train on your code, and the plan the agent writes lists exactly which fields are read and which are written, so the scope is visible before anything runs.
How long does a first connection take?
Usually the answering of questions takes longer than the writing of code. Once you can say which record maps to which and how they are matched, a first working version comes back the same day for you to try against a copy of your data, and the awkward cases are refined from there.
More the agent builds
Stop paying people to retype records
Name the two systems and the field that identifies a record in both.