Agentforce triggered agents

For its first two years, every Agentforce agent had the same first move: it waited. A customer typed, an employee asked, a developer called the API — something initiated, and then the agent reasoned. The agent was a tool you picked up. Useful, but fundamentally passive: it only ever knew about the problems people brought to it, which means it never knew about the problems nobody was looking at yet.

The Summer ‘26 release changed the first move. Triggered agents let an Agentforce agent fire on an event instead of a prompt — a deal stage change, a support ticket escalation, a signal from Data 360 — and act with no human starting the conversation. The pitch writes itself: your agents stop being tools you reach for and start behaving like a colleague who notices the escalation while you’re still in the meeting. It’s the most architecturally significant thing to happen to Agentforce since grounding, and it’s also the fastest way to run up a credit bill you didn’t forecast. Both of those are true at once, and this post is about holding them in the same hand.

What actually changed

The reasoning engine didn’t change. What changed is what’s allowed to start it. A triggered agent binds an event source to an agent so that when the event fires, the agent runs — picks a topic, reasons over context, and executes its actions — exactly as it would in a conversation, except the “utterance” is a system event and there’s no human on the other end.

You configure the binding in Setup: you point a trigger at an agent, scope it to a topic, and decide what context travels with the event. Salesforce made a point of noting that the configuration itself is non-billable — building and wiring a triggered agent doesn’t consume Agentforce credits. That’s a deliberate reassurance, and it’s also a tell about where the cost actually lands, which we’ll get to.

Three things feed a trigger, and they map cleanly onto machinery you already have:

Record and platform events. A record-triggered flow or a platform event fires when something changes in the CRM — a case hits a priority threshold, an opportunity slips, an order flips to exception. This is the most common trigger and the easiest to reason about.
Data 360 signals. A Data Cloud-triggered flow, data action, or calculated insight fires when unified data crosses a line — a churn score tips, an engagement pattern breaks, a real-time stream detects something the CRM alone would never see. This is where triggered agents earn their keep, because the signal often lives in data no single system owns.
Schedules. A time-based trigger runs the agent on a cadence — a nightly sweep of at-risk accounts, an hourly check on stuck orders.

Whatever the source, the pattern underneath is the same: the event carries or gathers context — related records, history, dependencies — and hands the agent enough to reason with. An agent triggered on a bare record ID with no surrounding context will reason badly; the quality of a triggered agent is mostly the quality of the context you assemble before it wakes up.

The mechanism: how an event actually invokes an agent

Under the productised feature is a mechanism that’s been available to developers since early 2025, and understanding it tells you exactly what a triggered agent can and can’t do. You can invoke an active agent programmatically through the Invocable Action API, from both Flow and Apex.

The important wrinkle: the standard AI Agent flow action is built for UI contexts, and a record-triggered flow runs in a UI-less context. So the clean path from a record change to an agent is a record-triggered flow that calls a small Apex handler, and the Apex invokes the agent through the platform’s Invocable.Action API:

public with sharing class EscalationAgentTrigger {
    @InvocableMethod(label='Run escalation agent for a case')
    public static void run(List<Id> caseIds) {
        for (Id caseId : caseIds) {
            // 'generateAiAgentResponse' is the standard action that invokes an
            // active Agentforce agent by its API name (found on the agent's
            // detail page in Setup).
            Invocable.Action action =
                Invocable.Action.createCustomAction('generateAiAgentResponse', 'Escalation_Agent');

            // Parameter names come from the agent/Agent API signature — the
            // agent needs the message that stands in for the "utterance" and,
            // optionally, a session id to continue an existing conversation.
            action.setInvocationParameter('userMessage',
                'A case has escalated. Assess it and take the appropriate action. Case: ' + caseId);

            List<Invocable.Action.Result> results = action.invoke();
            if (!results.isEmpty() && !results[0].isSuccess()) {
                // Never swallow this. A triggered agent that fails silently is
                // an agent nobody knows stopped working.
                System.debug(LoggingLevel.ERROR, results[0].getErrors());
            }
        }
    }
}

