A B2B procurement agent is a system in which an AI agent autonomously makes decisions and executes a series of tasks—from receiving purchase requests to issuing POs (purchase orders). This article is intended for procurement managers and IT system managers in Thai manufacturing, and explains the design procedures for autonomously executing RFQ generation, supplier selection, quote comparison, and PO issuance. The ultimate goal is a state where "humans only need to handle exception approvals," achieving both shorter procurement lead times and reduced buyer workload.

A B2B procurement agent is not simply an evolution of "RPA + chatbot." It autonomously calls upon multiple tools (ERP, supplier APIs, email clients) and completes the entire process—from quote acquisition → comparison → approval request → PO issuance—in a goal-oriented manner. This section organizes the differences from traditional procurement operations and the specific requirements unique to Thai manufacturing.

Traditional procurement operations follow a workflow-based model. Buyers manually cycle through a fixed sequence: create an RFQ → request quotes from three suppliers → build a comparison table in Excel → obtain manager approval → issue a PO in the ERP. RPA automation was limited to tasks like "transcribing data into Excel," while judgment-intensive tasks—such as individually tailoring RFQ language for each supplier or evaluating alternative parts during a stockout—remained with human staff.

AI agents operate in a goal-oriented manner. Given a goal such as "2,000 units of part number X-201, delivery within 4 weeks, budget within 500,000 THB," the agent selects the top three candidate suppliers from historical transaction data, generates email messages tailored to each supplier's language and business practices, parses the responses, and produces a comparison table. It is possible to design the system so that only exceptions—budget overruns, delivery non-compliance, or new suppliers—are escalated to a human.

Procurement automation in Thai manufacturing has three requirements not found at Japanese headquarters.

1. Multi-currency support: Parts from China (CNY), raw materials from Australia (AUD), local suppliers (THB), and specialty parts sourced through headquarters (JPY) all coexist. A mechanism to retrieve exchange rates and normalize values into a comparable unit is essential.
2. Multi-language supplier support: Emails in Thai, English, Chinese, and Japanese are intermixed. The system must generate RFQs in each supplier's preferred language and convert replies into structured data.
3. Automated AEO and customs compliance checks: Under Thailand's Authorized Economic Operator program, the HS code, country of origin, and tariff classification of imported parts must be recorded at the time of purchase. A mechanism to automatically verify that these fields are complete before a PO is issued must be built in.

With the advancement of the EEC (Eastern Economic Corridor), Thai manufacturers are under pressure to simultaneously shorten procurement lead times and manage multi-currency complexity. At the same time, hiring experienced buyers is increasingly difficult, forcing companies to manage with existing staff. Automation through AI agents is positioned as a practical solution to bridge this supply-demand gap.

In Thai manufacturing, component procurement lead times determine product shipment lead times. Japanese-affiliated automotive parts manufacturers and electronics manufacturers must complete the process from RFQ submission to suppliers through to confirmed purchase orders within a matter of days in order to maintain just-in-time production.

In manual procurement, a realistic upper limit for the number of RFQs a single buyer can handle concurrently is around 20. When urgent orders and complex parts overlap, this becomes a bottleneck and the risk of production line stoppages increases. By implementing an agent-based approach, routine RFQs can be completed without buyer intervention, allowing buyers to focus on higher-value activities such as negotiation and new sourcing.

Procurement sources in Thai manufacturing are geographically dispersed: electronic component suppliers in Shenzhen, China; resin manufacturers in Malaysia; specialty parts sourced through the Japanese parent company; and general-purpose materials from local Thai suppliers. Each involves different currencies, languages, and business practices.

In manual procurement, this means performing foreign exchange conversions each time quotes are compared, managing separate email templates for each supplier, and standardizing delivery time expressions (e.g., "Within 4 weeks," "30 business days," "4週間以内"). An agent can retrieve the day's exchange rates via a currency API, normalize quoted prices to a base currency (THB or USD), standardize lead times to calendar days, and generate a comparison table automatically. The ability to mechanically ensure consistency in comparison conditions—something that inevitably varies with manual work—is a key value of the agent-based approach.

When implementing a procurement agent, do not start with the agent implementation itself. The integration design with core systems and the preparation of the supplier master data will determine the success or failure of the entire project. This section outlines the prerequisite preparation items.

A procurement agent does not operate in isolation. It must integrate bidirectionally with existing ERP systems (SAP, Oracle, Microsoft Dynamics, local ERPs) and procurement management systems (Coupa, Ariba, or in-house developed systems).

The minimum required integrations can be classified into three categories.

If the ERP's API infrastructure is insufficient, consider a design that routes through a read-only replica or an intermediate database. Having the agent directly call the ERP's write API makes it difficult to roll back in the event of an erroneous order. It is safer to divide PO issuance into three stages—draft creation → human final approval → ERP write—and restrict write permissions to only that last step.

The quality of an agent's decisions is directly dependent on the quality of its input data. Prepare the following before implementation.

• Supplier master: Transaction history, areas of expertise, supported currencies and languages, lead time track record, quality scores
• Parts catalog: Part numbers, alternative parts, HS codes, country of origin, last purchase price, recommended suppliers
• Historical transaction data: PO history from the past 2–3 years. Price negotiation history is particularly important.

