A reply is not a result. Finish the work.

Mostly it is the same automation with a different caller, and that is the point. Existing Flows were written to be triggered by a record change or a button, with a person supplying context and judgement. An agent supplies context assembled from a conversation and decides for itself when to call. So the automation needs explicit inputs rather than assumed ones, a defined outcome it can report rather than a silent success, and failure behaviour that does not leave a customer mid-sentence. Often we adapt what exists rather than replacing it.

Yes for reversible, low-consequence changes — logging an interaction, updating a preference, creating a case, changing a delivery address inside policy. No for anything that moves money, changes a contract, or cannot be undone, which should sit behind an explicit approval. The useful test is not how confident the agent is; it is what it costs to be wrong and how hard it is to reverse. Designing that boundary deliberately is usually what lets a risk owner approve everything on the other side of it.

It depends entirely on whether someone designed for it. A process that updates Salesforce, calls an ERP and sends a confirmation can fail at any of the three, and Salesforce cannot roll back what an external system already did. So we design compensating steps — reverse the CRM change, or flag the record for reconciliation and raise an exception — and we make sure the agent tells the customer the truth about what state things are in. Silent partial completion is the failure mode that erodes trust fastest, because nobody finds out for a week.

Only on the objects the agent touches, and yes, usually. Where several Flows fire on the same object update, the order they run in decides the outcome, and an agent invoking an action into that will produce results that look random. We inventory what fires on the objects in scope, find the conflicts, consolidate where it is safe and retire what is dead — with regression tests before anything is removed. It is the least glamorous part of an automation engagement and reliably the highest-value one.

It can eventually, but not in one project. Each domain has its own processes, its own control points and its own risk profile, and trying to cover all three at once produces an agent that is mediocre everywhere and impossible to debug. We sequence: one domain, one process, measured, then the next. The automation built for the first often gets reused by the second — routing, approvals and integration patterns travel well — so the second increment is faster than the first, which is how a programme builds momentum instead of stalling.

Compare the two front doors. Measure completion rate, exception rate and end-to-end cycle time for agent-initiated and human-initiated instances of the same process, and take a baseline before launch — the same discipline our optimization practice applies to the agent itself. Containment on its own is a misleading number — an agent can contain a conversation and still leave the work undone. The question that matters is whether the request finished without a person touching it, and whether it finished correctly, which is why exception rate belongs next to completion rate rather than in a footnote.