AI Value Assessment
Workload shortlist, target architecture, governance model, business case and a recommended pilot.
Retrieval, tools and agents
Build the part the demo never shows.
Enterprise context the model can retrieve safely, tools it can act through, orchestration that holds under load, an evaluation harness that tells you when quality moves, and the ordinary applications that never used to clear the funding bar.
A pilot proves a model can do something once. Production asks whether it does the right thing on the case nobody anticipated, and whether you can tell the difference.
How it gets built
Five capabilities, built in this order.
The order matters. Teams that start at orchestration and work backwards to context spend the second half of the programme explaining why answers cannot be traced.
01
Context
Enterprise context and retrieval
The layer that decides answer quality. Sources are selected deliberately, chunked and indexed with their permissions intact, and tested against a set of questions someone has already scored by hand.
- Source selection and content governance
- Permission-aware indexing
- Citation behaviour and refusal behaviour
- A scored question set as the quality baseline
02
Tools
Tool access through MCP
What the model may read from and write to, connected through the Model Context Protocol. Every tool is scoped to a task rather than to a system, and every write is designed as a proposal until a gate clears it.
- Tool inventory with least-privilege scoping
- Read and write separated explicitly
- Failure and timeout behaviour defined
- Service identity distinct from any human account
03
Orchestrate
Orchestration and workflow
How a case moves: what triggers it, what the model may decide alone, where it must stop, and what happens when a tool fails halfway through. Most production incidents in agentic systems are handling failures, not reasoning failures.
- Trigger and queue design
- Step limits and stopping conditions
- Exception and escalation paths
- Idempotent writes and replay safety
04
Evaluate
Evaluation harness
A held-out set of real cases with known-good outcomes, run automatically on every change to a prompt, a source or a model version. Without it you are not managing quality, you are hoping.
- Held-out evaluation set built from real cases
- Automated runs on every change
- Regression thresholds that block a release
- Human review sampling on live output
05
Adopt
Interface and adoption
Where the work actually happens: inside Teams, inside the line-of-business application, or in a purpose-built review queue. An excellent agent behind a link nobody opens produces nothing.
- Interface placed where the work already happens
- Reviewer experience designed, not an afterthought
- Training for the approval decision, not the tool
- Usage reported against the funded outcome
Agent sorter
Five things get called agents. Two of them are.
Read the scenario and see which one it is, including the cases where the honest answer is that you do not need a model at all.
A search box over our policy documents that answers in full sentences with links to the source.
Retrieval, not an agent
This is a retrieval system with a model writing the answer. It takes no actions and makes no decisions. It is also one of the highest-value things most organizations can build, and it is cheaper and safer than anything below it. Build this first.
A nightly job that summarizes yesterday’s support tickets and emails the summary to the service manager.
A workflow with a model in one step
The schedule is fixed, the steps never vary and the model is doing one bounded task inside them. That is a workflow. Calling it an agent adds governance overhead and no capability. Keep the workflow.
A chat assistant that answers HR questions from the handbook and says when it does not know.
A grounded assistant
Useful, and the refusal behaviour is the hard part rather than the answering. Still not an agent: it neither chooses its own steps nor changes anything. Where it earns its keep is deflection volume, which is measurable from day one.
Given a failed three-way match, it gathers the purchase order, receipt and invoice, works out which one is wrong and proposes a correction for approval.
An agent
It selects its own steps, calls multiple systems, reaches a conclusion the designer did not script, and proposes an action. This needs an evaluation harness, an approval gate and an audit trail. It is also where the hours are.
It watches an exception queue, investigates each case, calls systems to gather evidence, resolves within policy or escalates with a recommendation.
An agent, and the demanding kind
Continuous operation, variable steps, and a policy boundary it has to respect without supervision. Worth building, and worth building last. Start with the investigation and keep the resolution behind a gate until the evaluation data earns the autonomy.
We would rather lose the agent scope and keep the client. A workflow that runs correctly every night is worth more than an agent that is interesting in a steering committee.
What it can reach
Your systems, reached through permissions you already grant.
Anthropic’s Model Context Protocol gives Claude a standard way to reach tools and data sources. What it does not do is decide what your model should be allowed to reach. That is a design job, and it is where most of the risk sits.
- Microsoft 365, SharePoint and Teams content, filtered by the user’s own entitlements
- Microsoft Fabric and the semantic models built on it
- Dynamics 365 records and business process events
- ERP and line-of-business systems, through their supported interfaces
- Document repositories, contract stores and ticketing systems
- Internal APIs, exposed deliberately rather than wholesale
An agent inherits the permissions of whatever identity it runs as. If that identity can read more than the requester can, the agent has become a way around your access controls. We design for this before it is a finding.
What changed underneath
The quietest change is what software now costs to write.
A large share of the value here is not an agent at all. It is the ordinary application that was always obviously worth having and never cleared the funding bar: the reconciliation tool, the integration two vendors will not build, the front end over a system nobody can use. Those projects were rejected on cost, and the cost moved.
One example from our own work. A client needed to check mileage claimed against GPS routes, against the distance those routes should actually have required. At volume it is not a judgement problem, it is an arithmetic problem nobody has the hours for, so it was sampled rather than checked. AIM built the tool that does it properly, comparing recorded routes against distances calculated through Azure Maps. It was developed with Claude, and two years ago it would have been scoped, costed and declined.
What now clears the bar
- Reconciliation and audit tools across two systems that were never designed to agree
- Internal applications for a team too small to justify a project
- Integrations the vendors on either side will not build
- Migration and transformation tooling that gets used once and discarded
- A replacement for the spreadsheet quietly running a real process
- A usable front end over a system people avoid
This work sits with AIM’s Application and Cloud Modernization practice. The governance on this page still applies: an engineer owns what ships, and a tool that touches financial or personal data goes through the same review as anything else we build.
Where to start
Three engagements, in order.
Enterprise Knowledge Foundation
One governed retrieval layer over a priority content domain, with permission fidelity and citation behaviour tested.
Governed Agent Pilot
One process, production intent, a KPI baseline, an evaluation harness and a scaling decision at the end.
Dexter, AIM’s internal AI-assisted delivery platform, is used on these engagements to accelerate build and test work. It is part of how we deliver rather than a product you licence.
One partner. The full journey. No handoffs.
Start with the workload, not the licence.
A two-hour session with the people who own the process, the data and the risk. You leave with a shortlist of candidate workloads, the constraints that rule some of them out, and an honest view of which one is worth a pilot.