AI-first isn’t a phase. It’s every phase.
That was the point of the one-pager I recently shared on Microsoft’s AI-first Success by Design guidance.
Data readiness in Discover. Agent scope and human-in-the-loop design in Initiate. Agent evaluation in Implement. Monitoring and incident response readiness in Prepare. Continuous evaluation and outcome measurement in Operate.
Now look at those responsibilities and ask one question:
Who can make the decisions?
If the answer requires three internal meetings and a message to someone who might be available Thursday, the delivery structure needs attention.
I keep coming back to a team I led long before agents became part of this conversation.
We hired them for their expertise
I was responsible for a portfolio of Business Central implementations, a team of consultants and developers, and our customer delivery commitments. Fortunately, I wasn’t the only person on the team who knew what they were doing.
We operated in what many practices now call a pod: one implementation team, a shared book of projects, and the authority to plan and deliver the work together. We called ours Team Endeavor. I was the Project Delivery Manager and PM of record. Thomas White was our Solution Architect. Alongside a team of consultants and developers, we owned the work across our customers.
Thomas could make a design decision without checking with me. Lead consultants could prioritize and delegate. Developers went directly to the person who could answer their questions. We hired them for their expertise. It seemed reasonable to let them use it.
The org chart only told part of the story
According to the org chart, I led the team. In practice, Thomas and I ran it together. I owned scope, schedule, budget and delivery gates. He owned solution design and the technical standard. I owned resourcing, working closely with Thomas on skills, priorities and assignments. When a solution decision affected a customer commitment, we worked it out directly.
Ultimately, I remained accountable for delivery. That required me to build and protect an operation where good decisions could happen without me in every conversation. The team understood what it owned, what it could decide and when another person needed to be involved. That is the part of the model I recommend for AI-first delivery.
More decisions need clear owners
Consider a customer-facing agent that can process a routine request but must escalate an exception. Someone has to define the boundary. Someone has to validate the behavior. Someone has to agree what happens when the agent gets it wrong.
In a pod, I would assign the solution boundary to the SA, working with the relevant technical, security and customer owners. The PDM would own the effect on scope, schedule, capacity and readiness. Consultants would bring the business process knowledge needed to make the design usable. Those responsibilities meet inside the team doing the work.
Discover and Initiate: Data gaps and agent boundaries become delivery work with named owners. The SA leads the solution decisions; the PDM ensures the work is planned and dependencies are visible. Customer business owners confirm the intended outcome and required approvals.
Implement: Evaluation findings go directly to the people able to change the design or build. If addressing a finding affects a customer commitment, the PDM and SA agree on the response together.
Prepare and Operate: The PDM coordinates go-live readiness and secures the required approvals. Accountable customer business stakeholders provide responsible AI sign-off and accept residual risk. The team establishes who will monitor agent behavior, respond to incidents and measure performance against the intended business outcomes after go-live.
That is how I would organize around Microsoft’s expanded lifecycle guidance. The pod keeps decisions close to the work, with clear paths to specialists and customer approvals when needed.
A pod is just a pod
Calling a group of people a pod doesn’t mean they’re peas in one. Sometimes they’re just mixed vegetables with a recurring meeting to debate whose version of the truth is current.
Team Endeavor planned the work and capacity together. When a customer wasn’t ready, we could see actionable work elsewhere. A consultant’s availability didn’t have to be reconstructed through conversations with several PMs.
The pod was the unit of capacity.
We held 80–90% utilization while running up to seven implementations at once. People could keep moving because we could see the work, make decisions and adjust across the team.
AI-related work needs that same visibility. Evaluation, remediation and monitoring consume real capacity. They need to appear in the plan alongside configuration, development and testing. Otherwise, the new expectations arrive while everyone’s calendar remains booked against the old ones.
Trust had an operating requirement
Scope, time, change and status lived in shared records. Artifacts, file structures and workflows followed consistent conventions. I didn’t need everyone to explain their personal filing philosophy before I could find a decision.
Thomas could resolve a question with a developer. I could see the decision and act if it created a scope, schedule or capacity concern. Change control had explicit ownership: Thomas validated the solution impact, I approved the delivery and commercial commitment, and the customer signed off. Nobody had to guess whether “we discussed it” meant “go build it.”
For AI-first delivery, I would extend that discipline to agent scope, evaluation results, required approvals and ongoing monitoring and support. When the design changes, the team needs to know what must be retested and whether the change affects go-live readiness or how the solution will be monitored and supported in Operate.
A successful pod is a result of data discipline, not a substitute for it.
Without that foundation, you’ve given one PDM too many projects and a longer list of people (and agents) to chase.
The foundation for what comes next
ModernOps EDGE grew out of this experience. Establish trusted information and clear ownership. Discipline how work enters, moves and changes. Govern commitments through visible decisions and checkpoints. Elevate performance through better information, mentorship and continuous improvement.
That foundation supports both delivering agents to customers and using agents inside the practice. An internal delivery agent could flag a scope deviation, surface a capacity conflict and route the next decision to its owner. The pod gives that signal somewhere useful to go: a person with context, authority and responsibility for acting.
Team Endeavor demonstrated the operating principle I recommend for AI-first delivery: capable people, shared information and clear authority can deliver together without waiting for every decision to climb the hierarchy.
The practical test for a Practice Leader is simple. Pick one AI-enabled engagement. Trace a change to an agent’s scope through design, approval, testing, deployment and ongoing support. Can everyone see who owns the next decision? Can that person act?
Hire the talent. Build the team. Give them the data. Trust them with the results.
Give peas a chance.
Revenue is closed in sales. Margin is realized in delivery.
— Let’s elevate! DGM
Source: Microsoft Learn: Organize your Dynamics 365 project team