Agentic Transformation Management: The Next Operating Model
The change is in how work is shared between the system and the people accountable for the transformation
It’s Thursday morning. A program manager is preparing a decision for the steering committee: should the next market go live as planned? Since the last review, a test has failed, a supplier has moved a delivery date, and the business owner has changed the scope of the pilot. Each change is recorded somewhere. The program manager still has to work out how they fit together, which facts are current and what the committee actually needs to decide.
What if the transformation workbench could do some of that preparation? It could retrieve the approved scope, find the dependencies affected by the supplier delay, check the evidence against the release criteria and draft the options for review. The program manager could then spend the meeting preparation testing the recommendation and resolving disagreements with the people who own the work.
That is the opportunity behind agentic transformation management: people direct AI agents to perform defined management activities, with access to the right information and clear limits on what they can do. The change is in how work is shared between the system and the people accountable for the transformation.
A useful agentic transformation management model needs a job it can finish
An agent can use tools to retrieve information, analyse it and take permitted actions. Give it a specific objective: “Prepare the release readiness review for Market B using the approved scope and current acceptance evidence.” Define what counts as a complete answer, which sources it can use, where it may write and when it must ask for help.
“Tell me whether the program is on track” leaves too much open. Which baseline applies? Does a green team status mean the capability is ready for use? Can the agent treat an unconfirmed dependency as a commitment? A persuasive answer can conceal those ambiguities. The agent needs to surface them.
Start with the simplest way to do each part of the work. A rule can check whether a required owner is missing. A fixed workflow can collect current records and put them in a review template. An agent is useful where the path varies, such as when it needs to investigate conflicting evidence or follow a changed dependency across several teams.
Anthropic distinguishes fixed workflows from agents that choose their steps at runtime, and recommends adding complexity only when it improves the result.[1] Its workflow guidance also describes how checks can run in sequence or in parallel, and how a separate evaluation step can review a draft.[2]
What the pattern, graph and workbench each provide
The earlier articles in this series introduced three parts of the operating model. Together, they give an agent enough structure to contribute to real work.
Component | What it gives the agent |
Transformation Pattern | A repeatable way to do the job: what triggers it, what to check, which evidence to use and when to stop. |
Transformation Graph | The context for this case: how objectives, features, decisions, dependencies, owners and evidence relate. |
Transformation Workbench | A place to do the work: tools, permissions, a review queue, an activity record and a route to the accountable decision maker. |
A release pattern may require operational acceptance. The graph identifies which service owner and evidence apply to this release. The workbench lets the agent request a review through a defined route and records what the owner decides. The same pattern can be reused for the next market, with different scope, dependencies and acceptance conditions.
An illustrative example: preparing a rollout decision
A manufacturer has piloted a portal where distributors can check order status. The next market is due to launch. A new test result shows that split shipments can display a misleading status. The pilot had excluded some split shipments, but the approved scope for the next market includes them.
The failed test triggers a release review. The agent reads the scope baseline, the test and its date, the linked order-feed dependency and the service owner’s acceptance conditions. It sees that the team’s green status predates the failed test. It can show the discrepancy without changing the status or assuming that the test has been reproduced.
The agent assembles two options for review: correct the feed and repeat the relevant tests before launch, or propose a narrower rollout with the excluded order types clearly communicated. For each option it lists the affected commitments and evidence needed. It marks the revised estimate as unconfirmed and asks the integration lead to validate it. It also asks the business owner whether a narrower rollout would still produce useful evidence about the intended reduction in service enquiries.
The release owner checks the sources and asks the teams to confirm the consequences. The authorised group then decides whether to change the scope or date. The workbench links that decision to the baseline, the test, the confirmed estimate and the actions that follow. At the next review, the team can see what it decided, why, and what has changed since.
The same approach can support other parts of the lifecycle. A refinement agent can flag an ambiguous acceptance criterion and draft a question for the product owner. A dependency agent can identify commitments that may need review when a date moves. An estimation assistant can compare relevant past work and show which assumptions make the comparison weak. A planning or risk agent can flag a conflict and route it to the people able to resolve it. The value comes from giving each agent a defined responsibility and a clear handover.
Set authority by the consequences of the action
The same agent may be allowed to draft a recommendation and save it for review, while having no authority to carry out the recommendation. Be explicit about the distinction.
Action | Appropriate authority |
Analyse and recommend | Read approved sources, compare records and draft options with evidence and uncertainty visible. |
Make a bounded, reversible change | Save a draft or create a review item in an authorised queue under rules that make the change visible and easy to undo. |
Make a consequential decision | A named person or governing body approves changes to investment, scope, launch dates, risk acceptance or business commitments. |
A technically reversible change can still have consequences. An automated notification about a launch delay can alter other teams’ plans before the delay is confirmed. Permissions should reflect the effect on people and commitments as well as whether the system has an undo button.
NIST’s AI Risk Management Framework organises risk work around governing, mapping, measuring and managing.[3] In a workbench, that means assigning an owner for the agent’s remit, recording the sources and actions behind its output, and providing a way to pause the workflow when it behaves unexpectedly. Microsoft’s 2025 Work Trend Index describes the emerging role of people directing and managing agents.[4] In transformation management, directing agents includes deciding which work to delegate and which judgments require human involvement.
Measure the decision process, not the activity count
Start with one recurring decision that already costs time to prepare. Give the agent read access and have it produce a draft alongside the existing process. Ask the people who normally prepare and review the decision to compare the two outputs against the same criteria.
Check whether the draft finds the material dependencies, uses current records, distinguishes confirmed facts from assumptions and makes its claims traceable. Include cases with missing evidence, conflicting sources and changes to the baseline. A useful agent should know when it cannot reach a conclusion. Check how often reviewers find material omissions or false alerts, and how long it takes to verify and correct the output. Include operating costs and the work needed to keep the sources current.
Only then look for a business effect: Are decisions ready earlier? Do fewer reviews end with a request to reconstruct the evidence? Do affected teams receive clearer follow-up? A faster draft is of limited value if it shifts the same work to a reviewer. DORA’s 2025 research on AI-assisted software development describes AI as amplifying the strengths and weaknesses of the organisation around it.[5] That is a useful caution for transformation leaders: if nobody maintains the scope baseline or owns a dependency, those gaps still need to be resolved.
At LINNFOSS, this is the direction we see for the transformation workbench: reusable patterns describe the work, connected information gives it context, and agents can help prepare and coordinate it within limits set by people.
Take the next decision your team has to make. Identify the preparation you would delegate, the evidence you would require and the point at which a person must take over. If you can specify all three, you have a practical place to start.
References
Anthropic — Building effective agents. Distinguishes workflows from agents and explains when to keep the design simple.
Anthropic — Common workflow patterns for AI agents and when to use them. Explains sequential, parallel and evaluation patterns.
NIST — AI Risk Management Framework Core. Provides a framework for managing AI risk throughout the lifecycle.
Microsoft — 2025 Annual Work Trend Index. Presents Microsoft’s research and perspective on people working with and directing agents.
DORA — State of AI-assisted Software Development 2025. Examines how organisational conditions shape the effects of AI adoption.
Tags:
Comments