Something did feel different at this year’s TrailblazerDX conference, but not in a way that caught us off guard. If anything, it confirmed what many teams have been sensing for the past 12 to 18 months. The pace of AI has not just increased, it has compounded. What was exploratory not long ago is now embedded, shaping how decisions are made in systems that directly influence revenue confidence.
The conversations at TDX 2026 reflected that shift. Less focus on possibility, more on placement. Where does AI sit within the operating model? How close is it to core revenue workflows? How much decision-making is it taking on, and under what guardrails? These are no longer forward-looking questions. They are active design considerations.
We are well past the stage of experimenting at the edges. The centre of gravity has moved inward, into pipeline management, case resolution, and the day-to-day mechanics of how teams interact with systems. And as that shift happens, the cost of ambiguity, in data, in ownership, in logic, becomes much more visible.
What stood out to us was not just a single release or capability, but a set of patterns that kept resurfacing across sessions and conversations, and that validated the fact that agentic actions in Salesforce are here for the long term. The emergence of the agentic enterprise, and the growing normalisation of vibe coding on their own, signal progress. Together, they point to a more fundamental change in how systems are built, extended, and trusted.
The Agentic Enterprise Is Not About More Automation
There is a tendency to interpret agents as just another layer of automation. That framing misses the point.
What we’ve seen instead was the idea of a “super agent” acting as a front door, routing work dynamically to specialized agents. Finance queries move to finance agents. Case triage moves somewhere else. All of it operates with shared context, as opposed to siloed logic. That last part is where things get interesting and is applicable to any industry focus.
In high-growth environments, fragmentation is rarely caused by tooling, but rather caused by context loss between systems and teams. Handoffs degrade information. Ownership becomes blurred. By the time something reaches RevOps or Finance, it has already been reshaped by three different interpretations.
A multi-agent architecture attempts to address that directly. But here is the tension. If agents are making routing decisions, what governs consistency?
This is where newer features like Agent Script and Skills come into play. What we saw was a structured way to define agent behaviour that blends AI reasoning with deterministic logic through code. Not everything is left to probability. Certain paths are fixed. Others are adaptive.
That balance matters more than it seems.
If everything is probabilistic, you lose auditability. If everything is deterministic, you lose flexibility. Most organizations already struggle with this tradeoff in workflow design. Now it is being reintroduced at a different layer.
A simple question to sit with: “Where in your current system does decision-making rely on implicit human judgement that has never been codified?”
Because that is exactly where agent behaviour will either drift or break.
Headless 360 Changes Where Work Happens
The introduction of Agentforce Headless 360 could (at first) be seen as a small technical detail. We see it differently. It represents a meaningful step forward in how Salesforce is accessed and operated.
By decoupling core functionality from the Salesforce UI and exposing it through APIs and MCP, Headless 360 shifts Salesforce from a destination to a layer. Everything becomes accessible via API or CLI. That changes the boundary of the system in a very real way. Agents, and people, no longer need to “enter” Salesforce to interact with it. Whether that interaction happens through Claude, Slack, or another interface entirely becomes almost secondary. The system is still there, but it is no longer the place where work has to happen.
We saw demos where Slack became the operational surface. Case management, updates, interactions, all happening in a familiar environment, with Salesforce acting as the system of record behind the scenes. This is not just about convenience. It is about reducing friction at the point where work actually happens.
In post-acquisition environments, we often see teams resisting system consolidation not because they disagree with the data model, but because the interface disrupts their workflow. Headless architecture sidesteps that tension. It lets you centralize logic without forcing behavioural change overnight.
There is also a deeper implication. When everything becomes accessible via API or CLI, governance shifts from interface design to access design.
Who can trigger what? Under which conditions? With what context? These questions are practical cues we are already thinking about with clients. If an agent can update opportunity fields via API, what prevents silent corruption of pipeline data when upstream context is incomplete?
That risk exists today with integrations. Agents just accelerate the pace at which it can happen.
“Add to Slack” Is a Cultural Signal
One-click deployment of agents into Slack came up repeatedly. It would be easy to treat this as a distribution channel, but we believe it is more than that.
It reflects an acknowledgement that systems do not dictate behaviour, organizational environments and do. Most revenue teams live in Slack. Decisions happen there. Exceptions are discussed there. Workarounds are invented there. Bringing Agentforce into that space is not just about accessibility. It is about embedding system intelligence into the informal layer of operations. And that informal layer is often where data integrity quietly erodes.
Think about how many pipeline updates happen after a Slack thread, not during structured CRM interaction. Now imagine an agent participating in that thread, with the ability to act. Helpful, yes. But also… risky.
So the question becomes: “How do you preserve trust in your system of record when actions are triggered outside of it?”
Because trust is not built on where data lives. It is built on whether people believe it reflects reality.
Vibe Coding Is Closing the Distance Between Idea and Execution
Another theme the team kept coming back to was vibe coding. It is easy to dismiss, especially if you have spent years building with intention, structure, and a healthy skepticism of anything that feels too fast. We would argue that instinct, while understandable, misses what is actually changing underneath.
We tinkered with Vibes when it was first announced last year, but with Agentforce Vibes 2.0, we saw meaningful improvements in how quickly developers can move across Apex, MuleSoft, LWC, React, even Slack integrations. The barrier between idea and implementation is shrinking.
That sounds like a productivity gain…because it is. But it also introduces a different kind of pressure. When it becomes easier to build, more gets built. Not all of it is necessary. Not all of it is coherent.
We have seen this pattern before with low-code tools. The constraint was never technical capability, but rather, system intentionality. Vibe coding amplifies both the good and the messy. A tactical observation here: Teams that benefit most are the ones that already have clear domain ownership and architectural principles. Without that, speed leads to fragmentation faster than it leads to value.
You might recognize this scenario: A quick solution is built to solve a local problem. It works. It spreads. Six months later, no one is entirely sure how it interacts with the rest of the system. Now imagine that cycle compressed into weeks instead of quarters.
Alongside the shift toward agents and faster development cycles, the updates to DevOps Center and DX Inspector stood out, less as feature enhancements and more as indicators of where governance is being redefined. The experience itself is evolving, but the more meaningful signal is that it is being designed with Agentforce embedded from the outset, not layered in after the fact. That detail matters.
For most teams, DevOps has historically been where control is reintroduced. It is where changes are reviewed, validated, and moved with intent. By bringing Agentforce into that layer, Salesforce is effectively acknowledging that AI is not just participating in execution, it is participating in how changes are defined, tested, and promoted.
This introduces a different kind of question than we are used to asking. Not just can we deploy this safely, but how was this change generated, and what logic shaped it?
DX Inspector adds another layer to that conversation. Visibility into what is happening across environments becomes more critical as both human and agent-driven changes increase in volume. Without that visibility, drift is not always obvious until it shows up in behaviour, or worse, in reporting.
A practical consideration we are already working through, and one worth asking internally, is this: When an agent contributes to a change, whether that shows up as generated code, configuration, or flow logic, where does accountability actually sit during review?
The Quiet Risk: Faster Systems, Slower Understanding
Across these themes, there is a common undercurrent. We are increasing the speed of execution without necessarily increasing the speed of understanding. Agents can act quickly. Code can be generated quickly. Integrations can be deployed quickly. But organizational clarity, ownership, and data definitions do not evolve at the same pace. That gap is where issues surface. Not immediately, but gradually.
Pipeline numbers that feel slightly off. Or forecasts that require more “context” to explain, for example. Teams that trust their own version of the data more than the shared one. These are not system failures in the traditional sense. They are confidence failures, and they can be expensive.
Where We Are Focusing
Coming out of TrailblazerDX 2026, our focus is not just on adopting specific features and recommending them to our clients right away, but more so taking a step back and focusing more on how these patterns reshape system design:
- Defining where determinism is required in agent behaviour versus where flexibility adds value
- Designing for context preservation, especially across agent interactions and Slack-based workflows
- Reinforcing governance at the API layer, not just within UI constraints
- Maintaining architectural intent as development velocity increases
None of this is new thinking. What has changed is the speed at which gaps become visible. If agents are making decisions, and code is being generated faster than ever, then the real constraint is no longer technical capability.
It is clarity. Clarity of ownership. Clarity of data meaning. Clarity of system intent. If your system started moving twice as fast tomorrow, where would trust break first? Let’s chat.