Salesforce's researchers get better CRM agents by writing the procedure into the prompt

Sort the failures by how loud they are. An agent that writes an illegal SOQL query gets an error back and sometimes repairs it, though Salesforce's researchers note that other attempted repairs produce further mistakes ^[8]. That one at least announces itself in the logs. The quiet failure is schema confusion: the agent treats an order item as a pricebook entry, or a lead as an opportunity, reads the wrong table, and hands back something shaped exactly like an answer ^[9].

The quietest case is ambiguity. Salesforce's own example is a support case transferred between two reps and whether it counts toward either rep's average handling time, both, or neither; the blog says agents usually assume one reading and carry on without noticing a choice was made ^[10]. Here is what teams tell themselves an agent will do with an underspecified task: ask. Here is what the execution traces show it doing: pick.

Put the ceiling against the denominator. At 60 percent completion, more than 856 of the 2140 task instances go unfinished ^[13]; at GPT-4o's rate, more than 1498 do ^[14]. Those are completion rates on scripted business tasks, which is a harder and more useful number than anything measured in sessions or clicks.

What Salesforke calls the remedy is domain-specific knowledge supplied in the prompt or wrapped as a tool ^[7]. Read the procedure finding as an operations statement rather than a prompt tip: instructions on how to do the work only exist if someone has written down how the work is done. The people who can write it are the admins and ops leads who already know which searches want SOSL rather than SOQL's fuzzy matching, which is precisely the fine-grained distinction the agents miss ^[11]. Salesforce sells Agentforce as agents that handle return and refund requests and draft tailored sales pitches ^[12]; the research underneath says the pitch arrives without your business context, and that context is your homework.

So sort candidate tasks on two axes before scoping anything. Axis one: is the correct procedure already written down somewhere a human follows it. Axis two: when the output is wrong, does it look wrong. Written procedure plus visible errors is where to start, because the agent is executing a runbook you can diff. Written procedure plus silent errors needs a checking step budgeted before the agent goes near a report. Unwritten plus visible errors is a documentation project wearing an AI budget line. Unwritten plus silent errors is the average-handling-time metric, and the honest move there is to write the procedure first, which is the work the drop-in agent was supposed to spare you.