Multi-agent on Microsoft / Copilot Studio, Power Platform, Azure
AI Value Register
An operating model for putting AI to work inside a business. Four connected agents take an idea from anyone in the organisation, decide how it should actually be built, screen it for risk, and attach a value case the business can be held to.
Every organisation has more AI ideas than capacity, and no consistent way to choose
The ideas arrive from everywhere. Some need a model. Several need a spreadsheet fixed. A few should not be built at all. Without a consistent way to tell them apart, the loudest request wins and the programme spends its budget proving that.
The second problem is quieter and more expensive. Benefits get claimed at approval and almost never verified afterwards, because nobody wrote down what would be measured or captured a baseline before the build started. A year later the programme reports success on the strength of the fact that things got built.
Knowing what not to automate protects a programme more than any model does.
Five stages, four agents, one register
Each agent does one job and hands on. Splitting them is not decoration: it is what allows risk to hold a veto over feasibility, structurally, in a place you can point at.
- 01Intake
Takes a use case from anyone in the business in plain language and turns it into a complete record. Elicits what it does not know. Never fills a gap with a plausible number.
Copilot Studio - 02Triage
Returns one of four verdicts with written reasoning: deterministic automation, generative assistance, agentic, or not yet. Names which test decided it.
Connected agent - 03Risk
Runs five questions covering personal data, decisions about people, cost of being wrong, verifiability and accountability. Holds a veto over the triage verdict.
Connected agent - 04Value
A specialist agent hosted in Azure AI Foundry and connected into the orchestration. Estimates effort and benefit from real volumes, with the arithmetic itself computed in a Power Automate flow rather than by the model, and no calculation attempted when an input is unknown.
Azure AI Foundry - 05Register
Writes the approved record to a benefits register in SharePoint, reported in Power BI as claimed value against realised value, with overdue reviews visible and a review date somebody owns.
SharePoint + Power BI
One rule decides the order of everything
Risk overrides feasibility. Value decides order. Anything unmeasured is a proposal, not a benefit.
Most intake processes ask one question: can we build this? That question is easy and it is the wrong place to start, because the answer is nearly always yes. The three that decide anything are whether we should, what it is worth, and how we will know it worked.
The four verdicts
Triage returns exactly one, decided by two questions in order. Does this need the system to understand language or unstructured content? If no, it is deterministic automation and a model would add cost, latency and a new failure mode for nothing. If yes: can the complete flowchart be drawn in advance? If it can, it is generative assistance, a model in one box of a fixed path. If the system has to choose the path itself, it is agentic.
Multi-step is not agentic. Using tools is not agentic. Deciding the path is agentic. That distinction is the one the industry gets wrong most often, and it is the difference between buying an agent and fixing a query.
The fourth verdict is not yet, with a reason recorded every time: the data does not exist, the decision is too consequential to delegate, or the value does not justify the build. It always carries a condition for revisiting. It is a date, not a rejection.
The five risk questions
- Does it touch personal information?
- Does it make, or materially influence, a decision about a person?
- What does one confidently wrong output cost, in consequence rather than probability?
- Can the output be verified against a source? If not, it cannot run end to end.
- Who is accountable when it is wrong? A named role, or it is not ready.
The veto has a deliberately narrow trigger. It overrides feasibility only when a decision about people is made at scale and the people affected would not know it happened. Drafting a letter someone reads and sends is assistance. Ranking applicants out of a process nobody reviews is the decision itself. A screen that fires on the word "personal" would block half the register and teach everyone to route around it.
The two fields nobody fills in
Every value case must carry a measurement method naming a metric, a source and an owner, and a baseline captured flag with a date. If you do not know what you are measuring before you build, you will not be able to measure it afterwards. Making both mandatory is the whole method; everything else is bookkeeping.
The behaviour it was built to get right
A gap in a record is not a value. The system is designed so that an absence of information stays an absence all the way through to the register, instead of quietly becoming a number somebody later signs.
Four defects, each a different species
All four were found by running the same script repeatedly and reading the output closely, not by testing whether it worked. It always worked. It was wrong in ways a pass or fail check would have missed entirely.
A rule written to record when the agent had suggested a value, so an anchored number could never be mistaken for a volunteered one, was applied to the record title: "Vendor invoice PO matching (agent-suggested, confirmed by submitter)".
The agent followed the instruction correctly. The instruction was too broad. Scoped it to the fields that feed a calculation or a decision, and excluded descriptive ones.
Fields were arriving as "unknown — not sure how many, it varies a lot". The note was valuable; storing it inside the value destroyed the value. That field has to become a number for the calculation, and later sit in a numeric column.
Split data from commentary: values stay clean, all annotation moved to a separate notes object keyed by field name. The first attempt at the fix did nothing, because an older instruction still said "never add a key" — a new rule is not in force until every instruction that contradicts it has been updated.
The same field returned as text on one run and a number on the next, with nothing changed in between. Everything looks correct until a numeric column rejects a row or an average is quietly computed over text. Only visible by running the same script twice and comparing.
The agent noticed a use case might really be two, and needed somewhere to say so. The notes object was keyed by field name and this was about the whole record, so it invented a key.
The observation was correct and the schema had no home for it. Not a defect I could have reasoned my way to from a chair: the schema looked complete until something real turned up that did not fit.
A register that can show you its own overdue reviews
Approved cases land in a register reporting claimed value against realised value, with realised hours left deliberately blank until a person fills them in at review. Blank, never zero: a blank is an absence of measurement, a zero is a claim that the work takes no time, and collapsing those two is how a programme reports success it has not earned.
On first load it read three initiatives, hours claimed, nothing yet verified, one review already overdue. That is the honest state of any programme in its first month, and a dashboard that showed green instead would have been lying.
- Agents
- Microsoft Copilot Studio with connected agents and generative orchestration, plus a specialist agent in Azure AI Foundry
- Model
- Claude Opus 5 via Copilot Studio
- Automation
- Power Automate, agent-triggered flows with typed inputs and outputs
- Data
- Dataverse, SharePoint list as the register
- Reporting
- Power BI: claimed against realised value, pipeline by verdict, and overdue reviews surfaced rather than buried
- Platform
- Azure and Azure AI Foundry, Power Platform developer environment, DLP and environment governance
- Assurance
- Labelled scenario set written before the build, run log, written defect log