Building and Scaling Production-Ready AI Agents: Lessons from Agent Force

salesforce · Tech · 2023 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise agent platform operations

Salesforce needed AgentForce agents to move beyond easy demos into production-grade enterprise workflows, where customers need grounded answers, autonomous or approved actions, trust controls, multi-channel deployment, evaluation, monitoring, latency control, and cost-effective optimization before they will turn agents on for employees or customers.

Constraints:

• early LLM and agent demos can be built quickly, but production requires much higher accuracy and trust
• agentic workflows are non-deterministic and hard for enterprise customers to debug
• headless agents embedded in workflows require monitoring beyond conversational UI testing
• RAG pipelines can fail at multiple stages, from retrieval to grounding and citation
• single-turn tests do not represent production use
• fine-tuning and grounding must respect enterprise data trust boundaries

Architecture

Salesforce framed AgentForce as a low-code/no-code platform and toolchain for building, testing, deploying, and monitoring enterprise agents. An agent definition includes a job, enterprise data access, actionability, guardrails, and channel exposure. Production readiness comes from an upgraded lifecycle around AI-assisted evaluation, human spot checks, synthetic batch tests, fast feedback, RAG pipeline monitoring, and selective fine-tuning of smaller models when prompt engineering and RAG no longer deliver enough quality, brand voice, latency, or cost control.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  agentforce-platform[AgentForce platform] --> agent-builder[Agent Builder]
  agentforce-platform --> agent-definition[Agent definition]
  agentforce-platform --> trust-layer[Trust layer]
  agentforce-platform --> evaluation-lifecycle[Evaluation lifecycle]
  agentforce-platform --> production-monitoring[Production monitoring]
  agent-builder --> agent-definition
  agent-builder --> batch-test-generator[Batch test generator]
  agent-definition --> enterprise-knowledge[Enterprise knowledge]
  agent-definition --> action-layer[Action layer]
  agent-definition --> trust-layer
  agent-definition --> channel-layer[Channel layer]
  enterprise-knowledge --> rag-pipeline-monitor[RAG pipeline monitor]
  action-layer --> channel-layer
  channel-layer --> production-monitoring
  evaluation-lifecycle --> ai-assisted-evaluator[AI-assisted evaluator]
  evaluation-lifecycle --> batch-test-generator
  evaluation-lifecycle --> human-review-loop[Human review loop]
  ai-assisted-evaluator --> human-review-loop
  human-review-loop --> production-monitoring
  rag-pipeline-monitor --> production-monitoring
  trust-layer --> fine-tuning-layer[Fine-tuning layer]
  fine-tuning-layer --> production-monitoring

Components

Data flow

A team defines an AgentForce agent's job, connects it to enterprise data, configures actions, guardrails, and channels, then tests it through eval criteria written into the PRD. AI-assisted evaluation scores generated responses across metrics, humans spot-check outputs and provide thumbs-up/down feedback, and batch testing can synthesize 100 or 200 test cases. In production, feedback, event logs, and RAG-stage metrics reveal failures in query processing, retrieval, chunking, LLM handoff, response quality, citation, and guardrail behavior. When quality, brand voice, latency, or cost plateau after prompting and RAG, the team fine-tunes smaller models inside Salesforce trust boundaries.

Why this architecture

Salesforce argues that enterprise agents need a full lifecycle because the hard problem is not building a demo; it is proving trust for non-deterministic systems. The platform shape keeps agent authoring low-code, but wraps it in PRD-level evals, synthetic batch tests, human review, RAG observability, and continuous optimization. Fine-tuning is intentionally late in the path: teams should first exhaust prompt engineering and RAG, then fine-tune smaller models when quality, brand voice, latency, or cost-to-serve require a more specialized model inside trust boundaries.

Models used: standard LLMs · proprietary LLMs · open-source LLMs · fine-tuned small language models · 10 billion parameter model

Scale

• The talk frames Salesforce as serving virtually any large enterprise customer.
  “we build CRM app and uh we have pretty much any big customer you can think of they use Salesforce”transcript, stated
• The production-readiness target is moving initial agent accuracy from about 60% to roughly 80-90%, depending on the domain.
  “optimizing from this initial 60% of the accuracy to 80 or 90% whatever your threshold is based on on the use case”transcript, stated
• Salesforce characterizes demo-building as about 10% of the work and trust-building as the remaining 90%.
  “building the flashy demo is only 10% of the work and rest 90% of the hard work is actually building the trust”transcript, stated
• Fast teams can test an agent change within about 30 minutes.
  “they make a change for example they add a new new topic into the agents and then if they can test within that that thing into 30 minutes”transcript, stated
• Batch testing can generate 100 or 200 additional test cases automatically.
  “I want to create uh whatever like 100 more test cases or 200 more test cases those test cases are generated automatically”transcript, stated
• Fine-tuning smaller models is proposed as a way to serve targeted use cases with a 10 billion parameter model at comparable quality and lower cost.
  “why can't I take a 10 billion parameter model and then uh tune it to my specific use cases and then start serving at the same quality at a faster speed and at a lower cost”transcript, stated

Alternatives considered (roads not taken)

Treat early demos as production readiness

Rejected because: The speaker says easy demos often start around 60% accuracy, while production needs much higher accuracy and trust work.

Single-prompt or single-turn testing before production

Rejected because: Salesforce argues single-turn tests are not enough to launch and that teams without batch testing hit a wall when scaling usage.

Fine-tune from the beginning

Rejected because: The recommended path is standard LLMs, prompt engineering, and RAG first; fine-tuning comes after those options plateau.

Prompt engineering alone for brand voice

Rejected because: The speaker says it can require very large prompts, increasing token count and cost, while fine-tuning can align brand voice more scalably.

Largest model for every request

