This is a development preview of the site for the authors. Enter the review password to continue.
AI agents are moving into the decision points organisations run on. Two companion practice guides define the discipline for governing what has been delegated to them: The Decision Analyst examines each decision point before an agent takes it over, and The Decision Architect owns the estate those decisions add up to.
Forthcoming from Routledge (Taylor & Francis). Manuscript submitted September 2026.
The discipline defines two roles, and each role gets its own practice guide. The books are written to be taught together: ten chapters each, one chapter per teaching session, with shared terminology, a shared competency framework and a shared set of artefacts.
When an AI agent replaces a person at a decision point, human judgement is replaced by a probabilistic decision. The agent will be right most of the time. The questions that matter are how often it is wrong, what a wrong decision costs, and who answers for it. This book defines the role whose job is to find out before the agent is deployed, and the Decision Requirements Document (DRD) that records the analysis.
The Decision Analyst stands at one decision point and inspects it. The Decision Architect stands back and looks at all of them: the thousands of decision points an organisation actually runs, the agents now sitting in them, and the flows between them. Its central claim is that this layer, the organisation's decision DNA, sits above the systems and below the strategy, and nobody currently owns it.
Every approval step, eligibility check, priority ranking, routing rule, threshold and escalation is a decision point. Organisations are placing AI agents into them at pace, usually with testing that asks whether the software runs. An AI agent needs a further layer of testing that software never required, because it is substituting for human judgement: how often is it right, how does it behave at the edges, and what does a wrong decision cost?
The Decision Analyst works through 11 Decision Components for each decision point and reports the analysis in a Decision Requirements Document, which goes to the Decision Architect, the AI Committee or the Board before the agent is implemented. The natural feeder for the role is the Business Analyst, with risk and governance literacy and the testing of probabilistic decisions added.
On what legal or delegated basis is the decision made?
Who answers for the outcome?
What data feeds the decision, and can it be trusted?
What determinations is the agent allowed to return?
What is the consequence if the decision is incorrect?
Can it be reduced to rules, or is human judgement still required?
What flags hand the decision back to a person?
Can the decision be reconstructed after the fact?
Could the organisation take the agent out again?
What can the agent reach, and what can it do?
What does the decision point cost to run, and to get wrong?
Every component, analysed and signed off before implementation.
The right to decide or act, traced to a Delegation Register, policy or position description. When an agent takes over, the authority must be reassigned, not assumed.
The obligation to answer for the outcome. It sits higher than the person who holds the authority, and it never transfers to an AI agent.
The duty to carry out the work. Not the same as answering for the outcome. The method depends on holding the three apart.
The Decision Analyst's principal deliverable: one document that records the analysis of a decision point and becomes the basis for commissioning, testing and governing the agent placed in it. Eleven sections, drawn directly from the components.
On the Monday, a hardship agent in customer care reviewed an age pensioner's overdue account, found three missed instalments and a concession card on file, approved a six-month payment arrangement and wrote to confirm it. On the Thursday, a collections agent in finance reviewed the same account, found it more than 90 days overdue and above the referral threshold, referred it to an external collection agency and wrote to say so.
Neither agent had failed. Each had a sound DRD, a named accountable officer, a tested error rate and approval from the AI Committee. What neither document contained was any reference to the other agent. For years the overlap had been resolved by two people emailing each other. When the two people became two agents, that coordination vanished, and nothing in the organisation was positioned to notice. The complaint reached the ombudsman within the fortnight.
Enterprise architecture owns how information moves between systems. Business architecture owns capabilities and value streams. Neither records who is allowed to decide, on what basis, and who answers when it is wrong. That middle layer is the organisation's decision DNA: its Decision Network Architecture. Every organisation has one; most have never seen theirs drawn.
The inventory of decision points, human and machine, with tier, ownership, automation status and delegation level.
The organisation's decision layer, defined as an architecture with its own views, made visible and kept current.
How decision points chain, feed and depend on each other, including agent-to-agent flows and flows that cross the organisation's boundary.
Machine limits recorded alongside human ones, stewarded by the Decision Architect as configurations and thresholds change.
Which decisions to automate, keep with a person or retire, run through the lifecycle from design to retirement.
The decision point as a first-class object, linked to agent, process, system, rule, risk and delegation instrument. The schema behind the forthcoming tool at rigor.apps.
The templates and references that make the method usable from day one. [Prototype note: gating shown is indicative; each resource can be set to open, email-gated or reserved once decided.]
The Decision Requirements Document in an editable format, structured by the 11 components.
A one-page checklist for interrogating a decision point before automation.
One decision point analysed end to end, genericised, showing the method in action.
The tiered risk classification that sets governance requirements for each decision.
Design, Approval, Testing, Deployment, Monitoring, Review, Retirement.
The discipline's defined terms as a public reference, from decision point to decision estate.
Both books run ten chapters of 2,000 to 2,500 words, each mapping to one teaching session, and share a competency framework a training provider can certify against.
For inspection copies, course-adoption enquiries, rights and translations, contact the authors directly or via the publisher. [Placeholder: add the Routledge rights and inspection-copy links when supplied.]
Make an enquiryFor speaking, media, consulting, training, review copies, course adoption, or questions about the method, we welcome your enquiry.
Direct
Greg Timbrell: greg.timbrell@gmail.com
Scott Stewart: [preferred contact address to add]