Developing agentic AI across the trade-to-cash lifecycle

Where it starts

A delivery order lands as a scan in a shared mailbox. Someone opens it, reads it, types the details into the trade management system, then pulls up a warehouse stock report and starts comparing quantities against contracted volumes, line by line. It's a time-consuming manual process. Then the next one arrives, in a different format, from a different region.

Across the trade to cash lifecycle we assessed more than thirty candidate use cases and prioritised three. The proof of concept went to the hardest of them, warehouse inventory reconciliation: inconsistent scanned documents, optical character recognition, data split across two systems, and reconciliation logic that must be right every single time.

Choosing the hardest case set the design constraints. Work this exposed to judgement cannot be handed to a model and trusted on its output alone. It must be broken into steps that can be inspected, measured and stopped, which is what shaped everything that followed.

How the agent is built

Three principles shaped how the agent works. Structure the work explicitly rather than trusting a prompt to hold it together. Keep deterministic control wrapped around probabilistic reasoning, so the path through a run is predictable and every step is recorded. Put the real work in tools, where it can be tested, versioned and reasoned about, rather than asking the model to do it in its head.

In practice this capability leveraged LangGraph, with an explicit graph for planning, tasks, tools and sub-agents. The tools carry the load: Azure AI Document Intelligence extracts structured data from the scans, others retrieve documents and metadata from the document management system, query commercial data from the trade management system, reconcile the two, check against contracted limits and write the result back.

A fourth principle governs where it runs: an agent belongs where the data and the controls already are, not alongside them. Agents are deployed as hosted agents in Azure AI Foundry inside the client's tenant, governed by their existing identity and access controls. A Python FastAPI service sits between the agents and a React and Next.js front end that gives users a document viewer, a live agent timeline and the reconciliation output, ultimately presenting agent interactions in a user-friendly and consumable way. Cosmos DB holds memory and state, and secrets stay in Key Vault. None of that must change when this moves to production.

Where humans intervene

The principle here is that oversight belongs inside the agent rather than around it. Checkpoints are nodes in the graph, so the agent stops where judgement and accountability matter instead of wherever a wrapper happens to intercept. A reviewer needs evidence rather than an answer, so each pause surfaces the source document, the extraction and the reasoning behind it, with approve, edit and reject treated as equal outcomes. And every intervention is data: corrections are written to the same trace as the agent's own steps, so the audit trail shows what the agent did, where a human took a different view, and what the system should learn from it.

Evaluation and Observability

Evaluation came before confidence. Golden datasets were built with our trading experts, so quality is judged against how the business reconciles a load rather than a generic benchmark. A DeepEval suite covers extraction groundedness and end-to-end behaviour, with regression baselines running as unit tests in the delivery pipeline alongside Azure AI Evaluations. If a change degrades accuracy, the pipeline says so before anyone sees a demo.

Observability was treated as foundation, not instrumentation added once something broke. Traces follow the OpenTelemetry semantic conventions for generative AI and flow into Application Insights, capturing latency, tool calls and token usage at every step. That is what makes token metrics possible: knowing what each run, each agent and each model choice actually costs, so routing, caching and budgets are set on evidence rather than instinct. Running cost becomes a measured number in the first week instead of a question asked at the end.

Built to be reused

The codebase is a blueprint. Repository structure, configuration, the evaluation harness and the observability layer are all inherited by whatever agent comes next, so the second use case starts further down the track. This blueprint contains documentation covering architecture, integrations, evaluations, configuration and deployment.

A proof of concept does not have to be throw away. This one opened a path to production rather than starting from a blank sheet, and the same framework and approach carries into every agent build that follows.

What production-ready actually means

Behind the build sits a framework of twelve capability areas across five groups. It is the checklist we work through on each agentic engagement, and it is the reason this proof of concept looks different from most. Key areas are addressed during the build rather than deferred to a hardening phase that is built in isolation.

• Foundation and integration. User-led design feeding a real backlog, a standardised solution architecture, and API-first integrations that are reusable rather than bespoke.
• Security and governance. Runs in the client's tenant under least-privilege access with OWASP-mapped guardrails, version control, CI/CD gating and an end-to-end audit trail.
• Agent operations. Approval checkpoints in every flow, evaluations and guardrails that halt drift, and OpenTelemetry tracing of every decision, tool call and token.
• Optimisation and learning. Per-agent cost attribution driving model routing and budgets, with human corrections captured as retraining data for machine learning models and additional tools to enhance accuracy.
• Experience and testing. A design-led interface with clear approve, edit and reject controls, backed by unit, integration, performance and agent-evaluation runs.

Taken together, the twelve areas are what separates an agent that demonstrates well from one that can be run, audited and paid for. Not all aspects need to be addressed during the first proof of concept, but each should progress the build closer to production, so that what follows is a continuation rather than a fresh start.

Why it matters

Return to the shared mailbox. The scanned delivery order still arrives, but it is now read, extracted, reconciled against contracted volumes and prepared for approval before anyone opens it, with the reviewer confirming the judgement rather than performing the comparison. That is the outcome the business cares about. The harder question is whether it survives contact with production, and most agentic proofs of concept do not. They show that a model can complete a task, then stop, leaving control, cost and repeatability to a later phase that quietly becomes a rebuild.

This work sits deliberately between a pure proof of concept and an MVP. The engineering is production standard: the architecture, guardrails, human checkpoints, evaluation harness, observability and deployment pattern are the ones that carry into live running, built to the same twelve capability areas we would apply to any agent going into production. That distinction is the commercial point: the gap to go-live is a known, costed list rather than a second build. The client came away with a working agent on the hardest use case in scope, a validated architecture and a blueprint the next agent inherits. Whether the first agent works is rarely the difficult part. Whether the tenth can be built safely, rapidly and by someone else is the question worth answering.