Delivery Intelligence Seen From the Inside
Author: Uriah Hakala
From the Professional Services Seat
Thirty years of consulting has a way of calibrating your expectations. I’ve seen a lot of things get named, branded, and announced before they were real. I’ve done some of the announcing myself. So when I say Delivery Intelligence™ is changing how our teams work — I want to be specific about what that means, because “changing how we work” is the kind of phrase that’s easy to say and hard to back up.
JP’s series covered the architecture. The layers, the orchestration model, the hotel analogy, why we picked Salesforce as the foundation. All of it holds. I was watching that build happen in real time and I’d have told you the same things. But the architecture posts are written from the builder’s seat. This one is from the delivery seat, which is a different view.
Here’s what I can tell you from that seat.
DI Agents: What’s Live Right Now
Four agents are in production. They don’t cover everything, and that’s intentional — we built them in the sequence that would hit the hardest problems first.
Workshop Agent
The Workshop Agent takes project context, the SOW, and our delivery best practices and helps build Elaboration Workshop plans and session agendas. Workshop planning is one of those tasks that looks simple from the outside and eats senior consultant time from the inside. Every workshop is different enough that you can’t just copy last quarter’s agenda, but similar enough that most of the work is structured assembly rather than original thinking. That’s exactly the kind of work an agent can help with.
Requirements Agent
The Requirements Agent does something harder. It takes unstructured inputs — workshop transcripts, notes, conversations — and extracts properly formatted requirements. Epics, Features, Product Backlog Items, a Requirements Traceability Matrix, ready to upload to Azure DevOps. Anyone who has sat in a workshop and then spent three days turning the notes into something structured and traceable knows how much time lives in that gap. That’s where this agent works.
Solution Agent
The Solution Agent takes PBIs or User Stories from multiple sources and generates developer-ready implementation solutions grounded in Salesforce and Diabsolut best practices. The practitioner gets a starting point that’s already calibrated to how we build, not a blank page.
Build Agent
The Build Agent processes components and generates fully configured metadata and code — deployable into a client org either as a release-ready branch or as a text output a developer can merge manually. That’s the end of the chain from scoping to build.
Early returns on the metrics are showing improvements, and the time we’re saving is going somewhere useful: our practitioners are spending more of it on the client outcomes that actually move the needle, not the structured assembly work that has to happen around them. The practitioners using these agents aren’t going back to the old way. That’s usually the signal that matters first.
30 Years of Delivery Experience Tell Me That This Is Different
I’ve watched a lot of productivity tools come through the consulting industry. Most of them helped with the edges — better templates, faster reporting, cleaner collaboration. The work in the middle, the thing that actually takes time and judgment, stayed mostly the same.
What’s different about a well-built agent is that it can sit inside the actual work. Not reporting on it. Not automating the admin around it. Inside it. The Requirements Agent isn’t helping a consultant file their timesheet faster — it’s doing a significant portion of the requirements extraction itself, in a form that’s already structured for what comes next.
That changes the economics of a project in a way that templates never did. When you compress the time between “workshop complete” and “requirements in ADO,” you’re not just saving hours. You’re changing what’s possible within a fixed project timeline. You can run a tighter feedback loop. You can catch ambiguity sooner. You can get into build faster, which means more build cycles within the same engagement.
There’s also something harder to quantify, which is consistency. Our best practitioners do this well. Our newer practitioners are still developing the pattern recognition that comes with experience. An agent grounded in our own delivery knowledge brings that pattern recognition to every project, not just the ones staffed with twenty-year veterans. That matters a lot at scale.
Recognizing the Journey
I’ve been doing this long enough to know that the thing that sounds most impressive in a blog post is usually the thing that’s hardest to actually pull off on a real project with a real client and real constraints.
The agents are live. The practitioners are using them. The architecture underneath them — the part JP described in detail — is what makes it possible to keep adding capability without rebuilding from scratch every time.
But we’re also early. These agents are going to get materially better over the next two quarters. The delivery team is still building the muscle memory for when to lean on an agent and when to apply their own judgment, because that discernment matters as much as the tool itself.
What I’m confident about is the direction. The sequence makes sense. The foundational investment was real. And the feedback from the practitioners using these agents every day is the kind of feedback you can’t manufacture.
I’ll have more specific numbers to share as we accumulate enough projects to report them properly. In the meantime, the series continues — and if you’ve read JP’s posts and you’re wondering what this looks like from the delivery side of the table, this is it.
Diabsolut is a Salesforce consulting partner building the agentic enterprise in the open. Follow the series to see what’s working, what we’re learning, and what’s coming next.