Home / Lessons from Agentforce: Why Context Matters More Than You Think
July 2, 2026
7 min read
I went to Agentforce World Tour in Boston last week and took part in multiple hands-on training sessions. The Agentforce session showcased Agentscript and the new builder, which was great to see in a guided format. The Data 360 session is where something shifted for me philosophically.
I have been writing about data quality for most of the past year. Clean records. Accurate fields. Consistent definitions. If your data is a mess, AI amplifies the mess. That argument is right and I stand behind it.
But sitting through the Data 360 session, I understood something I had not fully realized before I was in this convention center room. Clean data is the floor. The breadth of data with context is the ceiling. If you want agents doing real work, breadth is required. And almost nobody in the mid-market is thinking about the ceiling yet.
It’s the integration architecture underneath.
Here is the stress test I ran in my head during the training:
If I asked an AI assistant to give me a project status update on a specific client right now by pulling from email, calendar, meeting transcripts, Salesforce, Slack, Google Drive could it do that consistently and confidently?
The honest answer is for assisted work where I review the output before acting on it, probably. For an autonomous agent taking action on my behalf, no. Not reliably.
Why is that? Context. My Zoom account has transcripts from dozens of calls this month. Some are for that client I am inquiring about. Some are for different clients. Some mention the client in passing. Some are internal. For a full project view, some transcripts may have happened months ago. The longer I use Zoom transcripts, the more it has to sort through so it makes it harder to be consistent. Without a layer that has already made those associations deterministically the agent is guessing. It is matching names, inferring context from language, making probabilistic connections across systems that were never designed to talk to each other.
For a human reviewing output, guesswork at 85% accuracy is useful. For an autonomous agent sending a client email, updating a project record, or flagging a risk 85% accuracy is a liability.
Real-time connections to your tools solve the access problem. A context layer solves the organization problem. Most people are confusing the two and hoping the context layer automagically resolves itself. This is the path of least resistance for us as it requires us to simply log in to provide access versus doing the hard work of laying out the rules. Data 360 exists to hopefully solve this problem for its customers. It provides that standard data model and rules engine to create those associations before the agent ever touches your data.
Over its existence, Salesforce has assembled something genuinely hard to replicate. It is not just that they have all the tools. It is that they have a standard data model that harmonizes across all of them, and the tooling to map external data sources to that model.
The closed loop is real. The convenience is real. Unfortunately for a lot of customers right now, so is the cost. But think of it this way: This is how breakout technology has always worked. Enterprise pays to prove it. Everyone else benefits from what they learn.
For enterprise organizations with the infrastructure and budget to stand up the required Salesforce stack correctly, it makes complete sense. The investment buys you the context layer that makes agents actually work. For mid-market companies, the distance between the demo and a working implementation is wider than the keynote implied. This is not because the technology does not work but because the architectural foundation required to support it is significant and costly.
There will be other ways to build this context layer outside the Salesforce ecosystem. Some platforms charge for connectors and workflows rather than usage, which is a different risk profile when the use cases are still being proven. The architectural problem is solvable. It is just not as simple as connecting your tools and asking an agent to figure the rest out.
I have spent a year telling clients that data quality is the prerequisite for AI success. I still believe that. We are not connecting our tools and hoping the agent figures out the associations.
The target is a small number of subagents working correctly by the end of year. Not an impressive demo. Not a pilot that never scales. Working agents on a foundation we understand that grow and scale with us.
The agent capability question is really a data architecture question. It always was. Agentforce World Tour made that clearer to me than anything I had read or heard before.
If your AI strategy is currently a license in a renewal agreement or a tool connected to your stack with no underlying context layer, that is a starting point. The gap between access and context is where most agent deployments will stall.
Clean data matters. Breadth matters more. And without a layer that organizes that breadth deterministically, before the agent ever touches it, you are asking the agent to do work it should not be trusted to do autonomously.
The floor gets you started. The ceiling is where the real work is. training didn’t change the argument, it extended it.
But the hands-on training added a dimension I had been undervaluing. It is not just about whether your data is clean. It is about whether your data is broad enough, connected enough, and organized enough for an agent to reason across all of it correctly to take action on your behalf.
Structured data, your CRM records, your pipeline, your account data is the floor. Unstructured data, your emails, transcripts, contracts, Slack conversations, meeting notes is the ceiling. The difference between a workflow that executes a rule and an agent that makes a judgment call is often the unstructured layer. An agent that can only see your structured data is not much more than a sophisticated automation.
Most mid-market companies have invested in the floor. Almost none have a plan for the ceiling.
We left the conference talking about one thing: which agents we are going to build here at 28 North. Not because we have it all figured out but because we believe the best way to advise clients on this is to do the work ourselves first.
Before we build anything, we are mapping our data sources. Not just what systems we have but what data lives in each one, how it needs to be associated, and what a context layer would need to look like for an agent to reason correctly across all of it.
We are starting in one area of the business. One function, mapped carefully, with human oversight at every step. We are not deploying autonomous agents on data we have not validated. We are not connecting our tools and hoping the agent figures out the associations.
The target is a small number of subagents working correctly by the end of year. Not an impressive demo. Not a pilot that never scales. Working agents on a foundation we understand that grow and scale with us.