AI procurement agent: where the current supply process breaks
A procurement request rarely arrives in a single format: email, work chat, department spreadsheet, verbal agreement after a planning meeting.
The procurement specialist manually consolidates this into a common register, clarifies the item nomenclature, and fills in missing fields — and the processing of procurement requests stretches out even before the first supplier offer appears.
Then manual supplier comparisons begin. Prices, shipment times, minimum order quantity, and payment terms live in email threads rather than a shared database: you have to compare using the latest message, and price history is not accumulated anywhere.
The same item from different suppliers comes under different part numbers and packaging — matching relies on a specific person's memory rather than rules, so when that person is absent, the process stalls.
A separate bottleneck is waiting for confirmations. Approval goes to a messenger, gets lost among other discussions, and the initiator checks the status several times.
While the request waits, the supplier's offer expires, the delivery date shifts, and some items go to urgent procurement on worse terms.
The cost of these areas is not in a single mistake but in accumulation: a noticeable share of requests goes outside the regulations, the time from need to order grows, urgent procurement becomes the norm, and savings on terms are lost unnoticed.
The bottlenecks of the procurement process almost always lie not in negotiations but in the manual transfer of data between people. We analyze how an AI procurement agent closes each of these areas — from parsing an incoming request to a ready order.
What changes after implementing a procurement agent
The first shift is visible in the request cycle. Previously, collecting the need, checking against the catalog, requesting offers, and approval stretched over days, and almost every action was done manually.
The AI procurement agent collects data from the accounting system and email, checks stock and active contracts, and gives the buyer a ready request with calculations — a person makes the decision rather than transferring numbers.
The share of manual operations drops to a level visible in the department's workload: standard purchases go into an automatic route, while non-standard items, negotiations, and risk work remain with the specialist.
Request processing time is reduced severalfold — waiting for a supplier response and internal approvals run in parallel rather than sequentially.
The quality of supplier data stops depending on employees' memory: the history of prices, actual lead times, and claims lives in a single register.
The share of delays falls due to early warning — the agent compares the current lead time with the item's history and escalates the request before the delivery is missed.
Some errors disappear not less often but entirely: duplicate items, purchases using an outdated price list, lost requests, approvals bypassing the regulations. Verification happens before sending, not after.
The agent works within the 1C:ERP environment through standard interfaces, so data does not diverge between spreadsheets and the accounting system.
Agent operating modes: autonomy and human control
An agent's operating mode is not a general "enable autonomy" setting but a policy at the procurement category level.
For each category, it is determined separately what the agent closes on its own, where it must stop for human confirmation, and which requests go to manual exception review.
This approach allows starting with strict rules and scripts and expanding the boundaries of autonomy as statistics accumulate, without rewriting the integration.
| Option | When suitable | Limitations |
|---|---|---|
| Rules and scripts | Repeatable purchases of fixed nomenclature, long framework agreements | Does not work on new categories, breaks on non-standard requests |
| Human confirmation | First months of operation, new categories, significant orders | Speed is limited by the approver's availability, request queue accumulates |
| Autonomy within limits | Established supplier base, standard volumes, thresholds set | Requires up-to-date limits and monitoring, thresholds need revision |
| Exception review after action | High flow of standard requests, mature rules and accumulated history | An error is visible only after the action, requires a decision log and quick rollback |
Autonomy boundaries are revised based on accumulated data: if in a category the agent works for a long time without rollbacks and returns, the threshold is raised; after a series of rejections, the category is returned to human confirmation.
Every agent decision goes into a log with justification, conditions used, and data source — so exception review takes minutes, not hours of checking email threads.
Implementation stages: process audit, scheme, verification, handover
We start the work not with model configuration but with process analysis: who initiates the request, where it is approved, at what step the supplier is involved, and which exceptions are handled manually.
Without this, the agent reproduces not the regulations but the department's habits — and discrepancies surface during live procurement. Below is the sequence of agent implementation stages with an artifact and a control point at each step.
- Description of the procurement process as is. Interviews with buyers, analysis of request and contract history, recording of forks and manual bypasses. The output is a flow diagram marking where a decision can be formalized and where it remains with a human.
- Map of decision-making rules. From the description, we identify conditions: category, deadline, supplier history, price deviation from usual. Each rule receives a priority and an attribute by which the agent applies it.
- Designing agent decisions. We divide actions into three groups: performs itself, proposes with confirmation, escalates to a human. Separately, we describe behavior when data is insufficient — the request does not "hang" but goes to manual review for individual calculationConnection with the accounting system. We set up the exchange of catalogs, requests, statuses, and documents, limit the agent's rights to the necessary operations. Every decision is written to a log with a basis and a link to the rule.
- Verification on historical data. We run the agent on past purchases and compare with actual decisions. We calculate the share of matches, analyze discrepancies: refine rules, leave disputed cases to a human.
- Acceptance of results and handover. Control scenarios on the working environment, exception regulations, buyer training, and handover of documentation with a rule map and control points.
Agent configuration, access policies, and integrations
The procurement agent does not work in a vacuum: it reads nomenclature, procurement history, and limits from the accounting system and acts on behalf of the company.
Therefore, along with the solution, the customer receives the entire supporting framework — from supplier selection rules to the on-call engineer's procedure. Below is a list of what remains in the customer's environment and lives without our involvement.
- Agent configuration — cards by procurement class: categories, quantity thresholds, supplier priorities, analog selection rules, stop conditions under which a request does not proceed further.
- Access policies and roles — who sees correspondence, who approves deviation from terms, who changes limits. The agent operates under a separate service account with the minimum required rights, not as a superuser.
- Integration with the accounting system — exchange scheme: which catalogs are read, how often, by what attribute items are matched; behavior when the system is unavailable and the retry procedure.
- Escalation regulations — conditions for stopping and handing the task to a human: non-standard item, conflicting conditions, dispute over delivery terms, counterparty silence longer than a specified period.
- Message templates — texts of requests, reminders, and rejections in the counterparty's language, with variable substitution and tone rules.
- Support instructions — where to view the agent's decision log, how to reproduce a specific case, how to roll back a settings change, and whom to contact when behavior deviates from expected.
We hand over the package to your repository under version control: any configuration change goes through review rather than being edited "in place". Describe the task — we will return with an estimate and a handover plan.
Case study: agent in supply — metrics before and after
What it was like before implementation
Supply handled requests manually: an engineer opened an email, checked the item against the nomenclature catalog in 1C, checked warehouse stock, clarified deadlines with the initiator, and only then assembled a package for approval.
One line took 20–30 minutes, and the request approval cycle stretched to 4–7 business days. With 60–80 requests per week, a queue accumulated, and some items went to urgent bypass of the regulations — that is exactly where nomenclature discrepancies arose.
What was changed and what was achieved
The procurement automation case was built not on replacing people but on removing routine.
The procurement agent accepts a request from email and a form, brings items to the catalog, pulls stock, price history, and previous suppliers, requests missing information from the initiator itself, and sends the package along the approval route.
The procurement specialist gets involved only where the decision goes beyond the rules: non-standard item, new supplier, exceeding the limit.
| Metric | Before | After |
|---|---|---|
| Requests without manual intervention | 0% | 74% |
| Request approval cycle | 4–7 days | 1–2 days |
| Nomenclature discrepancies | 12% | 1.5% |
| Procurement specialist time per line | 20–30 min | 4–6 min |
The class of eliminated failures — nomenclature discrepancies, duplicate items, and requests sent for approval without a confirmed budget — is closed at the input.
The relieved load on supply went not into idle time but into work with suppliers and urgent procurement instead of processing the queue.
How does the agent differ from rules and scripts?
Rules and scripts work as long as the request arrives in a marked-up form: the item is selected from the catalog, the quantity is a numeric field, and the supplier is from a list.
Such a scenario is reproducible: the same input yields the same output, and a failure is reproduced on a test set and fixed by editing a single condition.
This breaks on free text. "The same filters as last time, but more and with delivery to the warehouse" — you cannot write a rule for such a phrase: there are dozens of formulations, and the catalog has five similar items with different characteristics.
The set of conditions becomes overgrown with exceptions, each new one affects the previous ones, and the share of requests going to manual review grows.
The agent parses the wording as a whole: extracts items, matches them against the catalog and procurement history, completes missing conditions — unit of measure, packaging multiple, deadline — and marks confidence for each line.
In case of ambiguous matching, it does not guess but forms a clarifying question to the requester and records the reason.
The boundary is drawn by the cost of an error. Limits, approvals, and audit remain with deterministic checks: the agent prepares data and justification, and the rule makes the decision.
This preserves a reproducible trace for each request and reduces manual review without loss of control.
Common technical questions before starting
Before starting, they check not whether the system can read emails but how it behaves in disputed cases. Below are answers to engineering doubts that most often decide the fate of the project.
What happens if the agent makes a mistake?
The agent does not write to the accounting system directly: it prepares a draft with justification and a source link, and the entry goes through confirmation based on a confidence threshold.
Anything below the threshold goes to a human in the review queue, and decisions are logged — rule version, input data, result.
How does the system handle non-standard requests?
Deviations are recognized by structure: new category, atypical field combination, unfamiliar wording. The agent does not fill in such requests by guessing but marks them and passes them to the responsible person, indicating what was missing for a decision.
Are changes needed in the accounting system?
At the start, reading catalogs and request history is sufficient — processing takes place in a separate environment with reconciliation.
If the accounting system provides data through standard interfaces, almost no modifications are needed, and writing is enabled after parallel operation.
Are there restrictions by category and role?
The customer sets the boundaries: categories, available counterparties, roles, and the circle of approvers. Categories with informal conditions remain with a human — the agent prepares a reference but does not make the decision.
Who is responsible for the agent's decisions?
The customer approves the rules and thresholds, and disputed cases always remain with a human: the agent executes the regulations rather than making decisions. The log shows why an option was proposed, and the employee who confirmed it is responsible for the final request.
Let's discuss the task: where we start
The first conversation is not a solution presentation but an analysis of the procurement process: who initiates the request, where it is approved, at what step the supplier appears, and which exceptions break the regulations.
We need the entire path, including manual bypasses and spreadsheets that live outside the accounting system — that is exactly where the agent most often delivers effect, not in the formal part of the process.
Preparation for the start on the customer's side is minimal but specific:
- a sample of closed purchases: requests, received offers, final terms — in any format in which they exist;
- supplier and nomenclature catalogs as is, without preliminary cleanup: we will assess data quality ourselves;
- approval routes and a responsibility matrix — by category, amounts, and divisions;
- access and data for the first environment: a read-only account, a database copy or test bench, and a communication channel;
- data restrictions: what cannot be taken outside the perimeter and what must be anonymized before the start;
- acceptance criteria: metrics that we fix before work begins so that there is something to compare the result against later;
- a responsible person on your side who confirms the logic and accepts the work by stages.
With these inputs, we prepare a work plan for the agent: the scope of the first environment, stages, team composition, dependence of deadlines on data readiness, and points where your decision will be required.
We return with a plan and estimate within the agreed timeframe, with explicit assumptions — so that further discussion is about concrete steps rather than expectations.
Describe the task in a message: which systems are involved, what data is available, and what you want to get as a result. We will have a call, clarify the details, and return with an estimate and a launch plan.