"Nothing to migrate" sounds like reassurance. It is really a bet on somebody else's API, and the bet can be lost in four specific places. Whoever makes the promise should have checked all four before the contract is signed, because the alternative is discovering in week five that the one write the whole workflow depends on is not exposed at all.
An agent on top of your existing stack does the same things a person does in those tools, only through the interfaces the vendors publish rather than the screens they designed. That gap is where the work lives. Here is what actually has to hold.
API coverage, and the read and write asymmetry
Reading is almost always easy. Every serious tool will hand you records over HTTP, and the fields you see in the UI are usually there.
Writing is where the gaps sit. The pattern repeats across categories: a rich read API, a write API that covers the obvious fields and skips the awkward ones. Computed and rollup fields are read-only, which is fine until the workflow needs to set the value that feeds them. Some record types are creatable but not updatable. Status changes that look like ordinary fields turn out to be transitions behind their own endpoint with their own validation. Attachments need a separate upload call with a different content type, sometimes a different host, and a size ceiling well under what the web upload accepts.
The test is cheap, so run it early. Take the three nastiest writes the workflow performs, not the easy ones, and make an agent do them against a sandbox or a throwaway record in week one of the build. Not read them. Write them, then read the record back and compare every field against what a person doing it by hand produces. A field that silently keeps its old value is the failure you are looking for, and it does not raise an error.
One more thing to check while you are in there. Whether the API can express the workflow's idea of "done". Plenty of tools let you write every field and still give you no way to record that a case was handled, because in the UI that state is a button wired to an internal process.
Rate limits are a design constraint
Rate limits are not an operational detail to handle later. They set what the agent can do in a run window, which sometimes changes the design.
Look for four things in the documentation. The window, which may be per second, per minute, per day, or all three at once. The scope, which is the difference between a limit per user and a limit for your whole organisation, and the second kind means your agent competes with every human in the tool and every other integration you already run. The cost model, because some APIs price a query by how much it returns rather than counting requests. And the penalty, which ranges from a 429 you retry to a temporary block on the whole credential.
Then do the arithmetic. A workflow touching 2,000 records with three calls each is 6,000 calls. At 100 calls a minute that is an hour of wall clock time before you add a single retry, and retries on a bad afternoon can add half again. If the workflow has to finish inside a 30 minute window because the next step in the business depends on it, you now have a design problem, and the answers are bulk endpoints, caching reads that do not change hourly, or splitting the run.
Build in the standard protections regardless. Respect the reset headers rather than guessing with a fixed sleep. Use exponential backoff with jitter, so a burst of retries does not synchronise. Put an idempotency key on every write you can, because a retry after a timeout is the most common way agents create duplicates, and the first request often succeeded.
Webhooks are a hint, not a source of truth
Webhook delivery is best effort at almost every vendor, and treating it as reliable is the most common way an agent system develops quiet gaps.
Assume all of the following, because each one is normal. Delivery is at least once, so the same event arrives twice and your agent must not act twice. Ordering is not guaranteed, so the update can land before the create. The payload is thin, carrying an ID and an event type, which means a fetch per event and those fetches count against the rate limit above. Some events have no webhook at all, deletions and permission changes being the usual omissions. And if your endpoint returns errors or times out for long enough, many vendors disable the subscription, sometimes with an email to whoever registered it and nothing else.
The fix is not clever, it is just work. Deduplicate on the event ID and keep those IDs long enough to cover a replay. Store the raw payload before processing so a failure is replayable. Then add a reconciliation sweep that queries records changed since the last successful sweep, on a schedule that matches the workflow's tolerance, and compares against what the agent has already handled. The sweep is what turns missed webhooks into a delay instead of a hole. It also tells you your webhooks stopped, which the vendor may not.
Permission models decide who the agent is
An agent needs an identity of its own. Running it on a person's token is the fastest way to start and the fastest way to regret starting. The logs attribute every action to that person, the agent's access silently changes when their role does, and the whole workflow stops the day they leave.
What you find when you look for a better option varies. Some tools have proper service accounts or app credentials with scopes you can narrow to the endpoints the workflow uses, which is the good case, even when the service account costs a seat. Some offer only user OAuth, so the answer is a dedicated account created for the agent, and you pay a licence for a user who is not a person. Some have scopes so coarse that read access to one object means read access to the whole workspace, which turns a technical decision into a data question your security lead should answer rather than you.
Two details catch people out. Record level visibility rules sometimes differ between the UI and the API, so an agent can read cases a person in that role cannot. And audit logs may record the credential rather than the reason, which is why the agent should also write its own log entry naming the workflow, the run and the rule it applied.
When a tool genuinely has to go
Sometimes the honest answer is that the stack has to change, and saying so late is worse than saying so early. The clear cases are narrow.
There is no API, and the vendor's answer is a CSV export from a screen. Scraping a UI is possible and it breaks on the vendor's schedule, not yours, so it belongs in nothing you are asked to trust. The API exists but sits behind a plan that costs more per year than replacing the tool. The data lives in free text or in per-person spreadsheets, where the problem is not access but that nothing has a stable identity to write against. The vendor's terms forbid automated access, which is a legal wall and not a technical one. Or the tool of record is a shared mailbox and a habit, in which case there is nothing to integrate with yet.
Everything else is a cost, not a barrier, and the cost belongs in the quote in plain numbers. Keeping the tool with the 100 calls a minute limit means this workflow runs nightly rather than hourly. That is a sentence a client can decide on. "We will need to modernise your stack first" is not.