Two design facts fall straight out of that code. First, invoking an agent this way is genuinely asynchronous, event-shaped work — you’re firing the agent and it goes and reasons; you are not blocking a user on the result. Do this from an after-save context or an async path, never inline in a way that ties up the transaction. Second, the agent still runs as a user with all the access that implies, so everything in Data 360 governance and agent access applies here doubly: a triggered agent acts unattended, so the running identity’s permissions are the only thing standing between it and data it shouldn’t touch.

If your trigger originates in unified data rather than a CRM record, the front half changes but the back half doesn’t — a Data Cloud-triggered flow assembles the signal and context, then reaches the same invocation. The Pub/Sub API and platform events are the other well-worn route for anything originating outside Salesforce entirely.

Should this even be an agent? The reasoning test

Here’s the discipline that separates a triggered agent that pays for itself from one that’s an expensive way to run an if statement. A triggered agent is worth it only when the response requires judgment the event doesn’t already contain.

Run the test on every trigger you’re tempted to build:

If the action is deterministic — “when an order flips to exception, notify the account owner and create a task” — that is a record-triggered flow, full stop. It has no ambiguity, needs no reasoning, and putting an agent on it means paying a language model to execute a branch you could have drawn. Flow does it faster, cheaper, and more reliably.
If the action requires reasoning over messy or unstructured context — “when a case escalates, read the thread, weigh the customer’s history and entitlement, decide whether to offer a remedy or route to a specialist, and draft the response” — that is a triggered agent. The judgment is the value, and the judgment is exactly what a flow can’t encode.

The failure mode we see is teams reaching for a triggered agent because it’s the exciting new capability, wrapping a three-branch decision in a reasoning engine, and then wondering why the automation is slower and pricier than the flow it replaced. The Flow, Apex, or Agentforce decision guide is the same call it always was; triggered agents don’t change the answer, they just make it tempting to get it wrong. Use the agent for the judgment and let it call deterministic flows and Apex for the mechanical steps — that division is the whole design, and it’s the one covered in building an Agentforce action from a Flow.

The credit math nobody forecasts

Now the reassurance from earlier — configuration is free — and why it’s precisely the wrong thing to be reassured by. Building the trigger costs nothing. Running it costs on every fire. A triggered agent that executes at runtime consumes Flex Credits exactly like a conversational one: a standard action is 20 credits, roughly $0.10 at list, and a triggered run typically chains several actions to gather context, reason, and act. We break the meter down in full in Agentforce pricing and Flex Credits, but the headline for triggered agents is specific and unforgiving: the meter runs on the machine’s cadence now, not a human’s.

That changes the risk profile completely. A conversational agent’s volume is bounded by how many humans talk to it. A triggered agent’s volume is bounded by how often the event fires — and events fire in bursts, at night, during data loads, in loops nobody anticipated. Do the arithmetic before you deploy, with your own numbers:

An agent triggered on every case update, at an assumed 5 actions per run, on an assumed 8,000 case updates a month, burns 800,000 credits — about $4,000 a month at list, for an automation that mostly wakes up to decide it has nothing to do.
The same agent triggered only on escalation to a priority threshold, say 400 times a month, burns 40,000 credits — about $200. Same logic, same value, a tenth of the volume, because the filter did the work the agent shouldn’t have to.

The lesson is blunt: the trigger’s filter is a cost control, not just a correctness control. Every fire that wakes the agent to conclude “nothing to do here” is a fire you paid for. Filter as tightly as the use case allows, at the event source, before the agent ever reasons. And two operational hazards deserve a hard stop before go-live:

Loops. A triggered agent whose action updates a record that fires the same trigger is a self-perpetuating credit incinerator. Guard every triggered agent against re-entrancy — check whether the change that fired the trigger was made by the agent itself, and bail if so.
Storms. A data import that touches 200,000 records will fire your record trigger 200,000 times. Bulkify, debounce, and put a circuit breaker on triggered agents that can be fired by bulk operations, or a Tuesday-afternoon data load becomes a five-figure surprise.

Turn on Digital Wallet alerts before the first trigger goes live, not after the first invoice. A conversational agent’s overage grows at conversational speed; a misconfigured trigger’s overage grows at event speed, and event speed is faster than your billing cycle’s ability to warn you.

Guardrails when there’s no human to catch it

