Begin with a consequential workflow
Follow a process from its trigger to the accepted result. Record decisions, hand-offs, exceptions and dependencies. Then ask what AI changes: does it produce an output, recommend an action or execute a permitted step?
Each design creates different demands on quality, authority, review and recovery. Conventional integration or assisted work may meet the objective without an autonomous agent.
Make six operating choices
Where accountability sits
Name the business owner of the outcome. Distinguish responsibility for the workflow from responsibility for the model, integration and security controls.
Technology can maintain a platform without controlling how its output is used. A business owner can own the result without being qualified to approve a security design. Both responsibilities must be explicit.
What the system may decide or do
Reading a purchase order, drafting a change and approving payment are different permissions. Decide which actions may occur within tested limits, which require meaningful approval and which remain prohibited.
Technical controls should enforce the boundary where appropriate. A prompt is not a substitute for an access-control design.
Which capabilities should be shared
Common platforms, evaluation, procurement and security standards can reduce duplication. Process expertise and benefit ownership often need to remain close to the business.
Compare centralised, distributed and federated arrangements against actual decisions and constraints. A centre of excellence needs a clear service and mandate, not only an organisation-chart box.
How work is accepted
Define a good outcome and who can judge it. Include difficult cases and consequences of error. If AI removes preparation but increases senior review, review capacity becomes part of the design.
Where information comes from
Identify authoritative sources, permissions, version control and update owners. The model should not have to guess which policy, price or customer record is current.
A knowledge repository needs stewardship. More documents can make the context worse if contradictions remain unresolved.
How value and failure are managed
Measure accepted outcomes, full cost and material exposure. Define triggers for investigation, rollback, reapproval or retirement. A deployed system is an operating responsibility, not a completed experiment.
Design human and agent work together
A human-agent team is not an organisation chart with software names added. Include supervision, exception handling, customer relationships, professional judgement and learning.
Workforce decisions should follow evidence of changed work and the organisation's obligations, not a comparison between a licence price and a salary. Retained human capability can also be a resilience requirement: the fallback must be executable by people who understand the process.
Use a decision-rights map
For each important step, identify who proposes, approves, performs, checks and can stop. Compare that map with implemented permissions.
In a hypothetical supplier-record workflow, an assistant identifies possible duplicates and shows the evidence. A finance owner decides whether to merge them. A controlled system performs and records the approved change.
That differs materially from giving an agent broad access and asking it to “clean up suppliers”. The objective can be similar while authority and risk differ.
Sequence the change around constraints
Start with a scope the organisation can supervise and measure. Resolve its dependencies, then expand when the evidence supports it.
Avoid enterprise-wide redesign before learning anything, but do not pretend a local pilot has no wider operating consequences. Show the next decision, its evidence and the owner responsible for producing it.
The strongest operating model is the one the organisation can operate, not the most sophisticated diagram it can approve.