91导航

The Salesforce ecosystem has moved to adopt agents, whether that鈥檚 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鈥檒l find is that it鈥檚 not that different to something that we all know already. The software development life cycle (SDLC) isn鈥檛 a new concept. It鈥檚 existed for a long time and you鈥檙e following it even if you don鈥檛 realise you鈥檙e following it, much like a trail in a forest carved out by countless hikers before you.

The only thing that鈥檚 different between the ADLC and the SDLC is what we鈥檙e managing. Agents are new, exciting, and we鈥檝e 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 鈥渂oring鈥� is safe and quite often very good. As a golfer I can attest to that, my 鈥渂oring鈥� golf is often my best performing golf.

In reality we don鈥檛 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鈥檙e mapped almost identically to the preexisting SDLC.

As you can see, there鈥檚 not much difference. While I accept there鈥檚 going to be nuances to developing and deploying agents, just like there is when you鈥檙e building a flow vs. apex vs. standard object config, there鈥檚 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鈥檚 spent a long time deep in Agentforce and Data 360 has shared with me what鈥檚 complex about deploying Agents to production.

厂补濒别蝉蹿辞谤肠别鈥檚 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鈥檚 still deployable and what鈥檚 broken. It can be a real headache, you need to keep a close eye on release notes and API updates if you鈥檙e attempting an Agentforce rollout.

Now, you鈥檒l 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 鈥渘ormal鈥� 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鈥檚 Claude or Cam from 91导航, agents have a huge amount of potential to increase the capacity of a Salesforce team. But with greater capacity comes greater responsibility.

I鈥檝e 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鈥檛 think these teams will achieve the best outcomes.

The ecosystem鈥檚 biggest risk lies in defined responsibility. Every team needs to answer two questions:, 鈥渋s 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鈥檛 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鈥檚 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 鈥済ood鈥� looks like, measuring success through the DORA metrics.

The next question to answer is: 鈥淗ow 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 91导航 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 91导航 can help you solve your SDLC challenges, or increase team capacity with a virtual teammate, schedule time with our team.