The defining property of a triggered agent — no human initiates it — is also its defining risk: no human is in the loop by default, so every guardrail has to be built, not assumed. In a conversation, a person is right there to notice a wrong turn. In a triggered run, the first anyone hears of a bad decision is its consequence.

Three controls are non-negotiable:

Keep the human on the consequential action, not the trigger. Let the agent fire, reason, and prepare freely — that’s where the reclaimed time lives. But if the outcome is irreversible or costly (issuing a refund, emailing a customer, changing an entitlement), the agent’s job ends at proposing it and a human approves. This is the human-in-the-loop approval gate designed before you need it, and for triggered agents it’s not optional polish — it’s the difference between an autonomous assistant and an unattended liability.
Make every triggered run observable. A triggered agent that fails silently is worse than no agent, because everyone assumes it’s handling something it quietly stopped handling three weeks ago. Every fire should land in Command Center and your observability layer: what fired it, what context it saw, what it decided, what it did, and whether it errored. If you can’t answer those five for last night’s runs, you don’t have an automation, you have a rumour.
Enforce access as if the agent were a stranger. Because a triggered agent runs unattended as its configured user, its blast radius is entirely that user’s permissions. Scope the running identity to exactly the objects and fields the use case needs and no more — the full argument is in Data 360 governance and agent access, and it matters most precisely when no human is watching what the agent reaches for.

The takeaway: proactivity is a capability, not a default setting

Triggered agents are the feature that finally makes “agentic” mean what the marketing always claimed — software that notices and acts, not software that waits and answers. That’s a genuine step, and for the right use cases (the churn signal caught at 2 a.m., the escalation triaged before the customer emails twice, the exception resolved before it becomes a shipment delay) it’s the difference between an agent that saves time and one that prevents problems.

But the move from reactive to proactive isn’t a toggle you flip; it’s a discipline you adopt. Pick triggers where judgment is genuinely required and let flows handle the deterministic rest. Filter at the source so the meter runs on real events, not noise. Guard against loops and storms before they teach you the hard way. Keep humans on the irreversible actions and instrumentation on all of them. Do that, and a triggered agent is a colleague who never sleeps. Skip it, and it’s an unattended process with your credit card and your customers’ trust, running at a speed you can’t watch. The capability is real; whether it’s an asset or a hazard is entirely a function of the care you put in before it fires. That care is most of what our Agentforce practice does before a trigger ever reaches production — and if you want to sanity-check whether a proactive automation pays for itself, our automation savings calculator runs the trade honestly.

Understanding the basics

What is a triggered agent in Agentforce?

A triggered agent is an Agentforce agent that runs in response to an event rather than a human prompt. Introduced in the Summer ‘26 release, it binds an event source — a record or platform event, a Data 360 signal, or a schedule — to an agent, so that when the event fires the agent reasons over the supplied context and executes its actions with no one initiating the conversation. It’s the shift from a reactive assistant you invoke to a proactive one that notices changes and acts on them, and it uses the same reasoning engine and actions as a conversational agent.

Do triggered agents cost Agentforce credits?

Configuring a triggered agent is free — building and wiring the trigger doesn’t consume credits. Running it is not: every time the agent fires at runtime it consumes Flex Credits like any agent, at roughly 20 credits (about $0.10 list) per standard action, and a run usually chains several. The critical difference from a conversational agent is that volume is bounded by how often the event fires, not by human traffic, so a loosely-filtered trigger can burn credits far faster than expected. Filter tightly at the event source, guard against loops and bulk-operation storms, and turn on Digital Wallet alerts before go-live.

When should you use a triggered agent instead of a flow?

Use a flow when the response is deterministic — a fixed set of steps with no ambiguity, like notifying an owner and creating a task on a status change. Use a triggered agent when the response requires reasoning over messy or unstructured context, such as reading a case thread, weighing a customer’s history and entitlement, and deciding among several possible remedies. Putting an agent on a deterministic branch just pays a language model to do what a flow does faster and cheaper. The best designs use both: the agent supplies the judgment and calls deterministic flows and Apex for the mechanical steps.

Weighing whether a proactive agent is worth the meter it runs on? Talk to us — scoping triggers so they fire on signal, not noise, is exactly the kind of call we make with clients before anything goes live.

Agentforce triggered agents: building an agent that acts on an event, not a prompt