Running an agent without this data in place leads to failures such as selecting previously unused new suppliers or being unable to suggest alternative parts. Data preparation is best undertaken as a joint project between the procurement department and the information systems department, and should be started prior to agent implementation.

This section explains the concrete implementation steps in three stages. The reference implementation starts with structuring procurement requests, moves on to designing a supplier selection agent, and finally automates quote comparison and PO issuance. At each step, we will clearly define "how much to delegate to the agent and where human involvement begins."

When purchase requests (PRs) arrive as unstructured data—such as "free-form text in Excel" or "bullet points in an email body"—an agent cannot process them. The first step is to normalize PRs into a structured schema.

The minimum required fields are as follows:

Unstructured PRs are structured using an LLM. Mixed-language text in Thai, English, and Japanese is passed to the LLM and parsed against the schema above. When parsing fails—due to missing required fields or ambiguous numeric values—the case is escalated to a human, and once a response is received, the result is reflected back into the schema.

Upon receiving a structured procurement request, an agent is designed to select candidate suppliers. The selection logic is determined by a combination of past transaction history, part catalog recommendations, and constraint conditions.

Tools the agent can call:
  - search_suppliers(item_code, quantity, currency, delivery_date) → candidate list
  - get_supplier_history(supplier_id, item_code) → past transaction records
  - get_supplier_capacity(supplier_id, delivery_date) → delivery date suitability
  - calculate_score(supplier_id) → overall score

The agent receives a goal (e.g., "select the top 3 suppliers that meet budget and delivery requirements") and calls the above tools in the necessary order to return a candidate list. The prompt includes procurement policies such as "do not include suppliers with quality issues in the past two years" and "include at least one supplier from a different region to avoid single-supplier dependency."

The agent is prohibited from autonomously adding new suppliers. New additions must go through an approval flow managed by the procurement department head; the agent's role is limited to proposing candidates only.

Quote requests are sent to the selected candidate suppliers, responses are collected, and a comparison table is generated. Finally, a PO is issued.

The HITL criteria for "order decision" should be explicitly documented. For example, a threshold such as "automatic approval for orders under 1,000,000 THB from existing top-3 suppliers; human approval required otherwise" should be used in practice. Leaving the criteria vague causes the agent to stall on edge cases, preventing any reduction in operational burden.

After going live in production, two failure patterns tend to occur frequently: inadequate HITL design and insufficient audit logging. Both are difficult to detect during the PoC phase and tend to surface as problems only after operations begin.

The two common failure modes in HITL design are polar opposites: "requiring human approval for every single item, rendering automation pointless" and "over-automating to the point where erroneous orders go undetected."

The design principle is to branch based on a combination of amount, supplier track record, and exception flags. The following threshold configuration, for example, is realistic:

• Under 500,000 baht + existing supplier + within budget → automatic approval
• 500,000–2,000,000 baht → section manager approval (Slack notification + approval by button click)
• 2,000,000 baht or more, or new supplier, or over budget → department manager approval
• Special expedited approval path for emergencies (risk of manufacturing line stoppage) → separate route

Escalation notifications should be designed to fit the approver's work rhythm. Since managers in manufacturing tend to have many meetings and are prone to delayed email responses, adding a mechanism that automatically forwards unapproved items to the next approver after a set period of time (e.g., 6 hours)—on top of notifications via Slack, LINE, and Microsoft Teams—helps stabilize lead times.

Under Thailand's Authorized Economic Operator (AEO) program, companies are required to retain import-related transaction records for a specified period and present them upon customs inspection. When AEO-certified companies (or companies seeking certification) introduce a procurement agent, the following logs must be stored in a structured format:

In addition, handling supplier contact information and transaction history falls under Thailand's PDPA (Personal Data Protection Act). Data minimization (not passing unnecessary personal information to the agent) and automatic deletion after the retention period should be built into the design.

The ROI of a procurement agent is underestimated when measured solely by "cost reduction." Measuring across the following three axes is more realistic:

In the early stages of implementation, reduction in buyer man-hours is the most visible metric. After six months to a year, the effects of "opportunity loss mitigation" (shorter lead times for emergency responses, reduced stockout risk) become apparent. "Reduction in governance man-hours" is the last effect to emerge and is best measured in alignment with audit cycles.

Consolidating KPIs into units that senior management can use in business reporting (annual cost savings, average procurement lead time, etc.) makes it easier to justify additional investment.

A B2B procurement agent is not "fully automated magic"—it is a mechanism that allows humans to focus on handling exceptions. For Thai manufacturers to adopt this mechanism, the ERP integration design, supplier master data preparation, explicit definition of HITL thresholds, and audit log design for AEO/PDPA compliance must all be finalized before implementing the agent.

As a first step, it is realistic to focus on a single procurement category (e.g., general consumables or a specific parts family), and run a 3–6 month proof of concept (PoC) to measure "buyer man-hours," "lead time," and "exception rate." Once the PoC shows improvement in these metrics, expanding to other categories is the approach that allows benefits to accumulate while keeping operational risk in check.

Procurement automation is not a one-off IT investment—it is an initiative that entails redesigning procurement strategy. Proceeding with the involvement of not only the IT department, but also the procurement department and senior management, is a prerequisite for success.