I Implemented Agentforce at a US Fintech. Here's What the Marketing Materials Don't Tell You — From Any AI Vendor.

I've been living in the US for two years, working in the local Salesforce ecosystem (how that reality compares to my expectations — that's a topic for a separate post, because there's plenty to say). Today, I want to talk about one specific project that taught me more about AI in Salesforce than all the marketing materials combined.
The Starting Point
I was offered a role on a project for a Miami-based fintech. The company had already purchased Agentforce and Data Cloud licenses — though along the way, a classic misunderstanding had occurred: they were convinced Data Cloud would solve their data storage problems in Salesforce. It didn't, because that's not what it's for (it's a data unification platform, not cheaper storage). Nobody was "at fault" here — the use case simply wasn't verified before the purchase. But the licenses were there, and the business problem was very real.
The problem looked like this: underwriters were losing enormous amounts of time analyzing each case. To make a decision in Salesforce, they had to manually scan several systems (risk assessment, banking systems) and several PDFs, each a dozen-plus pages long. For a single case.
The Plan
The plan was simple and beautiful on paper. JSONs and PDFs flow in from external systems, a Flow triggers a sequence of Agentforce agents, each one reads its portion of the data, and at the end the underwriter gets a clean, ready-made summary in an LWC. Instead of an hour of clicking through systems — one glance.
That was the plan. Now, the reality.
Three Walls We Hit
Wall 1: agent configuration. Setting up each agent turned out to be far more complicated than Salesforce tutorials suggest. In a tutorial, an agent answers questions about orders in 15 minutes. In a real project, where an agent has to read multi-page PDFs and structured data from several sources, every topic, every instruction, and every action required iterations, testing, and debugging behaviors nobody could have predicted.
Wall 2: data from outside the platform. This was our biggest limitation. At the time of our implementation, Agentforce worked exclusively on data inside Salesforce — it couldn't search for information on the internet. And in underwriting, up-to-date client data is fundamental: insolvencies, bankruptcies, registry changes. An underwriter needs to know what's happening today, not what was in the data from the last import. We had to work around it with additional integrations, which added complexity to an architecture that was supposed to reduce it.
To be fair: Salesforce has since partially addressed this limitation — as of the Summer '25 release, Web Search exists in the Agentforce Data Library. It's worth understanding how it works, though: it's not an agent freely browsing the internet, but grounding — search engine results are indexed into a data library, and the agent works from that layer. It requires Data Cloud, the right editions with the Einstein add-on, and separate configuration (a dedicated data library, a dedicated topic). Our lesson still stands: before you sign, check whether your exact data flow is supported out of the box — or whether it requires assembling more building blocks.
Wall 3: time. The implementation took significantly longer than anyone assumed at the start. Not weeks. Months
How It Ended
The team and I did get a version working in production — and it worked. But management ran the numbers on cost and time and made a pragmatic call: AI operations move to AWS Bedrock, and Salesforce receives a clean, parsed JSON displayed in an LWC.
I won't sugarcoat it: at first, I was furious. Months of team effort, dozens of iterations on the agents — and now all of it lands on a different platform? But once the emotions settled, I had to admit: it was a pragmatic decision — for this use case. Our scenario — a continuous pipeline of multiple dozen-plus-page documents from several external systems, with a requirement for fresh data from outside the platform — sat right at the edge of what could reasonably be assembled from the available building blocks at the time. The platform has more and more capabilities in this area today, but each of them is another component to configure, test, and pay for — and our case required all of them at once. Agentforce runs most smoothly where the agent works on data inside Salesforce — customer service, lead qualification, working on CRM records. We tried to force a problem into it that largely lived outside the platform, because the licenses had already been bought. It's a lesson about matching the tool to the problem, not about the tool.
What It Taught Me
Three things I'm taking away from this project — and they apply to every AI implementation, not just in Salesforce:
1. The gap between demo and production is enormous. What takes 15 minutes in a keynote takes months in a real implementation with real data. That's true for Agentforce, for Copilot, for every AI tool on the market.
2. Verify the use case before buying licenses, not after. Half of our problems came from the fact that the tool was purchased before anyone checked whether it fit the problem.
3. Companies don't need another "AI platform." They need solutions to specific problems. Many AI platforms don't bring anything fundamentally new to an organization — you get what you already have, just faster, plus the obligation to learn yet another tool. That only makes sense when "faster" applies to something that genuinely hurts. The underwriters didn't want agents — they didn't want to have to manually read 40 pages of PDFs a day. When you start from the pain point rather than the technology, the architecture designs itself.
This experience changed the direction of what I do. Those pain points — months of implementation, configuration complexity, access to current information from the internet without stacking more building blocks — literally became the requirements list for my own product. Today I'm building AI Engine — a Salesforce-native AI assistant where the time from package installation to a working assistant is measured in hours, not months. The technical setup fits in a single day — and all the implementation energy goes where the value is actually created: adapting the AI to a specific company's processes and data, not fighting infrastructure. Plus built-in access to current information from the web from day one — because I know firsthand how much that's missing in daily work.
And interestingly, I'm not alone in this — an entire segment of lighter, specialized AI solutions is gaining momentum, driven by exactly the same pain points from large implementations. I don't want to take anything away from the power and capabilities of Agentforce — it's a powerful platform. But it will always come down to matching the tool to the problem. Not everyone needs a combine harvester to mow the lawn behind their house — sometimes a simple push mower gets the job done faster, cheaper, and without reading a 200-page manual.
More on that — and on what working in the US Salesforce ecosystem really looks like — in future posts.
