The Agent That Says No
A four-agent procurement demo built to refuse. An agent that turns down an incomplete request is harder to build, and infinitely more credible in front of a client, than one that always says yes.
Project details
- Microsoft Copilot Studio
- Model Context Protocol
- Generative orchestration
- Synthetic data generators
Most demos are built to say yes
The standard agent demo is a happy path. Someone asks for something reasonable, the agent complies, everyone nods, and nobody learns whether the thing would survive contact with a real request.
This one is built the other way round. Four agents on Copilot Studio handle a purchase request, and the interesting behaviour is the refusal:
- Qualifies a purchase request against a written policy.
- Rejects requests that are incomplete or non-compliant with that policy.
- Scores the responses received, with no human in the loop.
An agent that says no is harder to build, because you have to encode the policy well enough to defend the refusal. It is also the only kind a procurement lead believes.
Watch it refuse
A request arrives, five filters run, one rejects it, and two reframes keep the conversation open. The refusal is the feature.
The lesson underneath it
This is the most senior point I take from building agentic systems, and it is not obvious until it bites you:
Restricting an agent through its instructions does not restrict it. The model can ignore an instruction. Under pressure, with a persuasive user, it frequently will.
You have to cut the capability itself. Disable the connector action, so the agent has no means of sending the email, rather than merely an instruction not to. Governance that lives in the prompt is a preference; governance that lives in the tool surface is a control.
128 tools down to 16
Building this hit the platform's function ceiling. The MCP tool surface had to come down from roughly 128 tools to 16 to fit under it.
That is not a footnote. Knowing a platform's real ceilings, and designing the tool surface as a budget rather than a wish list, is what separates someone who has shipped from someone who has followed a tutorial. It also makes the agent better: fewer, sharper tools produce more reliable orchestration than a large, ambiguous surface.
Why it is replayable
The demo ships with its own synthetic data generators, so it can be replayed at any client without touching a real dataset and without a lengthy setup. That is a deliberate constraint: a demo that needs live client data is a demo you can only give once.
The companion demo
Its counterpart is a conversational process analysis agent: nine MCP tools over real process mining data, answering in natural language and tracing every figure back to its source rather than guessing. I presented that one at a community call, with the build walked through end to end.
Recording, slides and the tool breakdown are on the talk page.
