How to build custom copilots using Agentforce Builder

A service employee asks a copilot for a short brief on a Case. The paragraph is accurate, well mannered, and about the right customer. The trace shows a field update the employee did not ask for, on a Case field a Flow also writes. The preview looked finished. The record and the Flow now disagree, and the employee has already moved on to the next tab, trusting the sentence.

A custom copilot is an employee tool with a small job. It is not a second product beside Agentforce, and it is not a place to park every automation the organisation owns. If the job cannot be named in one sentence, it is not one copilot.

Salesforce describes Agentforce, formerly Einstein Copilot, as support for employees in the flow of their work: search for data, create an action plan, and execute it. Agent Builder is how you shape that. Salesforce says you build agents there with platform tools, as standard and custom subagents and actions. Those three pieces are the whole design. Subagent, instructions, action library. A fourth piece, a personality, does not earn a place beside them.

#Start from one job

Name the job before you open the builder. "Help a service employee understand this Case" is a job. "Help the company" is not. The second sentence has no objects, no stop, and no refusal, so every action in the org can argue that it fits.

A service copilot might read the Case, the Account, and the latest related records, then draft a reply the employee sends. A sales copilot might assemble a brief from the Account, open Cases, and open Opportunities. Neither copilot should own the other's actions. The service draft does not move an Opportunity stage. The sales brief does not close a Case. An action left in the library is permission to use it, and the plan will sometimes pick a neighbour of the right one, because the neighbour was legal and the sentence still came out fluent.

Write the job down where the next person to edit the library will see it. One sentence, the objects it may read, the actions it may call, and the writes it must not perform. When someone asks to add "just one more action", the sentence is the test. If the action serves a different job, it belongs on a different subagent. Sharing the Account between the two jobs is fine. Sharing the action list is how the service copilot gains a stage edit it was never meant to have. How those two jobs should read one timeline without writing across it is aligning sales and service on the Account.

#Instructions are the specification

Write instructions as a specification, not as a personality. Include the objects to read, the action to call, the inputs required before the call, and the stop. Include the refusals in the same place: do not edit StageName, do not send the email, do not change ownership, do not close the Case. A refusal buried in a wiki the copilot does not retrieve is not a refusal. It is a hope.

Keep the instruction shorter than the knowledge it points at. If you paste a policy into the instruction, you now have two copies, and they will drift. The copy in the instruction will be the one a future editor is afraid to touch, because it is "what the copilot knows". The employee-facing copilot should search the record and the maintained article. The instruction says what to do when the search finds nothing: stop, and say it found nothing. It does not say to fill the gap with a plausible sentence so the employee is not left looking at a blank draft.

Name the record when several could match. "The Opportunity" is not an identifier when two are open on the Account. Prefer the one the employee named. If they did not name one, say there are two and ask, or draft nothing that depends on which deal it is. A brief that mixes facts from both deals will still read cleanly. It will be about a deal that does not exist.

Consequential buttons stay with the employee. The copilot may prepare a field update or a reply. The employee commits it. Agents may act inside guardrails. A stage change, a send, or a close is consequential, so it is a handoff even when the user of the copilot is on your payroll. An employee can make a bad commit. They can also see the record, notice the wrong Id, and stop. A copilot that commits on their behalf spends that chance. The draft is the work. The button is the decision.

The shape of those instructions, including how to test a refusal when the employee's utterance does not contain the policy, is the prompt that has to live on the subagent. The chat box is the request. It is not the specification.

#Test the plan

Salesforce's description of the employee assistant is search, an action plan, and execution. Your test should score those, not the prose. Write the expected trace before you run the utterance, so the fluent paragraph cannot talk you into moving the expected steps.

Take a Case you already understand. The expected plan might be: read Case, read Account, draft. If the trace shows a field update, the test failed, even when the paragraph was accurate and well mannered. Take an Opportunity the copilot should only read. If the plan writes StageName, the test failed, even when the new stage is the one a person would have picked. The right write, done by the wrong actor, is still the wrong outcome. A Flow or the employee was supposed to commit it.

Check the record Id in each step. A plan that reads a different Opportunity on the same Account, because two are open and the instruction never said which, will still produce a fluent brief. The brief is about the wrong deal. That is a failed test, and it is the one preview theatre misses, because nobody in the room has both Opportunity numbers in their head.

Keep a small set and re-run it when the library grows. New actions change the plan. An action added for a neighbouring team becomes a legal move for yours, and the old utterances will sometimes take it. The set should include a Case that must only be read, an Opportunity that must only be read, a request to send or to move stage, and a search that should return nothing. The last one is there to catch a copilot that invents. The pass is a sentence that says it found nothing, and a trace with no write.

A pass is boring. The steps match, the Ids match, and the reply is allowed to be plain. If the only thing that improved after an edit is the prose, the edit did not improve the copilot.

#What goes wrong

The org-wide copilot fails first. Every team adds its action, because a shared assistant feels efficient and because each addition is small. The plan has too many legal moves, and it picks one that is locally plausible and globally wrong. A service utterance closes nothing, until the day it closes a Case while assembling a brief, because close-case was added for a different conversation and never removed. Split by job. A short library is a control, not a lack of ambition. You can add a second subagent in an afternoon. You cannot easily unpick a month of writes the wide library performed.

The second failure is preview theatre. Someone reads the final sentence, says it sounds right, and ships. The sentence can be right while the plan created a Task on the wrong record, or updated a field the Flow also writes. Open the steps. Two writers on one field do not become acceptable because the user is an employee. The Flow was the owner. The copilot was a second writer, and the employee may not even know the write happened if the draft looked clean.

The third failure is the pasted policy. The instruction contains last quarter's discount rules, the article contains this quarter's, and the draft quotes the instruction because it is closer to hand. The employee sends it. You now have a price in a customer's hands that your own article no longer supports. Delete the pasted rules. Point at the article. Re-run the "search finds nothing" case so the copilot does not reconstruct the deleted rules from memory of the old instruction.

The employee is a running user, and that fact is easy to forget because they are on the payroll. The copilot sees what that user sees, and it can act with what that user can act on. An administrator testing as themselves will pass a trace the employee cannot repeat, or will hide a write the employee's permissions would have blocked and miss a different write they would have allowed. Run the small set as a real service user and a real sales user. If the service user cannot see an amount, the brief must not contain the amount, including as a rounded hint.

There is a second confusion about the word execute. Salesforce's description of the employee assistant includes executing the action plan. Execution, for a consequential step, can be the preparation of a draft the employee then commits. It does not have to mean the copilot presses the button. Read the word against the job. Searching and drafting is execution of the brief. Sending, moving a stage, and closing are commits. If a stakeholder hears "execute" and concludes the copilot should press every button in the library, they have widened the job past the guardrail. The library is how you keep that reading from becoming the configuration. Take the button out. The description of the product does not require you to leave it in.

Ship when the small set passes as the running user the employee actually is, not as an administrator. Then add nothing to the library without running the set again. The difference between a copilot that is still in use in six months and one that was quietly unpinned is usually this discipline, which is part of the wider rollout bar in what separates an Agentforce rollout that is still running in six months. The sentence was never the hard part. The library was.