The Salesforce ecosystem has moved to adopt agents, whether that’s for building their Salesforce orgs or Agentforce agents managing business processes inside of their orgs. On this journey they have started to discover what is called the Agentic Development Lifecycle (ADLC). But what is the ADLC? And is that any different from the software delivery mechanisms that we already know, love and use today?
Same framework, different name
When you look at the stages of the ADLC what you’ll find is that it’s not that different to something that we all know already. The software development life cycle (SDLC) isn’t a new concept. It’s existed for a long time and you’re following it even if you don’t realise you’re following it, much like a trail in a forest carved out by countless hikers before you.
The only thing that’s different between the ADLC and the SDLC is what we’re managing. Agents are new, exciting, and we’ve put them on a pedestal where we believe they deserve something new and shiny to go alongside them. Some may go as far to say that software is now, by comparison, boring. But “boring” is safe and quite often very good. As a golfer I can attest to that, my “boring” golf is often my best performing golf.
In reality we don’t need a specific ADLC, and I believe thinking so has the potential to be hugely detrimental to our overall business system tech stack. The ADLC speaks specifically to agents themselves however when we look at the stages of the ADLC they’re mapped almost identically to the preexisting SDLC.
| ADLC stage | SDLC stage |
|---|---|
| Ideation & design | Plan |
| Development | Build |
| Testing & validation | Validate |
| Deployment & release | Release |
| Monitoring & tuning | Operate & Observe |
As you can see, there’s not much difference. While I accept there’s going to be nuances to developing and deploying agents, just like there is when you’re building a flow vs. apex vs. standard object config, there’s a risk I fear will compound if ADLC becomes the default thinking.
An Agentforce agent is still metadata
Working for a DevOps vendor gives you a unique perspective. A colleague of mine who’s spent a long time deep in Agentforce and Data 360 has shared with me what’s complex about deploying Agents to production.
Salesforce’s Agentforce agents are deployed as their own metadata type. Over the last year or so, that metadata has gone through development churn. For example, what was Agent Planner bundles is now Agent Script.
Every time the underlying metadata format or Salesforce API changes, teams that built and deployed agents in the old format have to figure out what’s still deployable and what’s broken. It can be a real headache, you need to keep a close eye on release notes and API updates if you’re attempting an Agentforce rollout.
Now, you’ll recognise that this is a SDLC problem. Metadata is managed through the SDLC, always has been. An Agentforce agent, fundamentally, is still metadata just with some settings activated in production so that metadata can interact with a LLM. Just like a flow, just like “normal” Salesforce config.
Incorporating agents into your SDLC
Every Salesforce professional I speak to is now using AI in some way to help them develop or build Salesforce configuration. Whether it’s Claude or Cam from Gearset, agents have a huge amount of potential to increase the capacity of a Salesforce team. But with greater capacity comes greater responsibility.
I’ve spoken with teams whose vision is a fully agentic SDLC end-to-end, requirements intake straight through to deployment and enablement, with an agent handling every handoff in between. I don’t think these teams will achieve the best outcomes.
The ecosystem’s biggest risk lies in defined responsibility. Every team needs to answer two questions:, “is our AI agent producing quality changes?” and “is every change, human or AI, governed with the same rigour?” For that, an agent should do what an agent does well: analyze, surface insights, clarify, and build. Deterministic solutions should handle the rest: CI/CD with quality gates, testing, code review, and backups. In these scenarios, failure and unexpected outcomes isn’t an option.
What Salesforce teams need to do next
First and foremost, Salesforce teams have spent the last decade getting to grips with good DevOps practices and the SDLC. Release management, version control, sandboxes, CI/CD, testing, backups. That’s a good thing, and the area that needs up-front investment in people, process, and the products we use. Teams that continue investing time and energy into building the most robust delivery pipeline possible will be successful, and have a handle on what “good” looks like, measuring success through the DORA metrics.
The next question to answer is: “How do we incorporate virtual teammates so they add real capacity?”. For me that starts with experimenting, much like we always have. Teams can experiment with Claude, or a dedicated Salesforce solution like Cam from Gearset which follows established DevOps best practice. In the short term, success will likely be measured on the proportion of AI changes that get deployed and the change failure rate for those changes. But longer-term trust in (and success of) AI will be evident from team adoption rates and the durability of the code AI has produced.
For more information on how Gearset can help you solve your SDLC challenges, or increase team capacity with a virtual teammate, schedule time with our team.
