When clicks run out, someone has to write the code.

Use a Flow whenever a Flow can express it, because your admins can maintain it without a deployment. Reach for Apex when the logic involves genuinely complex data shaping, when it must process collections safely at volume, when it needs elaborate error handling or callout orchestration, or when it enforces a rule you do not want anyone changing by accident. The deciding question is not which is more powerful — it is who will need to change this in eighteen months, and what happens if they get it wrong.

Write the interface for the reader that actually uses it. The agent chooses an action by reading its name, description and input definitions, so those need to state plainly what the action does, when it should be used, and when it should not. Two actions with overlapping descriptions produce unstable selection in exactly the way two overlapping topics do. Attach actions only to the topics that need them, keep the input set small, and evaluate selection accuracy against real utterances before shipping.

Yes — through an action that makes the call, typically Apex or an external service using a named credential, or through MuleSoft where an existing API is exposed as a governed, agent-callable asset. The engineering considerations are latency inside a conversational turn, authentication and token handling, retry and timeout policy, and what the agent says when the external system is unavailable. Work that cannot complete inside a turn is better published as an asynchronous job the agent reports having started.

They inherit the permissions of the user the agent runs as, so object, field and record access all apply. The place that breaks is inside custom code: Apex declared without sharing runs in system context and will happily read records the agent user could never see. We write agent-facing Apex with sharing and add explicit object and field permission checks, then verify it as part of the release check rather than trusting the declaration. An action is the easiest place in an Agentforce build to accidentally grant more reach than anyone approved.

At two levels, because they answer different questions. Unit tests cover the action body — correct results, bulk behaviour, permission enforcement, and every failure path — and they are deterministic. Agent evaluation covers whether the agent selects the action for the right requests and populates its inputs correctly, which is not deterministic and needs a batch of real utterances scored against expected topic and action. An action can pass its unit tests perfectly and still never be called, and teams that test only one layer usually discover the other one in production.

Start with one, and split when you have a concrete reason. Good reasons to split: two domains with genuinely different risk profiles, different audiences such as customers versus employees, or a topic set that has grown large enough that classification is becoming unstable. Bad reasons: organisational boundaries, or an assumption that more agents means more capability. Every split adds a handoff, and handoffs are where context gets dropped — so the design work moves to what gets passed across and who owns the conversation afterwards.