Agentforce World Tour, 4th December 2025

Posted on by Mark Myers Leave a comment

A smaller version of the normal Salesforce conference, and very definitely targeted at Agentforce. As a change of pace to the normal Salesforce conferences It was very much geared around practical work 1, and that seemed to be the core theme of the day.

It felt like we have now moved past the over-excitement phase of AI. Everyone is asking the same question: how do we actually make money out of this, and what do we really do with it past a fun proof of concept?

There were quite a few large-scale customer success stories pushing cost savings and value. Also a lot of practical coding sessions on how you actually implement things. One interesting thread ran through the day. Those who are rolling their own, or “DIY AI” as Salesforce calls it, were very much looked down upon as an unnecessary cost and a waste of effort.

The clear message was why bother when you can have prefabbed AI with a set of ready to use tools. Alongside that was a constant emphasis on trust and trustworthiness. A valid point and one that needs making, because if you package up AI and make it opaque on what is going on under the hood, then people really do have to trust the implementation.

My highlight of the day was the Compliance Centre. It is the first truly useful business implementation of AI that I have personally seen. Most other tools feel like clever technology in search of a problem, or thinly disguised cost cutting exercises. Even the usual line of “freeing people up to do interesting work” often feels forced. The Compliance Centre, however, is genuinely useful. Corporations have to do compliance. They hate doing it. The people tasked with it hate doing it. The people they enforce it on tend to hate them for doing it. It is a miserable necessity. So having a tool that takes large regulatory documents, even giant government-produced PDFs, turns them into practical legislation and enforces it inside your data is genuinely powerful. It is exactly the sort of task no one wants a human to do, and no human wants to do it.

 

I may be slightly coloured by the fact that I genuinely enjoyed the day. It was a smaller event, but I had good company, which always helps. It felt much more like an information dump showing what is coming, rather than a sales drive. They clearly knew that very few organisations had money left to spend at this time of year.

One thing I nearly forgot to mention was the whole “vibe coding” toolkit. It was demoed and had multiple workshops, but in honesty I have seen the same ideas implemented elsewhere in other development environments. Salesforce are largely catching up here. They might see it as a big step forward, but for many developers it felt more like parity.

Overall though, well worth attending. I did not expect much from it, and several colleagues and previous clients skipped it because they assumed it would be too small to bother with. I think they missed out. It was far less hyperactive than the main events and much more focused on practical delivery. I came away with useful tools, new knowledge and a surprisingly positive view of where this part of the platform is heading.

   

  1. , which I suspect is down to the practicalities of it being held in Quarter 4 of the financial year when no one has any money left [↩]

Corporate term: “Gravy Train Project”

Posted on by Mark Myers Leave a comment

Definition

A gravy train project is a large, long-term initiative that attracts significant promised investment, often sanctioned by very senior decision-makers and spread over multiple years. These projects typically involve substantial spending, the rapid hiring of new staff, and the signing of large and expensive vendor contracts, often without clear short-term deliverables.

Explanation

A gravy train project usually begins with extensive hype. It is positioned as the next big thing and is supported by high-profile backing, whether from major corporations’ investment areas or government bodies. Marketing activity from vendors and internal stakeholders quickly follows, reinforcing the scale and ambition of the initiative.

From a delivery perspective, the outcomes are often framed as being years away. This removes immediate pressure for tangible results while releasing large amounts of funding into the system. As a result, spending accelerates rapidly. In many cases, this expenditure does not always align with effective delivery or long-term value.

Vendors and external partners are well aware that this type of funding rarely lasts indefinitely. As the money is expected to dry up eventually, there is often a rush to secure as much of it as possible while the programme still has momentum.

Real-World Context
One of the most visible examples in England has been HS2. There was an excellent interview with the former head of the Channel Tunnel rail link construction into London, where he contrasted the gravy train nature of HS2 with the way the cross-Channel connection was managed.

