Last October, Robert Soesemann, a Senior Principal Architect at Aquiva Labs, told Salesforce Ben something that stuck with me: "No one wants to be the first to take the risk."
He was talking about Agentforce adoption. The technology was live, the demos were impressive, and the enterprise pricing was public. But the ecosystem was frozen. Watching. Waiting for someone else to go first.
Four months later, the numbers tell a different story. 18,500 customers have signed Agentforce deals. $540 million in ARR. 330% year-over-year growth. Salesforce's entire strategic narrative now orbits a single product family that barely existed 18 months ago.
And yet.
When you look past the investor deck and into the orgs that are actually trying to deploy agents, a pattern emerges. 87% of sales organizations report using AI in some capacity. But more than half of all deployed agents are operating in silos, disconnected from the systems they're supposed to augment. The gap between "we're using AI" and "our AI is actually integrated into how we work" is enormous. And it's growing.
I'm calling it the Agent Readiness Gap. It's the distance between what Agentforce can do on a demo stage and what your org can actually support in production. It's not a technology problem. It's an infrastructure, data, governance, and talent problem. And everything in this newsletter — the earnings, the research, the release notes, the career shifts — maps back to it.
TL;DR:
- $540M ARR, 18,500 customers, Wall Street betting on Feb 25 earnings, CRM stock 28% down YTD
- 87% of sales orgs use AI but half of all agents work alone in silos — the readiness gap is widening
- Spring '26 tools: Agent Script for hybrid reasoning, Canvas View, GraphQL mutations in LWC, TypeScript support for base components
- 9 common Agentforce implementation failures are predictable and preventable — Knowledge Data Libraries are the fix for hallucination
- The admin role is splitting in two: config execution (shrinking, commoditizing) vs AI orchestration ($180K-$300K+ and climbing)
In this newsletter:
- Part 1: The News — Wall Street, the State of Sales, and the Connectivity Benchmark all point to the same gap
- Part 2: The Releases — Spring '26 ships the tools to close it (if you know where to look)
- Part 3: The Guide — 9 ways Agentforce implementations fail, and how Knowledge Data Libraries change the grounding equation
- Part 4: The Roles — the admin role is splitting, and the job market is repricing around agent skills
If someone forwarded this to you, welcome. This newsletter breaks down the Salesforce ecosystem's most important developments into analysis you can act on. Subscribe to get it weekly.
The Releases
Agent Script: The Architecture That Changes Everything
If there is a single release feature that addresses the readiness gap directly, it's Agent Script.
Agent Script is Salesforce's new hybrid reasoning framework for Agentforce agents. It lets builders combine deterministic code with natural language prompts in a single agent definition, giving you the predictability of programmed logic with the flexibility of LLM-powered reasoning.
Before Agent Script, you had two bad options. You could build a fully deterministic agent — reliable but rigid, unable to handle the natural variation of real conversations. Or you could build a fully autonomous agent — flexible but unpredictable, prone to hallucination, and nearly impossible to govern. Most production deployments ended up as awkward hybrids, stitched together with Topics, Actions, and custom Apex handlers in ways that were fragile and hard to maintain.
Agent Script eliminates that false choice. Here's how it works:
Procedural logic uses the -> operator. When you need the agent to follow a specific sequence — verify identity, check account status, look up case history — you define those steps with ->. They execute in order, every time, with no LLM discretion.
Natural language prompts use the | operator. When you need the agent to reason, empathize, or handle ambiguity — "the customer sounds frustrated, acknowledge their concern before proceeding" — you write prompt text prefixed with |. The LLM handles interpretation within the boundaries you've defined.
Slot-filling uses ... syntax. When the agent needs to collect information from the user — name, account number, issue description — you define slots with ... and the agent handles the conversational collection naturally, asking follow-up questions if the user's response is incomplete.
Linked variables connect slots to Salesforce data. A collected account number can be linked directly to a SOQL query, a record lookup, or a Flow input. No middleware. No custom code to pass values between conversation layers.
Available when conditions control which scripts activate based on context. An agent can have multiple scripts and automatically select the right one based on the customer's profile, the channel they're using, or the state of their case.
The architectural significance of Agent Script is hard to overstate. It's the first framework that lets builders encode business rules, compliance requirements, and conversational guardrails into a single, readable, testable artifact. Before this, agent governance was an afterthought — you built the agent, deployed it, and then tried to figure out how to audit and constrain it. Agent Script makes governance a design-time concern, not a runtime scramble.
Developer Experience: The Platform Catches Up
Beyond Agent Script, Spring '26 delivers a set of developer experience improvements that collectively signal where the platform is heading.
GraphQL mutations in LWC are now generally available. After a long beta, Lightning Web Components can now perform GraphQL mutations directly — creating, updating, and deleting records through the GraphQL wire adapter without routing through Apex. For developers building data-intensive UIs, this eliminates an entire layer of boilerplate code and brings LWC closer to the patterns used in modern web development.
Canvas View is a new UI surface for agents. Instead of agents being limited to chat interfaces and embedded panels, Canvas View lets builders design rich, visual agent experiences with custom layouts, interactive elements, and contextual data displays. It's the difference between an agent that talks to you and an agent that shows you.
TypeScript support extends to base Lightning components. The beta TypeScript support for LWC now includes type definitions for Salesforce's standard component library, which means developers get autocomplete, type checking, and compile-time error detection across the full LWC surface — not just custom components.
OmniStudio deployment improvements streamline the packaging and migration of OmniStudio configurations across environments. For ISVs and enterprise teams using OmniStudio, this addresses one of the most persistent pain points in the deployment pipeline.
File size limits increase to 10GB. Salesforce raised the maximum file size for Content documents from 2GB to 10GB. For industries that work with large files — engineering drawings, medical imaging, legal document packages — this removes a limitation that previously required external storage workarounds.
The GEO toggle lets admins control whether generative AI features are enabled or disabled at the org level. This is a governance feature disguised as a setting — it gives compliance teams a single switch to manage AI exposure across the entire platform.
Claude 3.7 Sonnet routing is now available through the Einstein Trust Layer. Agentforce agents can route specific reasoning tasks to Anthropic's Claude 3.7 Sonnet model, adding another option to the model selection layer alongside OpenAI and Salesforce's native models. The ability to route different tasks to different models based on performance characteristics, cost, or compliance requirements is a sign of the multi-model future that production agents will operate in.
The Guide
Lightning/Classic Taught Us This Lesson Already
Every Salesforce professional over the age of 30 remembers the Lightning migration. Classic worked. It was ugly, it was limited, but it worked. And when Salesforce told the ecosystem to move to Lightning, the reaction was exactly what you'd expect: some teams moved early and got the advantages. Most waited. And the ones who waited too long got stuck running two interfaces simultaneously, doubling their maintenance burden and confusing their users.
Agentforce is the same migration on a larger scale. The technology works. The early adopters are seeing real results. And the majority of the ecosystem is watching, waiting, and accumulating technical and organizational debt that will make the eventual migration harder.
The difference this time? The gap between early adopters and late movers is measured in competitive advantage, not just user interface preferences. When your competitor's agents are handling 130,000 leads while your sales team is manually researching prospects, that's not an inconvenience. That's a market position problem.
Here are the nine ways Agentforce implementations fail, organized into three categories. Every one of them is predictable. Every one of them is preventable. And every one of them maps back to the readiness gap.
Category 1: Foundation Failures
These are failures that happen before you write a single prompt or configure a single agent. They're organizational and strategic, and they're the most common reason Agentforce projects stall.
Failure #1: No operating model. Teams deploy agents without defining who owns them, who monitors them, who updates them, and who's accountable when they go wrong. The agent launches, runs for three weeks, encounters an edge case nobody planned for, produces a bad customer interaction, and gets turned off. Nobody turns it back on because nobody owns it.
Failure #2: No business outcomes defined. The project starts with "let's deploy Agentforce" instead of "let's solve this specific business problem." Without a defined outcome — reduce case resolution time by 20%, increase lead response rate by 3x, cut research time by 30% — there's no way to measure success, no way to justify continued investment, and no way to iterate intelligently.
Failure #3: Data isn't ready. This is the big one. 74% of organizations report spending significant effort on data cleansing before they can deploy agents effectively. The State of Sales data makes the connection explicit: 79% of top performers rate their data quality highly, versus only 54% of underperformers.
Agents don't create data quality. They expose data quality. An agent grounding on a Contact object with 40% duplicate records, inconsistent formatting, and missing fields will produce outputs that are 40% unreliable. And unlike a human user who can visually scan a record and mentally correct for bad data, an agent treats every record as equally authoritative. Bad data in, confidently wrong answers out.
Category 2: Technical Debt
These are failures that emerge from the existing state of your Salesforce org — the accumulated decisions, shortcuts, and deferred maintenance that were invisible to human users but are fatal to autonomous agents.
Failure #4: Governor limit conflicts. Agents operate at machine speed. A well-configured agent can execute dozens of actions in seconds — querying records, updating fields, triggering flows, sending notifications. Each of those actions consumes governor limits. Orgs with automation architectures that were already pushing limits with human-speed usage hit walls immediately when agents start operating.
The fix isn't just optimizing individual transactions. It's rearchitecting automation patterns to account for agent-scale throughput. That means auditing every trigger, every flow, every process builder (yes, some orgs still have them) for cumulative limit consumption.
Failure #5: Permission gaps. The Salesforce security model was designed for human users with relatively predictable access patterns. An agent operating on behalf of a user needs permissions that match the agent's capabilities, not just the user's role. If the agent can look up any account but the user's sharing rules restrict visibility to their territory, you have a conflict. If the agent can update opportunity stages but the user's profile restricts stage editing, you have a conflict.
These conflicts don't produce error messages. They produce silent failures — the agent attempting an action, being blocked by permissions, and either skipping the step (producing incomplete results) or generating a vague error that neither the user nor the agent can interpret.
Failure #6: Automation conflicts. Most Salesforce orgs have accumulated layers of automation over years — triggers, workflows, process builders, flows, and custom Apex handlers that fire in response to data changes. When an agent updates a record, it triggers the same automation cascade that a human update would. But the agent might update 50 records in rapid succession, triggering 50 cascades simultaneously, creating conflicts, loops, and failures that never occurred when a human was clicking through one record at a time.
Category 3: Governance Vacuum
These are failures that stem from the absence of oversight, monitoring, and control structures for autonomous agents.
Failure #7: No escalation paths. Agents encounter situations they can't handle. That's not a bug — it's a design reality. The failure is not having defined, tested, graceful escalation paths. When the agent can't resolve a case, what happens? Does it transfer to a human? Which human? With what context? If the escalation path isn't defined, the agent either loops (trying to resolve what it can't), stalls (leaving the customer in limbo), or hallucinates (making up a resolution that sounds plausible but isn't).
Failure #8: No monitoring or observability. You can't govern what you can't see. Most organizations deploying agents have no systematic way to track what their agents are doing, what data they're accessing, what decisions they're making, or how those decisions are affecting business outcomes. Without observability, you're flying blind — and the first indication of a problem is often a customer complaint, a compliance violation, or an executive asking why an agent just emailed 10,000 contacts with incorrect information.
Failure #9: No compliance framework. The Connectivity Benchmark found that 42% of IT leaders cite compliance as a major concern with agent deployment. 41% cite AI expertise gaps as a barrier. And 86% cite complexity as their primary challenge. These aren't independent problems — they're the same problem viewed from different angles. Without a compliance framework that defines what agents are allowed to do, what data they can access, and what decisions they're authorized to make, every agent deployment is a compliance risk.
NexGen's analysis of Agentforce implementation failures found that failures #5, #6, #8, and #9 consistently appear together. Permission gaps enable automation conflicts. Automation conflicts go undetected without monitoring. Unmonitored agents violate compliance policies. The governance vacuum creates a cascading failure pattern that's predictable but, in most orgs, isn't predicted.
Knowledge Data Libraries: The Fix for Hallucination
One of the most significant Spring '26 capabilities for addressing the readiness gap is Knowledge Data Libraries. This feature fundamentally changes how agents access and reason over organizational knowledge.
Before Knowledge Data Libraries, grounding agents on your organization's information required stitching together Data Cloud, Knowledge articles, file attachments, and custom integrations in ways that were complex, brittle, and difficult to maintain. Agents would search across broad data sets and hope the LLM could extract the right answer from a sea of context. When the context was noisy or contradictory, agents hallucinated — producing answers that sounded authoritative but were factually wrong.
Knowledge Data Libraries provide a structured, curated surface for agent grounding. You define libraries of authoritative content — product documentation, policy documents, pricing sheets, compliance guidelines, internal procedures — and agents query those libraries through the "Answer Questions with Knowledge" action. The agent doesn't search everything and hope. It searches the right library for the right context, with the right access controls.
This is the architectural difference between an agent that "knows about your company" and an agent that "knows your company's actual answers to specific questions." The first produces plausible outputs. The second produces accurate outputs.
The hallucination reduction is the headline benefit, but the governance benefit is equally important. Knowledge Data Libraries give you a clear, auditable surface for controlling what information agents can access. If an agent shouldn't have access to internal pricing for enterprise deals, you don't include that library in the agent's configuration. The access control is structural, not behavioral — you're not hoping the LLM knows to avoid certain topics. You're ensuring it doesn't have access to them in the first place.
The Implementation Readiness Question
Every org considering Agentforce needs to answer three questions before writing a single prompt:
-
Is your data agent-ready? Not "is your data clean" — that's necessary but not sufficient. Is your data structured, governed, and accessible in ways that support autonomous reasoning? Are your Contact records deduplicated? Are your Account hierarchies accurate? Are your Opportunity stages consistently applied? Are your Knowledge articles current and authoritative?
-
Is your security model agent-compatible? Not "do you have security" — every org has security. Does your security model account for autonomous agents operating at machine speed across your data? Do your permission sets support agent-specific access patterns? Can you audit what an agent accessed and why?
-
Is your governance framework defined? Not "do you have policies" — every org has policies somewhere. Do you have specific, enforced, monitored governance for autonomous agents? Who owns the agent? Who monitors it? What happens when it fails? Who's accountable?
If you can't answer all three with specifics, you're in the readiness gap. And every day you deploy agents without closing that gap, you're accumulating risk that compounds.
The Roles
The Admin Role Is Splitting in Two
Something is happening to the Salesforce Admin role that hasn't happened since the introduction of Lightning. The role is splitting, and the two halves are heading in very different directions.
Half one: Configuration Execution. This is the traditional admin role — building reports, managing users, configuring page layouts, creating validation rules, maintaining data quality. This work isn't disappearing, but it's shrinking. AI-powered Flow generation, Agentforce in Setup, and natural language configuration tools are automating the routine configuration tasks that used to consume most of an admin's day. The work that remains is becoming increasingly commoditized.
Half two: AI Orchestration. This is the emerging role — designing agent architectures, configuring Agent Scripts, managing Knowledge Data Libraries, building governance frameworks, monitoring agent performance, and integrating agents into business workflows. This work is expanding rapidly, requires judgment and strategic thinking that AI tools can't replicate, and commands significantly higher compensation.
Thomas Morgan, who has been interviewing Salesforce professionals across the ecosystem for his ongoing interview series, captured the tension: admins see the role changing beneath their feet, but the direction of change isn't clear to most of them yet. They know AI is reshaping what they do. They don't know what the new steady state looks like.
Vicki Moritz-Henry, a veteran Salesforce admin and community leader, described it differently: "The admin role isn't shrinking. It's growing wider. The problem is that 'wider' means you need skills that didn't exist two years ago — data governance, agent configuration, prompt engineering, compliance monitoring. The admins who add those skills will thrive. The ones who don't will be competing for a shrinking pool of traditional configuration work."
Dave Massey, who's built a following around practical Salesforce admin content, put the economics in sharp focus: "The admins who get paid the most aren't the ones who close the most tickets. They're the ones who create the most value. And right now, the highest-value work an admin can do is make their org agent-ready."
Tim Combridge, known in the Salesforce community for his hands-on technical content, demonstrated what the new admin skillset looks like in practice with his "Agentforce Vibes" work — deploying agents using Agent Script in sandbox environments and documenting the real-world configuration patterns, edge cases, and failure modes. This is the kind of exploration that separates the admins who will own the AI orchestration half from those who'll be limited to the configuration execution half.
The Agentic AI Job Market
The job market data confirms what the role split suggests. The numbers are dramatic.
Job postings mentioning "Agentic AI" or "AI Agent" skills have increased by 986% year-over-year. That's not a typo. Nearly ten times more job postings are explicitly seeking agent-related skills than a year ago. Gartner predicts that by 2028, 40% of existing Salesforce admin roles will be redefined to include agent orchestration responsibilities.
The compensation data follows the demand signal. Roles that combine traditional Salesforce administration with agent architecture, data governance, and AI orchestration are commanding salaries in the $180,000-$300,000+ range, depending on geography, industry, and seniority. That's a 40-80% premium over comparable generalist admin roles.
But the premium requires demonstrated capability, not just certifications. Hiring managers are increasingly asking candidates to describe agents they've deployed, governance frameworks they've built, and data quality problems they've solved. The gap between "I've completed the Agentforce Trailhead module" and "I've deployed and governed a production agent" is the gap between a $130K role and a $250K role.
The Skills Bridge
The good news is that traditional Salesforce admin skills aren't irrelevant — they're the foundation for the new role. Here's how they map:
- Flow Builder expertise → Agent Script configuration. The mental model is the same — defining logical sequences with branching conditions. The syntax is different, but the architecture thinking transfers directly.
- Data management → Data Cloud and Knowledge Data Libraries. If you can build a data model, deduplicate records, and maintain data quality, you have the foundation for agent grounding architecture.
- Permission set configuration → Agent governance. Understanding how Salesforce security works at a granular level is the prerequisite for designing security models that account for autonomous agents.
- Report and dashboard building → Agent observability. If you can build reports that track business processes, you can build dashboards that track agent performance, decision quality, and compliance adherence.
- User training and change management → Human-agent interaction design. Understanding how users interact with systems is the foundation for designing how users interact with agents — when to hand off, when to escalate, when to keep the human in the loop.
The bridge exists. But crossing it requires intentional investment in new skills, not just reliance on existing ones.
Gen Z Sellers and the Productivity Paradox
The State of Sales data surfaced a stat that connects the role conversation to a deeper generational shift. Gen Z sales reps spend only 35% of their time actually selling. The rest is consumed by administrative tasks, internal meetings, tool navigation, and manual data entry — an estimated two hours per week on manual data entry alone.
This is the generation that grew up with smartphones, graduated into a SaaS-saturated workplace, and is supposed to be "digitally native." And they're spending two-thirds of their time not selling because the tools and processes they've inherited weren't designed for autonomous work.
Agents don't replace Gen Z sellers. They free them. An agent that handles lead research, email drafting, meeting prep, and data entry gives a Gen Z rep those two hours back — and potentially shifts their selling time from 35% to 50% or higher. But only if the agent is grounded on good data, integrated into the sales workflow, and governed appropriately.
Which brings us back, again, to the readiness gap.
Three Things to Start This Quarter
If you're an admin, developer, or leader reading this and wondering where to begin, start with these three things before the end of Q1:
1. Get hands-on with Agent Script in sandbox. Don't wait for a Trailhead module or a conference talk. Spin up a sandbox, enable Agentforce, and build a simple agent using Agent Script. Pick a real use case — a common customer question, a repetitive internal process, a lead qualification workflow — and build it. The learning happens in the building, not in the reading.
2. Start a Data Cloud pilot. Data Cloud is the foundation that Knowledge Data Libraries, agent grounding, and unified customer profiles are built on. If your org isn't on Data Cloud yet, start a pilot. If it is, start building the data model that agents will ground on. Clean your Contact records. Standardize your Account hierarchies. Build the data foundation now so you're not scrambling when agent deployment accelerates.
3. Define your governance layer. Before you deploy a single agent, write down: Who owns it? Who monitors it? What data can it access? What decisions can it make? What are the escalation paths? What are the compliance boundaries? What are the success metrics? This doesn't have to be a 50-page document. A one-page governance charter for your first agent is enough to start. But start.
Closing the Gap
The February 25th earnings call will give Wall Street its verdict on Agentforce. The stock will move. Analysts will opine. Benioff will present numbers and vision in equal measure.
But the real verdict won't come from Wall Street. It will come from the thousands of teams sitting in the readiness gap right now — the ones who have signed Agentforce deals but haven't deployed agents in production, the ones who have deployed agents but can't govern them, the ones who know their data isn't ready but haven't started the remediation work.
The technology is here. The revenue is real. The market is repricing around agent skills. The tools are shipping. The question isn't whether Agentforce works. It does. The question is whether your org — your data, your security model, your governance framework, your talent — is ready for it.
Two questions to sit with this week:
How wide is your readiness gap? Not in theory. In specifics. Can you name the data quality issues that would block agent deployment? Can you describe your permission model in terms an agent would understand? Can you define who owns an agent after it goes live?
What's the first thing you're going to do to close it?
Where are you on the Agentforce journey? Still evaluating? Piloting in sandbox? Running agents in production? Stuck in the gap between "we bought it" and "we deployed it"? Reply and tell me — your experience shapes what we cover next week.