Four integration patterns that keep showing up
After connecting Lyrion to a lot of different stacks, the connections start to rhyme. Almost every integration is one of four shapes, and recognising which one you are dealing with saves a surprising amount of design time. Here are the four.
Knowing the pattern up front tells you where the work and the risk will be.
Read for context
The simplest shape is read-only: the agent reads a system to inform an answer but never changes it. Pulling account history to draft an informed reply, checking an order status, reading a knowledge base. Low risk, high value, and usually where a new integration should start.
Most of the value of context comes from this pattern, and because it changes nothing, it is the safest place to build trust before you grant any write access at all.
Act under a rule
The second shape is a bounded write: the agent takes a specific action under a specific rule. Issue a refund under this policy and limit. Update this field on resolution. Book this appointment. The action is real but constrained, and the constraint is the whole safety story.
This is where approvals and thresholds live. The pattern is not “let the agent write to the system,” it is “let the agent take these named actions, within these limits, logged.” The bound is the design.
Route and hand off
The third shape moves work rather than changing records: triage, tag, assign, escalate. The agent decides where a piece of work should go and sends it there with context attached. It touches the flow of work more than the data, and its failure mode is misrouting, which is recoverable.
This pattern is how an agent takes a queue down to the part that needs a person. It is lower-stakes than writing to records and often the highest-leverage thing to automate first.
Sync and write back
The fourth shape keeps two systems agreeing: the agent writes the outcome of its work back so the record stays current. This is the pattern behind CRM hygiene as a by-product. It is a write, so it lives under rules and logging, but its purpose is consistency rather than action.
Recognising which of the four a given need is tells you immediately where to put the approvals, what to log, and how much to worry. Most integration design is just sorting the requirement into one of these boxes and then following the box's rules.
Why the record matters
A confident wrong answer is only dangerous if you cannot see how it happened. Every action here is logged, attributable and reversible, so a mistake is something you can find, explain and undo, rather than something you hear about from a customer weeks later.