Dominic Jainy has spent the better part of the last decade at the intersection of emerging technology and enterprise efficiency. As a seasoned IT professional with a deep specialization in machine learning, blockchain, and autonomous systems, he has become a pivotal voice for organizations navigating the “agentic” shift. Currently, he focuses on how the Salesforce ecosystem is evolving beyond static automation into a world of reasoning engines and long-horizon goal-seeking. In this conversation, we explore the transition from traditional workflows to Agentforce, examining the architectural, economic, and operational shifts that define the current landscape of 2026.
The fundamental shift in Salesforce automation seems to be moving away from pre-planned paths toward something more fluid. How would you describe the core architectural difference between traditional workflows and these newer agents?
The most profound change is that we are moving from a map to a compass. In traditional automation—think of your standard Salesforce Flows or Apex triggers—a human designer has to anticipate every single “if-then” scenario and hard-code the path in advance. If a customer’s request falls outside that pre-defined flowchart, the system breaks or simply stops. Agentforce, however, is objective-oriented; you give it a goal, and it uses the Atlas Reasoning Engine to decide the best path at runtime. It feels much more like delegating a task to a person than programming a machine, as the engine interprets the “intent” and selects the right tools to get the job done dynamically.
When we look at the legacy stack of Flow, RPA, and Einstein Bots, how do we differentiate what we’ve been doing for years from what Agentforce is doing now?
It is helpful to think of the existing stack in three distinct layers that are often incorrectly lumped together. First, you have rule-based workflow automation like Flow, which is deterministic—give it the same input, and you get the same output every single time. Then there is Robotic Process Automation (RPA), which is essentially a software bot “driving” a user interface when no API exists to move data. Finally, there is predictive AI, which handles lead scoring or uses Einstein Bots to follow a rigid dialog tree. While Einstein Bots are still supported, the strategic investment has shifted entirely to Agentforce Service Agents because they don’t just respond; they execute multi-step tasks based on reasoning rather than a script.
One of the biggest frustrations with traditional bots is how they handle “exceptions.” How does the agentic approach change the way we manage those outliers in a business process?
In the old world, the success of your automation was capped by your imagination—the more “edge cases” you could foresee, the more efficient you were. Anything you didn’t predict became an “exception” that landed in a human’s queue, often causing bottlenecks. Agentforce effectively makes the concept of an “exception” disappear within its permitted boundaries. A customer might send a single, messy email containing an incorrect invoice number, a partial payment, and a request to change their address. To a traditional bot, that is three separate failures; to an Agentforce agent, it is a single conversation where it reasons through each point, finds the correct data, and updates the records without needing a human to intervene.
We often hear that an AI is only as good as its data. How does Agentforce leverage the “Data 360” layer differently than a standard workflow rule would?
A standard workflow rule is blind to anything that isn’t a structured field—it sees a “Status” picklist or a “Revenue” number, but it can’t “read” the context around it. Agentforce is built on the Data 360 unified layer, which allows it to ingest and index unstructured data like case histories, PDF attachments, and long email threads. This is the difference between an automation that simply knows a contract is up for renewal and an agent that actually understands what the specific clauses in that contract say. However, this deeper access is a double-edged sword; if your data quality is poor or your permissions are messy, the agent will inherit those flaws and act on them with misplaced confidence.
You’ve mentioned “long-horizon agents” like Piper and Fin. How does the time-scale of automation change when we move from event-driven triggers to goal-seeking agents?
Traditional automation is “event-shaped”—a record changes, a trigger fires, and the logic runs instantly. A Flow cannot “own” a goal that takes weeks to complete, such as “progress this stalled sales pipeline,” because there is no single event to hang that logic on. The new class of job-ready agents, including Piper for sales and Marshall for back-office work, are designed to pursue goals over days or even months. They can check in periodically, follow up on missing information, and pivot their strategy based on new data. This is a category of work that was never actually automated before; it was always something a human had to remember to do between their other tasks.
The interface for Salesforce has traditionally been the “browser tab.” How is the “AIforce” layer changing where and how users actually interact with the platform?
The goal now is to bring the power of Salesforce to wherever the user is already working, whether that is Slack, Claude, or a search bar. With Agentforce Coworker and Slackforce generally available, we are seeing the “Salesforce screen” become less of a requirement for daily productivity. For years, the biggest barrier to adoption wasn’t the logic of the automation; it was the friction of forcing a user to navigate to a specific page to trigger it. Now, you can have an agent operating inside a Claude window or a Slack channel, effectively turning the CRM into an invisible engine that powers conversational interfaces across the entire enterprise.
With the introduction of the “Koa” model and the ability to “Bring Your Own Model,” how has the role of the architect changed regarding model choice?
Architects now have to make decisions that never existed in a Flow-based world, specifically around where inference happens and which “brain” is best for the job. Salesforce has introduced Koa, their first CRM-specific reasoning model built on NVIDIA Nemotron, which is optimized for tool use and decision-making within the platform’s own infrastructure. But organizations can also pull in Anthropic models via Amazon Bedrock or Google’s Gemini for different workloads. This introduces a new layer of complexity: you have to decide if a task requires a high-reasoning, expensive model or a faster, more specialized one, and you have to account for how the agent’s behavior might shift if you switch models mid-stream.
Governance is a major concern, with some analysts predicting a high failure rate for autonomous agents due to a lack of oversight. How should companies secure these “identities”?
Gartner’s prediction that 40% of enterprises will demote their AI agents by 2027 due to governance gaps is a sobering reality. We have to move away from the idea that an agent is just another “system user” and start treating it as a distinct identity with scoped permissions and action-level audit trails. The risk with an agent isn’t just that it might fail, but that it might succeed in doing something it wasn’t supposed to do—like issuing a massive refund because it misread a customer’s tone as an urgent threat. Proportional governance is the only way forward; you cannot apply the same oversight to an agent that drafts email summaries as you do to one that has the power to modify financial records.
The pricing for Agentforce is a departure from the traditional seat-based model. What are the economic realities that businesses need to prepare for?
The business case for Agentforce is fundamentally different because it is metered. Traditional Flow runs are essentially free at the margin, but Agentforce uses Flex Credits, which are sold at $500 per 100,000 credits, with a standard action costing about 20 credits, or roughly $0.10. Alternatively, customer-facing agents can be priced at $2 per conversation. Organizations need to be incredibly disciplined with their math here; Gartner expects those on uncapped, token-based pricing to exceed their cost expectations by 50%. You have to model your highest-volume scenarios at ten times the pilot volume before you sign a contract, especially since unused Flex Credits don’t roll over to the next year.
How does the way an agent “fails” differ from the way a traditional workflow fails, and why does that matter for observability?
When a Flow breaks, it throws a “red box” error, a developer gets a notification, and the process stops. When an agent “fails,” it often produces a beautifully formatted, highly confident, but completely wrong answer and then proceeds to act on it. This “inversion of failure” means that evaluation and observability are now more important than the code itself. You need reasoning traces and action logs to see why an agent made a specific choice. Without these tools, you won’t be able to distinguish whether a mistake was caused by a bad instruction in your prompt, a hallucination by the underlying model, or just poor data quality in the CRM.
Since Agentforce seems so capable, is there any reason to keep using Salesforce Flow at all?
Absolutely, and in fact, the strongest implementations use Flow as the “hands” for the agent’s “brain.” You should keep deterministic automation for compliance-critical steps where the same input must always produce the same output, such as validation rules, approvals, and high-volume transactions with zero variance. Agentforce is expensive to run for simple, mindless tasks; it is pure cost for no judgment. The ideal architecture is to turn your existing, reliable Flows into “callable actions” that the agent can trigger. This way, the agent decides what to do based on the conversation, but the Flow ensures the actual database update happens exactly the same way every time.
If an organization is ready to start their agentic journey today, what is the most practical sequence for moving from rules to agents?
Don’t try to rebuild your entire roadmap in a week; start with a process that has high volume, high variation, and a measurable outcome. Variation is the key, because if there’s no variation, a cheap Flow will do just fine. Before you give an agent autonomy, audit your data and permissions, because the agent’s output is only as good as the knowledge articles and object structures it “grounds” against. Start by using the agent in an “advisory” capacity—let it draft responses or recommend actions while a human clicks the final “send” button. Only after you’ve instrumented the reasoning traces and confirmed consistent behavior should you widen the scope to full autonomy.
What is your forecast for the future of agentic interoperability?
I expect that within the next two years, the ability for an agent from one vendor to talk to an agent from another will become a standard procurement requirement rather than a “nice-to-have” feature. We are already seeing Salesforce demonstrate handoffs between Agentforce and external agents from SAP or ServiceNow. The future isn’t a single, monolithic AI that does everything; it’s a web of specialized agents that negotiate with one another to complete complex cross-platform tasks. For our readers, my advice is to stop building “silos of automation” and start building “callable actions.” If your processes are modular and accessible via API or Flow, they will be ready to be picked up by any agent, regardless of whose logo is on the front end.