The most useful thing I’ve learned about AI in the past year isn’t a model release. It’s the difference between AI-powered software and an AI agent, and why that difference matters before making an AI investment.

Both are useful, and neither is interchangeable with the other.

The contrast

Software powered by AI is deterministic, cheap, and fails in known ways. You give it an input. It runs a defined process, often a single model call, and returns a structured output. The output may be wrong, but the kind of wrong is bounded. You can validate it, test it, and catch failures in QA. It costs cents to run and takes seconds.

An AI agent is autonomous, costly, and prone to unpredictable failures. You give it a goal. It decides for itself what to do next: which tools to call, which sources to consult, and when it has enough evidence to conclude. It iterates. It costs orders of magnitude more per task because it makes many model calls. And when it fails, the failure mode is often one you didn’t anticipate, because the agent did something you didn’t expect.

Both classes of system are useful for different problems. The mistake is treating them as the same thing.

Why this matters for procurement and risk

Vendor contract review and vendor risk briefing are routine work for procurement and risk functions. Both can be compressed from hours to minutes using AI tooling. The implementation choice, however, determines what you can actually trust the output for.

A deterministic contract analyser produces the same result for the same contract. You can audit it, version it, and build it into a workflow with confidence. It’s not perfect, but its imperfections are knowable.

An agentic vendor risk system can investigate more deeply than a checklist ever will. It can track corporate filings, surface adverse news, cross-reference sanctions lists, and synthesise findings into a brief. But two runs on the same vendor might yield somewhat different briefs, depending on what the agent prioritised that time. The depth is real. The variability is too.

Procurement teams may struggle to govern this distinction. That’s where the conversation about AI commissioning should start.

The prototypes — what they are, and what they are not

I’ve developed and deployed two narrow prototypes on my Test Environment for AI. One analyses vendor contracts. The other investigates vendor risk autonomously. They take minutes to try.

They are not built on a heavy framework. They are not the most technically ambitious demos you could build with current tools. That is deliberate.

Real AI advisory work is not about chasing every new orchestration library. It is not about wrapping fifteen abstractions around three API calls. The temptation to reach for libraries like LangChain at the start of any AI engagement is precisely the trap.

The abstractions feel like progress, but they are usually the wrong move until you understand the specific failure modes of the system you are building. Apply domain judgement first. Add abstractions later, and only when the abstraction earns its complexity cost.

What governance actually requires

The PETALS™ framework, which I developed for evaluating AI systems against governance criteria (purpose, effort, tools, assembly, leverage, and security), is what most procurement engagements actually need. Not another orchestration layer. Not another vendor demo.

The framework compels us to answer the questions: Does this system do what its designers claim? Can you show your evidence? Is there a person accountable when it fails? Will it still work in eighteen months? Can you operate it safely?

These are not technical questions. They are governance questions. The technology delivers the answers; the framework asks the questions.

The Cyber Quadrilemma, a diagnostic lens I use for security posture, applies a parallel logic across Code, Config, Compliance, and Culture. Where are the gaps? Where is the actual risk hiding?

Both frameworks exist because both questions, AI governance and security posture, need a structured way to talk about something most organisations are still learning to articulate.

The work begins where the prototypes end

The prototypes show what the patterns look like. They demonstrate the deterministic vs autonomous distinction in a way that text cannot. Try them.

The real work, for any organisation seriously commissioning AI, sits in the gap between the demonstration and production deployment. That work covers integration with your existing systems, security overlays appropriate to your jurisdiction, governance under your applicable regulatory regime, and the judgment on whether to proceed.

For a deeper assessment of your workflows, secure deployment, and integration, engage Grey Orbits. Reach out at support@greyorbits.com to discuss what would actually fit.

Related from Grey Orbits

About the Author

Viren Mantri is a cybersecurity advisor and former senior technology leader across Standard Chartered, UBS, McAfee, and KPMG. After three decades at the intersection of technology, risk, and regulation, he now helps organisations cut through complexity and make better security decisions.

CC-BY Viren Mantri, 2026, licensed under a Creative Commons Attribution 4.0 International License.

Disclaimer: All views expressed here are entirely mine.