Rejected because: The talk recommends data-driven decisions about when a targeted, fine-tuned smaller model can preserve quality while reducing cost and latency.

Patterns

eval-driven-development (quality)

Salesforce makes evaluation criteria part of product requirements so teams know the acceptance threshold before launch.

llm-as-judge (evaluation)

Agent responses are evaluated by AI across metrics before humans spot-check and feed back corrections.

human-in-the-loop-gate (quality)

Salesforce combines AI-assisted evaluation with human spot checks, thumbs-up/down signals, and feedback loops.

synthetic-data-generation (evaluation)

The platform can generate large test-case sets because hand-authoring hundreds of examples is difficult.

observability-tracing (operations)

Salesforce recommends monitoring every RAG stage and production feedback signal so teams can debug opaque agent behavior.

rag-retrieval (retrieval)

Agents are grounded in enterprise knowledge through RAG, but the pipeline requires quality monitoring over retrieval, chunks, citations, and generation.

fine-tuning-adaptation (model-ops)

Fine-tuning is used after prompt and RAG optimization to improve brand voice, domain specificity, structured output, summarization, and cost-to-serve.

cost-aware-routing (cost)

Salesforce argues for fine-tuned smaller models in targeted use cases to reduce cost-to-serve and latency without defaulting to the largest model.

safety-policy-enforcement (trust)

AgentForce includes a trust layer and guardrails as a core agent attribute for enterprise deployment.

Tradeoffs

Production readiness strategy

Chose evaluation, monitoring, trust, and feedback loops over shipping after a flashy demo.

Rationale: A demo may show the possibility, but production requires proof that the agent can meet accuracy, trust, and monitoring expectations.

Optimization sequence

Chose standard LLM, prompting, RAG, then fine-tuning over fine-tuning from the start.

Rationale: Salesforce describes fine-tuning as the next step after teams exhaust prompt engineering and RAG but still need more quality, brand voice, cost, or latency gains.

Testing approach

Chose batch tests with synthetic cases over a handful of hand-written examples.

Rationale: The speaker says five to ten examples are easy, but production needs hundreds of examples and generated scenarios to test variation.

Evaluation governance

Chose AI-assisted evaluation plus human-in-the-loop review over fully automated scoring alone.

Rationale: AI scoring scales response assessment, while human spot checks and thumbs-up/down feedback keep the loop accountable.

Model serving strategy

Chose fine-tuned smaller models for targeted use cases over largest general model for all requests.

Rationale: For targeted CRM tasks, a tuned smaller model can preserve quality while improving speed, latency, and cost-to-serve.

Gotchas (what bit them)

A compelling demo can hide most of the production-readiness work.

Root cause: Early demos are easy to build, but moving from roughly 60% accuracy to an 80-90% production threshold requires trust, testing, and optimization.

Resolution: Treat the demo as the beginning of the lifecycle and invest in evaluation, monitoring, fast feedback, and continuous optimization.

Agentic workflows are hard to debug as black boxes.

Root cause: A bad response can involve many LLM calls, latency points, knowledge choices, RAG chunks, citations, and guardrail decisions.

Resolution: Instrument each step so teams can backtrack from a response to the calls, retrievals, chunks, citations, and guardrails involved.

Single-turn tests are inadequate for production launch.

Root cause: A single prompt does not exercise the variety of scenarios, retrievers, models, and component behavior encountered in production.

Resolution: Use batch testing and automatically generated scenario sets before scaling usage or comparing fine-tuned models.

RAG quality fails at several internal stages, not only at final answer generation.

Root cause: Enterprise knowledge lives across PDFs, images, documents, and other systems, and failures can occur in query processing, retrieval, chunking, LLM handoff, response quality, or citation.

Resolution: Define and monitor metrics at every RAG pipeline stage, then iterate on retrieval and generation quality.

Prompt-only brand voice optimization can create unscalable prompts.

Root cause: Capturing enterprise tone, empathy, terminology, and lingo in prompts can grow into very large instructions that raise token count and cost.

Resolution: Use fine-tuning for brand voice and task-specific behavior once prompt engineering and RAG have plateaued.

Fine-tuning creates enterprise data-boundary concerns.

Root cause: Customers do not want their data used to tune base models or leave trust boundaries.

Resolution: Keep customer fine-tuning inside the platform's trust boundaries and explicitly avoid using it to train base models.

Evaluation

Salesforce's production-readiness process starts with PRD-level eval acceptance criteria, then uses AI-assisted response evaluation, human spot checks, thumbs-up/down feedback, synthetic batch testing, component testing for prompts/retrievers/models, RAG pipeline metrics, production monitoring, and continuous optimization decisions around cost-to-serve and fine-tuning.

Metrics: accuracy threshold · response quality · prompt quality · retriever quality · model performance · test-case coverage · human thumbs-up/down feedback · RAG query-processing quality · retrieval quality · chunk handoff success · citation and grounding quality · cost-to-serve · latency

Outcomes

• Salesforce positioned AgentForce as a build, test, deploy, and monitor platform for enterprise agents
• the recommended production path centers on evals, fast feedback, production monitoring, and continuous optimization
• the platform supports batch testing with automatically generated 100- or 200-case scenario sets
• Salesforce uses fine-tuning for CRM cases such as brand voice alignment, summarization, structured output, and domain-specific tasks
• the talk argues that fine-tuned smaller models can improve the speed, precision, latency, and cost balance for targeted use cases
• customer data boundaries are treated as a platform requirement for fine-tuning

The transcript is a vendor presentation rather than a measured customer study. It gives production targets and operating benchmarks such as 60% to 80-90% accuracy improvement, 30-minute change-test loops, 100/200 generated test cases, and 10B-parameter smaller-model tuning, but it does not provide audited before/after deployment metrics.