LLM Agent–Embedded Cruise Procurement Platform

The pain: one procurement journey, disconnected information

The starting point is not simply a difficult PDF. Requirements, product decisions, supplier quotes, logistics and settlement can live across personal experience, Excel, email and LINE. That fragmentation creates repeated entry and information silos, and it prevents the organisation from accumulating reusable operational data. The solution therefore has to evolve the operating model as well as automate document handling.

The coordination problem continues after a request is captured: product matching, supplier quotes, port delivery and reconciliation still need connected records and clear responsibility. Automating one document in isolation would leave the downstream handoffs fragmented.

The solution: shared records, explicit handoffs, controlled automation

To address repeated entry, I connected PDF extraction, classification and order matching to RFQ generation and Excel export. To address information silos, I designed shared records for documents, orders, RFQs and master data rather than separate data flows for each interface. To make handoffs traceable, the operating model names the responsible team, inputs and decisions at each stage.

The LLM agent adds a conversational entry point to these business capabilities; it does not replace the workflow or its controls. Web chat and LINE reuse the same agent, while execution waits for a submitted proposal and user approval. This is the distinction between a standalone chatbot and an agent embedded in a procurement system.

Design the operating model before adding the agent

The platform models eight connected stages: requirement intake, product matching, RFQ and quote collection, quote evaluation, purchase ordering, logistics and customs, onboard delivery, and settlement. Each stage names its responsible team, inputs and decisions. This makes the handoffs visible before the software attempts to automate them.

The architecture: one platform, seven bounded business domains

The FastAPI access layer exposes 18 routes above seven business domains: documents, orders, RFQs, master data, settings, identity and LINE. A shared Supabase PostgreSQL model contains 30 entities, while file storage and external services such as Google Document AI remain behind service boundaries. This structure lets web, messaging and background-task entry points reuse the same business capabilities without collapsing them into one monolith.

The LLM agent is embedded through tools, not direct database access

The agent runtime handles reasoning, planning, context and memory, then calls a controlled toolset. Read tools query information, write tools update through the service layer, and proposal tools require approval. Business actions such as generating an RFQ enter the same approval-and-execution path. The global rule is explicit: the agent never operates the database directly.

Three concrete paths through the same platform

A PDF can move through extraction, classification, order matching and RFQ generation before export to Excel. A chat request can trigger agent reasoning, a tool call and business processing, but execution waits for a submitted proposal and user approval. A LINE message follows the same shared agent after webhook intake and identity resolution, then returns the response through LINE. Swappable LLM services keep the workflow independent of a single model provider.

What the available evidence establishes

The available materials establish the end-to-end operating model, implemented system topology and approval-gated agent design. They do not establish production adoption, measured accuracy improvement, time savings or return on investment, so this case study does not claim those outcomes.

The finished interface: the actual application, not a mockup

The original application screenshots below show the Japanese-language interface as implemented, not a generated mockup. The order repository brings document upload, order search, status filtering and verified records into one workspace, alongside navigation for products, suppliers and other master data. The login screen provides the entry point to the cruise supply-chain management platform. These screenshots establish the actual interface; they do not demonstrate every agent capability described in the architecture.