ON THIS PAGE (12 SECTIONS)
- ✓A handoff is a write with no contract: which system may create the record, which fields must match, and what happens when the receiver rejects the payload.
- ✓A model placed on an unowned handoff becomes another writer, and a harder one to audit than the person it replaced.
- ✓Use a model only where the input is unstructured and the output is a draft checked against a field contract. Known mappings belong in deterministic integration.
- ✓Persist rejections. An inbox is not an error log.
A new hire exists in the HR system. Payroll does not. Someone retypes the name, start date, and manager. IT does not learn about the hire until a third copy lands in a ticket. None of those products is failing. The workflow fails at the boundary where a fact has to become a fact somewhere else, and the only reliable carrier is a person.
That boundary is the handoff. Adding a model there does not close it. The model becomes another writer, one that is harder to audit than the coordinator it was meant to relieve. Close the write first. Then decide whether any step on that path needs a model at all.
A handoff is a write without a contract
Two applications that do not share a database can still form a sound workflow. What they need is a contract for the moment information crosses: which system is allowed to create the record, which fields must be copied, which value wins when they disagree, how quickly the second system must reflect the change, and what the workflow does when the second system rejects the payload.
When that contract lives in someone’s memory, the integration is the person. Spreadsheets show up because they are the only surface both teams can edit. The spreadsheet then becomes a third copy, with no stronger claim to being right than the systems it was meant to reconcile.
Why a new tool often keeps the gap
Teams add software because the current tool does not do a job. The new tool stores its own customer, employee, or order. Nobody is assigned the job of deciding which copy may create or correct the record. The manual step survives inside a nicer interface.
An assistant pointed at those copies will answer from whichever copy it can reach. It will not know that finance’s sheet and the ERP disagree unless a person has already defined which one is allowed to be right. That ownership problem is separate, and it is the subject of AI Features Need an Owner for the Record.
Four decisions the contract has to settle
| Decision | If it is still unclear | What to do before automating |
| Who may create this record? | Two systems both insert rows | Pick one writer. Other systems store a reference or a received copy. |
| Which fields must match? | Teams argue after a mismatch | Mark each field required, optional, derived, or ignored. |
| What if the receiver rejects the write? | Someone notices in email, sometimes | Store the rejection against the source record and name the person who must act. |
| Where does a correction land? | People fix the copy they can see | Corrections go to the creating system and propagate. Edits to a copy do not stick. |
Where a model is allowed to stand
A model fits when the input is unstructured and the output is a draft the contract already knows how to check. A vendor email can be turned into a proposed purchase request. The proposal is still a proposal. Code checks the vendor id, the amount, and the cost center, then commits or returns the draft.
A model is the wrong tool when the input is already structured and the rule is known. Copying an employee identifier from HR into payroll is a mapping. Put it in an integration with an idempotency key so a retry cannot create a second person. The wider choice between a fixed workflow and an agent is laid out in AI Agents vs Workflow Automation. If the path must survive a receiver being down, design it as an event-driven workflow with a visible waiting state, not a hidden retry loop.
Engineers decide which system may write. A model may draft a payload. A validator decides whether that payload is allowed to land.
Illustrative scenario: employee onboarding
This scenario is illustrative. It is not a Vasiva customer engagement, and it states no measured error rate.
A company creates employees in an HR system, then retypes them into payroll and files a ticket so IT can provision an account. Leadership asks for an onboarding agent. The useful first build is smaller. HR remains the only creator. A worker delivers a versioned payload to payroll and to the identity provider. When payroll rejects a field, the onboarding record stays in pending_payroll and the coordinator sees the field that failed. The worker does not loop. There is no ambiguous decision on this path, so there is no agent on it.
A narrow model can still draft the IT ticket’s description from a role title, because that text is unstructured. The draft cannot create the account. Account creation stays on the identity provider’s API, called by code, after the HR record is in an accepted state.
What the worker is allowed to return
| 1 | type HandoffState = 'accepted' | 'rejected' | 'waiting'; |
| 2 | |
| 3 | interface HandoffResult { |
| 4 | idempotencyKey: string; |
| 5 | state: HandoffState; |
| 6 | rejectedFields?: string[]; |
| 7 | } |
accepted means the receiver stored the payload. rejected means it refused specific fields and a person must change the source. waiting means the receiver could not be reached and the same key will be sent again later. None of those states is a model score.
Checklist before you automate the step
- Name the record and the single system allowed to create it.
- List the fields that must cross, and the fields that must not.
- Choose an idempotency key so a retry cannot create a second employee, invoice, or ticket.
- Persist rejections on the source record. Do not treat an inbox as the error log.
- Name the role allowed to correct the source.
- State what happens when the receiver is down: queue with the same key, or stop. Do not guess in a retry loop.
- Add a model only on a step whose input is unstructured and whose output is checked against the field contract.
- Name the person who looks at waiting and rejected states. A handoff with no owner is still manual.
What a clean handoff does not fix
A reliable copy of a wrong manager is still a wrong manager. Closing the handoff makes the source visible. It does not make the source true. Gregor Hohpe and Bobby Woolf’s enterprise integration patterns treat incompatible models and partial failure as normal properties of systems that were not designed together. The useful response is a contract at the boundary, not a promise that one new platform will erase the boundary.
If the applications cannot implement that contract, then replacing one of them is a real option. Replacing both of them with a suite that still stores two copies of the employee recreates the handoff under a single vendor. Start with the write.
Questions that usually come next
Will an integration platform close the handoff by itself?
It can move a payload. It does not decide which system wins, which fields are required, or who fixes a rejection. Configure the platform after those decisions are written down. Configuring it first freezes the ambiguity in a workflow diagram.
Should the two applications be replaced by one suite?
Only when you are willing to operate that suite as the system of record. A suite that still lets two modules create the same person has not closed the handoff. It has moved it.
Direct answers
Will an integration platform close the handoff by itself?
It can move a payload. It does not decide which system wins, which fields are required, or who fixes a rejection. Configure the platform after those decisions are written down.
Should the two applications be replaced by one suite?
Only when you are willing to operate that suite as the system of record. A suite that still lets two modules create the same person has moved the handoff, not closed it.
References & Prior Art
Enterprise Integration Patterns
Gregor Hohpe and Bobby Woolf • Enterprise Integration Patterns (2003)
Vikas
Software EngineerVikas focuses on event architectures, webhook idempotency, queue resilience, and sequential product development workflows at Vasiva.
