AI Pilot – Production

Getting an Agentforce demo to work is the easy part. A good demo needs a clean example, a friendly dataset and a few minutes of someone’s attention. Production needs none of those things. It needs an agent that works on a Tuesday afternoon, with messy data, a busy user and a question nobody planned for.

This is where many Agentforce projects slow down. The pilot looks great, the team is excited, and then the project sits in “almost ready” for months. Nobody decided to stop it. It just never quite goes live.

This post walks through the most common reasons, what each one looks like in practice, and what to do about it. It ends with a checklist, a simple 90-day plan, and answers to questions we hear often. If you have a pilot that is stuck, you should be able to find your situation in here.

Why a good pilot is not the same as a good launch

A pilot answers the question “can this work?” Production answers a harder one: “will this keep working, for everyone, when nobody is watching closely?”

The two stages need different things:

A pilot is run by a small group who want it to succeed. Production is used by people who did not choose it and will only use it if it saves them time.
A pilot uses examples chosen to show the agent at its best. Production uses whatever real customers and employees ask.
A pilot is judged by whether it impresses people. Production is judged by whether it quietly does its job, day after day.

Most of the problems below come from treating production as a bigger pilot. It is a different project, and it needs its own plan.

1. The pilot was built for the demo, not for the job

A pilot often starts with the question “what can the agent do?” That is a fine way to learn the tool, but it is the wrong way to plan a launch. A production agent needs to answer a different question: “what job do we want it to take off someone’s plate?”

What it looks like: The agent can handle a wide range of requests in the demo, but nobody can say which of them it is meant to own. When it gives a weak answer on a harder question, nobody can tell whether that counts as a failure.

Illustrative example: Imagine a service team that pilots an agent to “help with customer questions.” It answers order-status questions well, struggles with billing disputes, and gives confident but wrong answers about returns. Because the goal was vague, there is no clear point at which the team can say “this is ready.”

What to do: Pick one job. For example, “answer order-status questions for existing customers without a person.” Write down what a good result looks like: how many questions it should resolve, what it should hand over, and what mistakes are unacceptable. Add other jobs later, one at a time.

2. The data is not ready

An agent can only work with what it can see. If account records are duplicated, fields are half-filled, or the knowledge articles it relies on are out of date, the agent will repeat those problems, and it will sound confident while it does.

What it looks like: The agent quotes an old policy. It addresses a customer by the wrong name. It tells two people two different things because two records disagree.

What to do: Before the agent goes live, check the sources it actually uses.

Which objects and fields does it read?
Which knowledge articles or documents does it quote?
Who is responsible for keeping each of them current?
When was each last reviewed?

Fixing a handful of key sources usually helps more than any change to the agent itself. Also decide who updates these sources after launch. A clean dataset on launch day does not stay clean without an owner.

3. Nobody owns it after launch

Pilots usually have an enthusiastic sponsor. Production needs an owner: someone who reads the agent’s conversations, notices when it gets something wrong, and decides what to change.

What it looks like: The agent launches, a few early problems come up, and nobody is responsible for fixing them. People stop trusting it, quietly stop using it, and the project is later described as a failure, for reasons that were easy to fix.

What to do: Name an owner before launch, and give them real time for the job, not “when they can.” Their weekly routine can be simple:

Read a sample of the agent’s conversations.
Note what it got wrong and why.
Decide whether the fix is in the instructions, the data, or the process.
Report the results to the team.

4. There is no plan for what the agent should not do

Every production agent needs boundaries. When should it hand over to a person? What should it refuse to answer? What should it never change in a record?

What it looks like: The agent answers something it should have passed to a person, or someone worries that it might, and the team refuses to switch it on for customers.

What to do: Decide the rules with the people who will be affected. Questions to settle:

Which topics always go to a person?
What should the agent say when it does not know?
Which actions can it take on its own, and which need approval?
How does a customer reach a person at any point?

A clear, easy handoff to a human is often what makes a team comfortable launching in the first place.

5. Success is never measured

“It seems to be working” is not a measure. Without numbers, you cannot tell whether the agent is helping, and you cannot defend the project when someone questions it.

What to do: Choose two or three numbers before launch. Good candidates:

The share of conversations the agent resolves without a person
How often people ask to speak to a human
How long a task takes compared with before
Customer or employee feedback after a conversation

Look at them every week for the first month. Measuring also protects the project. When you can show what the agent has improved, the next round of investment is much easier to approve.

6. The rollout is all at once

Switching an agent on for everyone on day one makes every early mistake public. A smaller rollout lets you find problems while they are cheap to fix.

What to do: Start with one team or one type of request. Review the numbers and the conversations after a few weeks. Widen the rollout when the results are steady, and pause if they are not. A slower start often gets to a full launch sooner, because the team trusts the result.

7. The people who will use it were not part of the plan

The agent can be technically fine and still go unused, because the people who work alongside it were never asked what they need.

What it looks like: Service staff do not trust the answers. Sales staff do not know when the agent has already spoken to a customer. People work around it.

What to do: Involve the future users early. Ask what takes up their time, what they would hand over, and what they would never hand over. Show them the agent before launch and fix what they point out. Explain what changes for them and what does not.

A 90-day plan from pilot to production

This is a simple outline, not a fixed formula. Adjust the timing to your team.

Days 1 to 30: Narrow and prepare

Choose one job and write down what success looks like.
Check the data and knowledge sources the agent uses, and fix the biggest gaps.
Name an owner and agree the handoff and boundary rules.

Days 31 to 60: Launch small

Roll out to one team or one request type.
Review conversations weekly and track your two or three numbers.
Fix instructions, data and process issues as they appear.

Days 61 to 90: Widen and review

Expand to more users or request types if the numbers are steady.
Share results with the wider team.
Decide what the next job for the agent should be.

A checklist before you go live

One clear job, with a written definition of success
The data and knowledge sources the agent uses have been checked
A named owner with time set aside
Clear rules for handing over to a person and for what the agent must not do
Two or three measures, reviewed weekly
Future users have seen the agent and given feedback
A staged rollout plan

Frequently asked questions

How long should a pilot last? Long enough to learn what the agent can and cannot do on real requests, usually a few weeks, not months. A pilot that runs much longer than that often means the team has not decided what “ready” looks like.

Should we fix our data before starting an Agentforce project? Fix the data the agent will actually use, not all of it. Start with the objects, fields and articles for your first job, and improve from there.

Who should own an Agentforce agent after launch? Someone close to the work the agent does, for example a service or sales operations lead, supported by a Salesforce admin. It should be a named person, not a committee.

What if the agent gets something wrong in production? It will, sometimes. That is why you set handoff rules, review conversations every week, and start with a limited rollout. The aim is to catch mistakes early and fix the cause, not to avoid mistakes entirely.

Do we need a partner to take an agent to production? Not always. A partner helps most when your team is new to Agentforce, short of time, or stuck between a working pilot and a launch.

Where to start?

If you have an Agentforce pilot that looks good but has not gone live, go through the checklist above and see which gaps apply. Usually it is two or three, not all seven, and they are fixable.

At Aekot, we help teams take Agentforce from pilot to production as a Salesforce consulting and Agentforce implementation partner. If your project is stuck, we would be glad to talk through where.