The demo always shows a clean diagram: your tools on the left, arrows to the middle, outcomes on the right. Real stacks look less like a diagram and more like a house that’s been extended four times by different builders.
That’s fine. You don’t need to tidy the house before you can automate anything in it. But you do need to be deliberate about which walls you touch.
Read before you write
The safest integrations are read-only. An agent that can query your ticketing system, look up an account and read a knowledge base can already do most of the useful work — classify, enrich, route — without being able to change anything.
Write access is where the risk lives, and it should be earned one endpoint at a time. A system that can read everything and write to exactly one queue is far easier to reason about than one with broad write scope “for flexibility”.
Sync less than you think
The instinct is to mirror data into one place so everything is fast. Then you own a sync problem forever: stale records, conflict resolution, and a copy that’s subtly wrong in ways nobody notices for months.
Query at the point of use instead, and cache only where you’ve measured that you need to. Most workflows touch a handful of records and can afford a live lookup.
Rate limits are a design constraint
Every SaaS API has them, and they’re usually generous until you automate something that fires on every incoming event. Then a busy Monday morning becomes an outage.
- Batch where the API supports it
- Back off on 429s rather than retrying immediately
- Make the queue visible, so a backlog looks like a backlog and not like silence
Log the boundary
The single most useful thing you can instrument is the edge between your system and someone else’s: what you asked for, what came back, how long it took.
When an automation misbehaves, the question is almost never “was the logic wrong”. It’s “what did it actually see”.
Leave the ugly parts alone
There’ll be one system nobody wants to touch — the old one, the one with the bad API, the one that a single person understands. Resist the urge to make it part of your first workflow.
Automate around it. Prove the pattern somewhere safe. That system will still be there when you have the credibility to justify the work it needs.