His key lesson was that large projects should not release all funding at once. Instead, investment should be announced and approved in tightly defined phases. While the overall programme may span many years, each phase should be funded only when the previous phase has delivered successfully. In effect, this turns one vast programme into a series of smaller, tightly controlled projects.

Why This Matters?
This phased approach limits uncontrolled spending, maintains delivery focus, and helps prevent the gravy train mentality that assumes unlimited money for unlimited activity. It also reduces the risk of large-scale failure, reputational damage, and the familiar situation where those who spent most freely are never held to account, while delivery teams are left to manage the consequences and the frantic panic as the funds run dry.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

 

LDC Via site redesign

Posted on by Mark Myers Leave a comment

I have worked with LDC and LDC Via for well over a decade now, and it remains my main professional home for the work I do. Like many small companies, however, we are far better at delivering for clients than we are at regularly refreshing our own website.

This time, Ben and his excellent UI skills have once again come to the rescue. He has produced a clean, modern single-page redesign that puts everything front and centre. It covers what clients most commonly ask for, provides clear links to everything else, and does so in a way that is simple, fast and easy to navigate. It is a huge improvement on what we had before.

If you have not already seen it, I would encourage you to take a look at https://ldcvia.com/

And yes, you can also use it to hire us.

Why so many non-technical posts?

Posted on by Mark Myers Leave a comment

For someone who’s been technical for their entire working life and who still sells such skills to clients, it may seem odd that this blog contains so many non-technical posts. The simple answer is that these are the things I think I can help to fix longer term.

A great deal of technical work is largely a question of knowledge, pattern recognition, and experience. Once you have seen the same types of problems often enough, staying current is relatively straightforward 1.

After it is established in each client that you genuinely have been here before and understand the need, working through issues becomes a matter of dealing with one technical problem after another using either the client’s chosen platforms or whichever best-of-breed solution is suitable 2. The path to delivery is usually proven, even if the exact solution is not yet known.

Integration, delivery, and many of the wider challenges around technology don’t work the same way. The difficult part is not the code or the platforms. It is the human behaviour, the organisational design, and the processes wrapped around the technology. Those are the areas where progress is slower, resistance is higher, and inefficiency is often tolerated. They are also the areas where I believe many organisations could make meaningful improvements.

That is why you see so many non-technical posts here. Despite being a geek by preference and by nature, these are the problems I now find that clients find the hardest to resolve.

There will still be plenty of deeply technical material to come, particularly in the new year.

  1. , it just takes a bit of time and effort[↩]
  2. with the odd paradigm shift thrown in [↩]

Corporate term: “Admin Rampart”

Posted on by Mark Myers Leave a comment

Definition

An “Admin rampart” is an odd but very real construct. It is a defensive structure, usually built by one team, silo, or functional area to protect itself from the perceived aggressions of another.

Explanation

Often the creation of “Admin Ramparts” is the unintended consequence of a well-meaning initiative.
A large corporation realises that it is drowning in paperwork and process, to the point where it is actively impeding delivery to the business and even to itself. In response, it launches a drive for simplification or boundary breaking.

In practice, this rarely breaks down the old issues. Instead, new processes are created in the hope that they will simplify delivery. The critical flaw is that the existing processes are very often not removed first. Another layer is simply added on top, usually by the team creating the new framework. This is done to demonstrate progress and the aim of simplifying delivery.

Meanwhile, the areas whose boundaries and controls are being challenged frequently respond by placing even more dependencies in front of their current processes, as they feel they are losing control of their own deliveries and so want to place responsibility safeguards in place for the inevitable “blame game”; sometimes these dependencies become cyclic and impossible to achieve for a new delivery. The result is that regardless of whether you follow the new route or not, you still have to complete all of the old steps as well, often just under a different name.

This back-and-forth, without ever dismantling what already exists, produces admin ramparts. These become great walls of paperwork that serve to deflect blame, avoid responsibility, and maintain control, rather than enable delivery.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.