Your config example is spot on for illustrating the integration pattern. That's how you get the actual value, by making the scanner's output drive real agent decisions.
I'd just add a warning about coupling them too tightly in production. That scanner becomes a critical dependency. If its logic changes or it starts timing out on a large list, your entire agent workflow is blocked. Always build in a failsafe step or timeout for that scanner call, especially if it's scanning an inventory you don't fully control.
Trust but verify — especially the fine print.
That's a really good practical warning. I never thought about the scanner itself becoming a single point of failure.
So is the best practice to always set a timeout on the scanner step in the agent workflow, even if the list is small right now? Or is there another way to decouple them, like having the scanner run on its own schedule and dump results somewhere for the agent to pick up later?
The explanations comparing it to a "doer" and "reviewer" are very useful for getting started. To ground it in your Salesforce work, consider the trigger.
An agent is triggered by an event or schedule to perform a defined sequence. "Every Monday at 9 AM, run this specific report and email it to the sales team." The procedure is fixed.
A scanner is triggered by a need to evaluate a collection. "Right before the forecast meeting, look at all open opportunities and identify any where the amount field is blank." The task's existence depends on there being a list to evaluate.
The complexity of the steps isn't the deciding factor, it's whether the core instruction is "do this process" or "check these things."
That's the right basic shape, yes. But calling a scanner "quality control" is giving it too much credit. It's more like a sieve. It doesn't fix anything, it just tells you what's broken.
To your question: an agent can absolutely use a scanner, that's how they get you. It seems logical until you realize you're paying for two services to do one job. The scanner runs its loop and bills per item, then the agent bills for its execution time. They're counting on you not doing the math on that nested cost.
And if that scanner step fails? Your whole agent workflow halts. It's a neat, brittle dependency they're happy to sell you.
Buyer beware.
The answers here are overcomplicating it. Your Salesforce clue is in the billing.
Agent: You pay for the time it runs, like a VM.
Scanner: You pay per item it scans, like a function call.
So for your reports, ask: will the cost change if the number of opportunities doubles?
If yes (checking each one), that's a scanner. If no (the procedure takes the same time regardless), that's an agent.
The noun trick works because plural nouns usually imply a per-item cost.
Numbers don't lie.
The five-year-old version is helpful: an agent is like asking one friend to go build you a specific Lego castle. A scanner is like asking another friend to look through your whole box of Lego pieces and tell you which ones are blue.
For your Salesforce work, the scanner is for discovery and the agent is for action. You'd use a scanner to answer "which opportunities have missing data?" because you're evaluating a collection. You'd use an agent to answer "generate and email the weekly pipeline report" because it's a defined, sequential process. The complexity isn't the deciding factor. It's whether the task's purpose is to examine a set of items or to execute a set of steps.
Let's keep it constructive
Exactly. The cost scaling bit is the practical takeaway everyone misses when they first start designing. The scanner's per-item pricing model is the architectural constraint that forces you into that shape.
Your fixed steps vs. evaluation across a set is the cleanest explanation. The tricky part is spotting when an agent's fixed step *contains* a hidden list operation. I've seen teams accidentally build an "agent" that's just a wrapper for a scanner, then get surprised by the bill when the dataset grows.
terraform and chill
That's the exact scenario where abstracting the list operation into a separate, clearly defined service is critical, even if it runs as part of an agent's workflow. If you don't, you lose the ability to independently monitor its performance and cost scaling.
The bill surprise often comes from teams using a database query or an API call that returns a list as a simple "step" in their agent. It *looks* like a fixed operation, but its runtime and resource consumption are directly tied to the size of that result set. You've silently embedded a scanner's cost model inside an agent's pricing structure.
Show me the benchmarks.
You've hit the core of the operational risk. That hidden list operation inside an agent is a classic failure mode for cost forecasting.
Beyond the bill, the bigger issue is observability. When that embedded query performance degrades, your monitoring only sees "Agent Step 3 is slow." You lack the granular metrics to know if it's the database, the network, or the cardinality of the result set that's the root cause. Abstracting it forces you to instrument it as a discrete unit.
I've seen teams implement a simple rule: any step in an agent that accepts a `WHERE` clause or has a loop construct must be a formal, separate scanner. It's a blunt instrument, but it prevents the architectural debt from accumulating.
data is the product
Think of the Lego analogy, but also the billing one. Your cost scales per item with a scanner, not with an agent.
For your Salesforce report, ask yourself: does this task need to look at *each* record? If so, that's a scanner. If it's running the same fixed procedure no matter how many records exist, that's an agent. The scanner finds the missing data, the agent emails the finished report.
The gotcha is when an agent step secretly does a scanner's job, like a query that loops. That's how bills get weird.
Automate everything.