Prompts for the work around an Agentforce project: finding out what agents already exist, whether the org is ready for them, what an agent would run into, how to plan the build, and how to test the result. They read your org's real configuration, so each answer names the components involved. Where a prompt produces a document, it comes in a short form you can type in a few seconds and a fuller form for when you want more control.
Two conventions in the prompts below:
‹Opportunity›means replace this with your own object, agent, field or process«option A | option B»means pick one
Start with one object or one agent per prompt. A focused prompt is faster, and its answer is easier to check, than one that tries to cover the whole org.
Find out where you stand
List the agents
List the Agentforce agents in this org, with the exact description stored on each, and whether each version is active.
What an agent covers
What topics does the ‹agent name› agent cover? One line on each.
Then go one level down, in the same conversation:
For its ‹topic name› topic, list the actions it can take.
Treat a topic or action list as a first map. Confirm it in Setup before you present it as the full inventory.
Agentforce readiness assessment
Type this:
Produce an Agentforce readiness assessment for this org, as an HTML page. Focus on ‹Account, Opportunity and Case› and on the automation an agent would have to work alongside, including flows, Apex triggers and validation rules. Count only active flows, active validation rules and active Apex triggers, and list the inactive ones separately.
For more control over what the assessment covers:
Produce an Agentforce readiness assessment for this org. Cover the data foundations an agent would rely on, the automation an agent would have to coexist with on ‹the Opportunity object›, the security model that would govern what an agent can see and do, including the org-wide defaults and sharing rules, and the specific configuration that would need cleaning up first. Rank the gaps by how much they block an agent deployment. Treat only active flows, validation rules and Apex triggers as blockers, and list inactive ones separately. Name the components. Flag any number that should be confirmed with a direct query, and give me the query.
Naming the objects an agent will work with keeps the assessment on the part of the org that matters, and the ranking puts the blockers at the top. You can ask for a different reader in the same conversation, for example "Rewrite this for a CIO".
What an agent would run into when it writes a record
An agent that writes to a record fires everything already attached to it.
When an agent creates or updates ‹an Opportunity or a Case› from ‹a dictated note›, list everything that would run in execution order: flows, triggers, validation rules, assignment and escalation. Only include active components, and name every Apex trigger on the object, custom ones first. Which of those could reject or alter what the agent writes? Rank them by how likely they are to cause a failed or wrong update.
What an agent can see and change
An agent can only touch what the user it runs as can touch, so the access review is part of readiness.
Who can see and edit ‹Opportunity Amount› in this org? Which profiles and permission sets grant it, and what looks too broad?
The Security and access review playbook covers the wider version. Open it from Playbooks, and see Playbooks: ready-made prompts that produce a finished document.
Names and descriptions agents lean on
Agents work from the names and descriptions in your org. Vague or missing ones lead to wrong answers.
Produce a naming and documentation hygiene report for ‹the Opportunity object› in this org. Cover components whose API name doesn't match their label or purpose, misspelled API names, auto-generated opaque names, missing descriptions on flows and fields, and inconsistent conventions between similar components. Report the names exactly as they are, and do not correct them silently. Recommend a naming standard based on what the org already does well.
Plan the project
Run these three in order, in the same conversation. The first describes the project and the next two build on it.
Frame the project
Describe the project the way you would to a colleague. Who uses it, what they ask for, and what the agents should do is enough.
This engagement is a Salesforce architecture review for ‹a company and what it does›. The main use case is ‹the Agentforce use case, in a few sentences: who uses it, what they ask for and what the agents should do›. The company is «live | not live yet» and ‹its proofs of concept exist only in a sandbox›. Help me structure this review. Where should we start, what are the workstreams, what will the project look like, and what questions should I ask the client?
Design the agent structure
First list the Agentforce agents that already exist in this org, as agents with their type and active version rather than their planner bundles. Then design the Agentforce structure for the project described above. Propose the sub agents, and for each one give its purpose, topics, actions, the objects and fields it touches, which steps must stay human-approved, and how it hands off to the next. Then say which of the existing agents and flows we can reuse.
Break it into stories
Break this into phases and user stories with acceptance criteria against this org, with a build order. Base them on active components only, and mark the stories that depend on a client decision.
Test the agent
Write a test-scenario CSV for our ‹agent name› agent: 50 things a user might ask, with the topic and action each one should hit and the expected response. Read the agent's topics and actions from its definition in the org and use their exact names. If you cannot confirm an action is enabled, leave the expected response blank and say why.
Rename the column headings to match the template in Salesforce's Testing Center before you import it.
Getting the best out of it
Name the agent or object. "The Case Support agent" or "the Opportunity object" gets a more accurate answer than "our agents" or "the org".
Ask for a document when you need to share it. Add "as an HTML page", "as a PDF" or "as a Word document" and the answer arrives as something you can send. HTML is the easiest to read on screen.
Ask it to flag numbers worth confirming. Adding "flag any number that should be confirmed with a direct query, and give me the query" gives you the figure and the SOQL to check it.
Give it the values it can't see. If an answer depends on a picklist's real values, a licence count or something stored as data rather than configuration, paste it into the prompt.