9-minute read
Executive summary: AI assistants are shortening individual tasks in enterprise programs, but most programs still run on the same manual reporting, fragmented registers, and meeting-driven handoffs. Programs that redesign the delivery workflow itself, assigning repeatable steps to agents and naming where people review and decide, can reduce manual effort while keeping evidence and accountability intact. On a Workday enterprise resource planning (ERP) transformation at a state technology agency, Logic20/20 applied that approach: map the recurring deliverables, consolidate the sources, prove the method on one output, and expand as results support it.
Agentic delivery integrates AI agents into recurring program workflows, with defined responsibilities, approved sources, and accountable human decisions. Its value comes from changing how work moves through the program, not from speeding up isolated tasks.
Why AI adoption has not changed how programs run
An analyst uses an assistant to summarize a week of meeting notes in minutes, and adoption metrics suggest progress. The program still runs on the same manual reporting, fragmented registers, and meeting-driven handoffs, because the task got faster without any change to the workflow that connects it to the next one.
The weekly status report shows why. Drafting the narrative is one step. Someone must also gather current updates, reconcile conflicting information, check dependencies, assess whether reported health matches the evidence, and approve the report. A better draft leaves most of that workload intact.
Reliable program delivery depends on authoritative inputs, defined responsibilities, coordinated handoffs, and clear approval requirements, and a general assistant supplies none of them on its own. Mapping the full workflow makes a different approach possible: teams assign the repeatable steps to agents and name the points where people interpret findings or approve action. The difference shows up in four starting assumptions:
| Common starting point | What changes the workflow |
|---|---|
| Select a tool and look for uses | Map recurring deliverables, inputs, and handoffs before selecting capabilities |
| Judge an output by how well it reads | Check its accuracy, sources, completeness, and usefulness for the next decision |
| Use AI whenever someone chooses to open it | Integrate AI into an established reporting or review schedule |
| Leave review responsibilities informal | Name the reviewer, the decision, and the approval requirement |
The design work establishes what each agent can access, what it produces, and who reviews the result. Clear answers help teams integrate AI into program operations and assess whether it improves delivery.
Industry context: Designing for public sector delivery
Public sector transformation programs often combine extensive documentation requirements, audit expectations, and contractual capacity limits. Access to live program data may also depend on systems the client controls.
On a recent state agency engagement, those conditions shaped the approach from the start. The team needed to work from available exports and documentation, preserve the evidence behind its outputs, and use fixed analyst capacity well. Agent design began with those operating requirements.
Find the work before choosing the tool
The two speeds of program work
Program delivery includes two kinds of work. Assembling information (gathering updates, reconciling registers, retrieving documentation) follows repeatable steps. Judging it (assessing feasibility, evaluating risk, accepting a deliverable) requires context and an accountable decision.
Most activities mix the two. In a risk review, an agent can collect and compare schedule and budget data, but a program leader decides whether the evidence warrants escalation. The design task is to find that seam in each activity, because it defines what the agent does and what the reviewer receives.
Four questions that locate the work
Four diagnostic questions locate that work and show what each answer reveals:
| Diagnostic question | What it reveals |
|---|---|
| Which deliverables do we rebuild each cycle from information that already exists? | Opportunities to reduce repeated collection, reconciliation, and formatting |
| Where are people gathering or routing information, and where are they interpreting it? | Steps suited to agent support and points requiring judgment |
| Which sources are authoritative, and how are they maintained? | Data gaps, conflicting records, or refresh requirements to address before automation |
| What decision follows each output, and who owns it? | Review requirements, accountability, and the evidence the output must provide |
The diagnostic should follow the work across team and system boundaries. A reporting bottleneck may begin with inconsistent updates upstream, and automating the report without addressing those inputs reproduces the same problem faster.
Some activities may also be unnecessary. Mapping the workflow gives teams a chance to eliminate duplicate reporting or redundant handoffs before building agents around them.
Where repetitive work appears
Repetitive work tends to cluster in a few places, depending on the program type:
| Program type | Activities to examine |
|---|---|
| Enterprise transformation | Status reporting, requirements traceability, and cross-workstream dependency tracking |
| Capital and field programs | Work package updates, inspection documentation, and contractor coordination |
| Operations and shared services | Case routing, exception research, and recurring reconciliation |
| Product and engineering | Release notes, incident timelines, and backlog comparisons against the roadmap |
Each activity needs its own assessment. Routing a case may be straightforward when the criteria are clear, while an ambiguous or high-impact case may require immediate human review. The diagnostic identifies those boundaries before the tool is configured.
Business analysis on an ERP transformation
The challenge: Extensive documentation, slow retrieval
A state technology agency is modernizing enterprise finance on Workday as part of a statewide ERP program. Before Logic20/20 began the current phase of business architecture and analysis, earlier work had produced process and journey maps, persona definitions, a gap analysis, and a transformation roadmap. More than 300 documents were available. [Author to confirm the document count against the engagement record.]
The challenge was putting that material to work during two-week sprints. Three conditions increased the effort required:
- Prior findings were difficult to retrieve quickly. Relevant knowledge existed, but locating and interpreting it took time.
- Current sprint data required manual exports. The team could not query the client-owned system directly, so status reporting depended on exported data and manual preparation.
- Analyst capacity was fixed. Time spent assembling reports reduced the capacity available for business architecture and analysis.
The engagement needed a repeatable way to prepare delivery information while preserving the evidence and judgment behind it.
How the engagement was designed
The first two weeks focused on mapping the work. Our team inventoried recurring outputs, their inputs, the people involved, and how often existing material was gathered and rebuilt.
The action register emerged as an important foundation. Several versions existed across files, with inconsistent ownership and limited history. We consolidated the records into a single register with stable identifiers and a history that retains prior entries as updates are added. The register became the authoritative source for action tracking and the reporting elements derived from it.
We then established two requirements for agent-generated outputs:
- Human review before client delivery. A person reviews and approves every client-facing output.
- Traceability to supporting evidence. Figures identify the file, export, or transcript they were drawn from, and outputs flag claims the available material cannot support.
Both requirements were built into agent instructions and output formats, so reviewers could verify the evidence without requesting citations each time they used the assistant.
Adoption began with one recurring output that was especially burdensome to rebuild. Once the team could review the result and verify its sources, it requested support for additional work. A visible operational problem gave the team a practical reason to use the capability.
Execution insight: Test the difficult cases
A useful demonstration shows what an agent can produce. A dependable workflow also establishes what happens when inputs are incomplete or inconsistent.
Before expanding, effective teams test whether the agent flags a missing source, identifies conflicting records, and gives a reviewer enough evidence to verify a figure. They also confirm that the review requirement holds before an output reaches the client. Those checks show whether the workflow is ready for recurring use.
What the engagement has produced
The work spans two related areas: support for the consulting team's delivery workflow and agent opportunities within the agency's operations.
Project delivery support
The project assistant supports the recurring delivery cycle. It maintains the action register with stable identifiers and retained history, runs progress assessments twice a day against the engagement plan, assembles financial information from available inputs, and drafts the weekly status report.
The assistant also evaluates status reports for detail and candor. It compares reported health with supporting evidence and flags mismatches for human review. A person determines the appropriate status, then reviews and sends each report.
The workflow surfaces potential issues between meetings and gives analysts a prepared view of the evidence to assess. Human responsibility remains explicit at the point where findings become a client-facing assessment.
Agency operations
We used agents to assess process maps from the readiness work and develop a prioritized backlog of Microsoft Copilot agent opportunities, scoring each use case on business value, feasibility, and effort.
The agency-focused work also includes a writing agent that accelerates job aid preparation and knowledge agents that retrieve gap findings, remediation guidance, and process instructions with cited references. The prioritized backlog gives the agency a basis for sequencing further development and adoption.
Together, the two efforts address recurring information assembly and access to prior knowledge. The project assistant supports reporting and review, while the agency work identifies where similar capabilities can support staff in their own operations.
The proposed next phase: Coordinated PMO agents
The next opportunity is to apply the method across a broader program management office (PMO) workflow. The roster below is a recommended future design, not a description of the deployed environment.
| Agent role | Proposed responsibility | Decision retained by a person |
|---|---|---|
| Status reporting | Draft executive and sprint reports from approved project data sources | Determine whether reported health matches the evidence and approve the report |
| Risk monitoring | Review schedule, budget, and dependency information for potential risks | Decide whether to raise or escalate a risk and assign ownership |
| Coordination | Capture decisions, owners, and deadlines and track follow-up | Accept or renegotiate commitments |
| Dependency analysis | Map cross-workstream impacts and compare sequencing scenarios | Select the sequence and approve changes |
| Knowledge retrieval | Answer questions from approved plans, artifacts, and history with citations | Assess whether the evidence supports the conclusion and intended use |
| Orchestration | Route requests, sequence agent tasks, and identify review responsibilities | Resolve exceptions and approve outputs for release |
The roster's value depends on the handoffs. Agents need shared definitions, consistent records, and clear rules for resolving conflicting information, and each workflow needs a person responsible for reviewing its conclusions or authorizing action.
Expansion can proceed in stages. A team begins with an assistant supporting one deliverable, connects additional approved data sources under supervision, and then coordinates specialized agents across the workflow. Each stage gives the team a chance to assess accuracy, review effort, and operational value before increasing scope.
Four design rules for dependable agentic delivery
Programs that get dependable results from agents share four design practices.
Rule 1. Map the work before choosing the tool
Build an inventory of recurring outputs, inputs, owners, schedules, and handoffs. Identify how much of the work involves gathering existing information and where people make consequential decisions.
Use the map to select an initial deliverable with visible manual effort and a manageable review process. A baseline for preparation time and review effort lets the team assess whether the new workflow improves performance.
On the ERP engagement, the initial mapping took two weeks. The right scope and timing for another program depend on its complexity and the condition of its documentation.
Rule 2. Establish reliable sources and update rules
Agents need to know which records to use and how current those records are. For an action register, useful requirements include stable identifiers, clear item ownership, retained history, and a defined update schedule.
For workflows that use multiple sources, specify which source governs each field and how conflicts are handled. Export-based workflows should make the export date visible so reviewers understand the limits of the assessment.
Addressing those requirements reduces the risk that outdated or inconsistent information spreads across reports. As more agents are added, a shared, dependable foundation matters more.
Rule 3. Make evidence part of the output
Specify how outputs identify their sources, flag missing information, and distinguish supported findings from unresolved questions. Reviewers should be able to locate the evidence behind a figure or conclusion without reconstructing the agent's work.
Build those requirements into the output format and test them with incomplete inputs. An unsupported claim should appear as a gap requiring attention, not as a confident answer.
Traceability also makes review more useful. When verification is straightforward, analysts can spend their time interpreting the evidence.
Rule 4. Name the decision and its owner
Define what a person must review or approve after each agent task. Drafting a risk assessment, changing a program status, and releasing a client report carry different responsibilities.
Make the required decision and the responsible role visible in the workflow and, where useful, in the output itself. Establish an escalation path for missing evidence, conflicting records, and issues outside the agent's scope.
Clear responsibility helps the team use agent outputs consistently. It also keeps accountability connected to the work as capabilities expand.
Where to start
The approach begins with one recurring deliverable and uses it to prove the method before anything expands:
| Step | Action | Evidence to review before expanding |
|---|---|---|
| 1. Map the delivery workflow | Identify recurring outputs, inputs, manual effort, reviewers, and decisions | A clear scope and reliable sources for the first use case |
| 2. Prove the approach on one output | Configure agent support, source traceability, and human review | Preparation time, review effort, accuracy, and handling of missing or conflicting information |
| 3. Expand the workflow | Add data sources or specialized agents as needs and results justify them | Consistent handoffs, clear ownership, and dependable performance across the expanded scope |
The first output should show that the team can reduce repetitive work while preserving the evidence and accountability needed to act on it. Faster drafting is useful, but the fuller measure is whether the workflow gives people more capacity for analysis and decisions without adding avoidable review effort.
A well-scoped first use case also establishes the source conventions, review requirements, and ownership patterns that support later expansion across the delivery cycle.
Redesign the workflow, not just the task
If your programs have adopted AI assistants but still run on manual reporting and meeting-driven handoffs, let’s talk through where agents can take over the repeatable work.
About the author
Ben Higa is a Manager in Logic20/20’s Digital Strategy & Transformations practice with more than a decade of experience in project management, program planning, strategic communication, and digital marketing. He leads teams and stakeholder groups toward shared goals, aligning deliverables with business objectives and KPIs, and is known for clear progress reporting, strong presentations, and connecting diverse teams to deliver high-quality work.