From 5 to 20 Reviews a Day, with Overlooked Issues Surfaced — A BeSir Procurement Agent Case Study
How BeSir connected buyers’ judgment, Workflow, and Apps to increase daily review throughput from five to twenty per buyer and surface overlooked procurement issues.
On this page
After this procurement agent implementation, new purchase requests were reviewed automatically through Workflow, allowing buyers to focus on the areas requiring human judgment. Average daily review throughput increased from five to twenty requests per buyer, while the agent also surfaced overlooked discrepancies and missing explanations for higher prices. Achieving that change required more than selecting a model. The implementation addressed the gap between policy and practice, buyers’ implicit reasoning, consistent process execution, and the screen used to review results.
Start with the gap between policy and practice
Read procurement policies, retrieve past purchases, and assess a new request. Described this way, a procurement agent’s role seems straightforward. In the implementation, however, written rules did not fully explain how the work was done.
There were differences between formal policies and the criteria buyers applied in practice. Urgent requests were particularly difficult to handle by following the standard procedure alone.
Policy remained the foundation for decisions, but it did not describe every situation. Simply automating every existing practice was not the answer either. The work began by making these differences visible and identifying where judgment and organizational agreement were needed.
The question expanded from “What does the policy say?” to “What does the buyer check in this situation, and what evidence supports moving to the next step?”
Make implicit judgment visible through actual cases
Asking experienced buyers to explain their process was not enough. Familiar checks can be omitted from an explanation precisely because they have become routine. What is obvious to a person may need to be made explicit for an agent.
We interviewed buyers while following actual purchasing cases one step at a time. We examined which information they checked first, when they sought additional material, and what supported their assessment. The observed facts were entered into the Enterprise Compiler.
Different buyers also used different review methods. We collected those methods with policy as the foundation, resolved conflicting approaches through agreement, and converted complementary methods into organizational knowledge.
Building the agent was not about copying one person’s habits. It was about making distributed judgment explicit and organizing it into criteria the team could share.
Similar purchases did not look similar in the data
Retrieving comparable past purchases presented another challenge. Two records might both concern relational database systems, yet contain only different product names. Those names alone did not provide a reliable basis for recognizing that the purchases belonged to the same category.
Buyers did not rely on a single lookup method:
- They searched purchasing history with keywords.
- They checked item codes to identify categories.
- They used web search to clarify ambiguous product names.
- For services, they reviewed the work execution plan as well as the purchase record.
We defined these working methods in the ontology so the agent could use multiple approaches to find comparable purchases.
The ontology did more than categorize data. It connected what makes two purchases comparable with what needs to be checked to establish that comparison.
Separate contextual judgment from consistent process execution
Procurement review requires judgment appropriate to the situation. It also contains repetitive work that must follow a defined process every time.
During implementation, relying on an LLM to follow the procedure led to variation in a workflow that needed to remain consistent. We addressed this by using BeSir Workflow to define the required sequence.
Understanding business context and executing a process consistently were both necessary. The agent handled interpretation and judgment, while Workflow structured the repeatable process.
Buyers needed a familiar review screen, not a wall of text
Producing an answer did not automatically reduce the buyer’s workload. In the existing procurement system, buyers knew where to find and compare each item. Receiving the same information as a long text response meant locating and cross-checking it again. Reviewing the agent’s output could take longer.
We addressed this by using BeSir Apps to recreate the review screen in the same form as the existing procurement system. Buyers could inspect the agent’s results within a familiar screen layout.
An output becomes useful in a business process when someone can understand it, review it, and take the next action—not merely when it has been generated.
A new request now starts an automated review
After implementation, a new purchase request triggered an automated procurement review through BeSir Workflow.
New purchase request → Automated review through Workflow → Human review where needed
Instead of examining every request from the beginning, buyers could focus on the portions requiring human judgment after the agent had performed its review.
The agent used the captured decision criteria, methods for finding comparable purchases, and agreed organizational standards. Workflow handled the defined process, while buyers inspected results in a screen matching their existing procurement system. The change reorganized the work around the issues requiring attention; it did not remove human judgment.
From five to twenty reviews a day—and overlooked issues surfaced
The time buyers spent assessing purchasing appropriateness, reviewing contracts, and examining technical specifications decreased substantially. In this implementation, average daily procurement review throughput per buyer increased from five requests to twenty—a fourfold increase.
The result extended beyond volume. The agent also surfaced issues that people had missed during review.
| Review area | Findings from the implementation |
|---|---|
| Quotation versus purchase request | Differences between quotation details and the purchase request |
| Comparison with past purchases | Missing justification when a purchase was more expensive than a comparable past purchase |
| Sole-source procurement | Whether organizational eligibility criteria were met and where further checks were needed |
These checks required more than reading each document separately. They involved comparing the request with the quotation, connecting past purchasing records, and applying the relevant criteria to the current request.
By performing these checks, the agent helped buyers focus on the issues it surfaced. The value was both greater review throughput and the repeated application of organizational criteria to identify overlooked items.
The throughput and findings describe this implementation. They do not guarantee identical results across procurement operations or the detection of every error.
Building the agent meant organizing how the enterprise makes decisions
The implementation required more than supplying policies and data. It involved making buyers’ reasoning explicit, reconciling different review methods, and organizing them into shared criteria. It also addressed how comparable purchases were found, how repeatable work was sequenced, and how results were presented for review.
Enterprise Context takes concrete form in this work. Written principles need to connect with business concepts, decision evidence, information-seeking methods, and criteria agreed across the organization.
The result did not come from the model’s ability to answer questions alone. It came from bringing together organizational knowledge, consistent execution, and a screen buyers could use to review the results.
Related reading: Why Agents Need Ontology · What Should Enterprises Own in the AI Agent Era?