What Does an Agent Need to Know Before It Acts?

A customer profile is a starting point. A replacement decision needs more.

A customer tells a service agent, “My device failed again. Replace it.”

The agent can find the customer’s account, read the case history, and summarize earlier conversations. It may sound well informed. But can it tell whether this particular device qualifies for a replacement?

That takes more than knowing the customer. The agent needs to identify the device, check the order, find the warranty that applies, and establish what is known about the failure. It also needs to know whether another replacement has already been approved.

Some of those facts may be in Salesforce. Others may live in an order system, a device platform, or a policy document. Bringing them together helps, but the team still has to decide which sources to trust, how recent the information must be, and what to do when something is missing.

That is the question behind context design: what does this agent need to know before it can responsibly take the next step?

Teams already assemble information for decisions

A support representative working without an agent does much of this today. They open the case, look up the order, read the warranty, and check the device’s service history. A Flow can retrieve records, and an Apex service can request information from another system.

The process can be slow or incomplete. Its gaps, however, often give the representative a reason to stop. An order lookup fails. A warranty date is missing. The device platform is unavailable. The representative can say, “I cannot verify that yet.”

An agent needs an equally clear way to recognize those gaps. A fluent answer should not conceal the fact that a required check failed.

Bringing data together is only part of the work

Salesforce positions Data 360 around bringing structured and unstructured data together, resolving customer identities, and making information available for retrieval and use. These capabilities can help connect a service conversation to records and documents spread across systems.

They address useful questions: do these records belong to the same customer? Where is the relevant information? Which documents might help answer this request?

A replacement decision adds further questions. Does this warranty apply to this device and region? Has the order changed since the data was retrieved? May the agent use the information for this purpose? Is it allowed to approve the replacement, or only prepare a recommendation?

Finding information and having permission to act on it are separate checks. A user may be able to read a case without being allowed to approve a replacement. The same distinction needs to hold when an agent does the work.

Start with the decision the agent must make

For the replacement request, write down the questions that must be answered before approval. This gives the team a practical way to decide what belongs in the agent’s context.

What the agent needs to establish	Why it matters
Which customer and device are involved?	A matching name alone can lead to the wrong account, serial number, or service history.
What is the current order and replacement status?	The item may already have been returned or replaced.
Which warranty terms apply?	Eligibility can depend on the product, region, purchase date, and policy version.
What evidence supports the reported failure?	A customer’s report, a telemetry reading, and a model’s inference are different kinds of evidence.
How recent is each fact?	An old order snapshot may miss a replacement approved a few minutes ago.
Where did the information come from?	The team needs to explain the decision and investigate it if something goes wrong.
What may the agent do with this information?	Access to a record does not automatically grant authority to approve a replacement.

If the next step includes contacting the customer, the system also needs to check the chosen channel and any applicable consent or communication preferences. That check belongs to the contact action; it should not be treated as proof of replacement eligibility.

This list is more useful than a request to “give the agent all customer data.” It states what information is required and why, and it gives the team something concrete to test.

Make missing information change the next step

Suppose the order system is unavailable. The agent still has yesterday’s order snapshot and remembers that the customer asked for a replacement last week.

That may be enough to continue the conversation. It may be enough to explain the usual replacement process. It may be insufficient to approve another shipment.

The team should decide that behavior in advance. The agent might ask for the serial number, retry the order lookup, or hand the case to a representative. It should explain what remains unverified instead of filling the gap with a plausible answer.

Freshness needs the same treatment. “Use current data” is too vague to test. Specify which facts need to be checked again before approval and what happens if that check fails. A product description may tolerate a delay that an order’s replacement status cannot.

Even a fast connection can return outdated information. The source may be delayed, or the record may have changed after retrieval. When the system is about to create the replacement, the operation that creates it should recheck the relevant state and permissions.

Gather the facts needed for this decision, keep their sources visible, and recheck state and permissions before taking action.

Decide which source answers which question

The agent may encounter information that disagrees. A conversation says the device is covered, while the warranty record says coverage expired. An old policy document allows a replacement that the current regional policy excludes.

There is no single ranking that solves every disagreement. The team needs to identify the source responsible for each question. The order system may own shipment status. The warranty service may determine coverage. A policy document may explain an exception that requires human approval.

Record those choices so the system can apply them consistently. Include the policy version and relevant dates with retrieved information. If the conflict cannot be resolved, make it a reason to ask for help.

Conversation history has a different role. Remembering a previous request helps the agent avoid asking the customer to repeat themselves. It does not establish that the replacement is still eligible or that no shipment has been created since then. Memory should help the conversation while the responsible systems establish the facts needed for action.

Access to external data still needs an owner

Zero-copy access allows a platform to work with external data without first copying all of it into another store. That can reduce duplication, but it does not settle what the data means or how reliably it will be available.

For example, a device platform may expose a field called “failure status.” Does it mean the customer reported a fault, the device detected one, or a technician confirmed it? The agent cannot safely treat those meanings as interchangeable.

The team responsible for that source needs to explain the field, its update behavior, and its limitations. The Salesforce team needs to decide how to use it and how the service process behaves when the source is unavailable. Making data reachable does not remove either responsibility.

Write the requirements before refining the prompt

Once the replacement decision is clear, document the information and checks it requires. Architects sometimes call this a context contract: an agreement about what the agent receives and what the system must verify. The useful part is the agreement, which can be written in ordinary language.

For this service process, it should answer:

• Which customer and device must be identified?
• Which systems provide order status, warranty terms, and failure evidence?
• Which source decides each question when information disagrees?
• What must be refreshed before approval?
• What information may the agent access, and who may approve the action?
• What should happen when a required fact is missing or uncertain?
• What evidence should be kept so someone can explain the result later?

Test those requirements with difficult cases: two similar customer records, an outdated warranty document, a device lookup that times out, and a replacement created after the agent first read the order.

These tests reveal whether the process knows when to proceed, when to ask another question, and when to stop. Prompt wording can help the agent communicate those decisions, but the checks need to exist in the system that retrieves information and performs the action.

What the platform may do next

Platforms may take on more of this assembly work. They may select relevant records, attach source details, and flag information that is too old for a requested action. That would reduce the effort needed to prepare useful context.

The team would still need to define the decision and its requirements. A platform cannot infer from a unified profile alone which warranty source the business accepts or who is allowed to approve an exception.

Product names and retrieval features will change. The lasting questions are easier to state: what must the agent know, where is each fact verified, and what happens when it cannot be?

For the customer asking for a replacement, a well-designed agent can explain what it has confirmed and what remains unresolved. Once the required facts and permissions are established, the next challenge is carrying out the replacement and proving that it happened. That is the subject of the next post.

Sources

• Salesforce: Data 360
• Salesforce Architects: Well-Architected Framework
• Salesforce Developers: Get Started with Agentforce

More in This Series

• Post 01: How Salesforce Applications Evolve with AI
• Post 02: What AIforce and Agentforce Add to Salesforce
• Post 03: Agent Script Is a Control-Flow Language