Agentic AI Conversational Ordering PoC

Overview

Agentic AI Conversational Ordering PoC is an ordering prototype built by OneTeam in under 48 hours at Agentic AI Build Week 2026. A customer can describe an order in natural language; the agent searches menu data, updates a cart, validates promotions, and completes a simulated ordering flow without forcing the customer to leave the conversation.

OneTeam won Top 1 in the “Built with AWS” track and reached Top 5 in the F&B track with this agentic ordering solution for KFC Vietnam. The working demo uses Node.js, Express, OpenAI Agents SDK, SQLite, simulated business data, and an in-memory queue. In parallel, the team designed a production-oriented AWS target architecture showing how the prototype could evolve. That AWS architecture is a design target, not infrastructure that was deployed end to end for the demo.

This is a PoC for an F&B use case, not an official KFC Vietnam product or production deployment. At the time of writing, the team has not received formal approval to use the KFC brand in external marketing.

Problem

Conversational commerce loses momentum when customers must leave a messaging thread, open another application, sign in, and rebuild an order. Human chat agents must also interpret informal requests, resolve menu items, handle mid-sentence changes, validate promotions, and re-enter orders into another system.

The prototype explored three questions:

1. Can an agent understand Vietnamese ordering language, including informal names and corrections within the same message?
2. Can it complete a commerce flow without inventing product IDs, prices, or promotions?
3. Can conversation logic remain independent of the messaging channel so new adapters can be added without rewriting the core agent?

Role

My role focused on designing the target AWS architecture for the solution’s production direction. My scope included:

• separating ingestion, agent runtime, memory, tool execution, data, and observability into explicit layers;
• designing an asynchronous webhook path from messaging channels to the agent and workers;
• positioning API Gateway, Lambda, SQS, Bedrock AgentCore, DynamoDB, OpenSearch, S3, and security and observability services;
• documenting the boundary between the local PoC and the cloud architecture that still requires implementation, testing, and validation.

Application implementation was a team effort. This case study does not attribute the entire codebase or every implementation decision to my individual role.

Solution

Implemented demo flow

The PoC exposes an Express backend that receives requests from Postman or a Zalo webhook. Each message is passed to an agent that chooses which tools to invoke and constructs its final response only from tool results.

Six business tools are implemented:

• search_menu: searches a local menu snapshot;
• get_cart: reads cart state and backend-calculated totals;
• update_cart: adds, edits, or removes items, variants, notes, and addresses;
• check_loyalty: looks up a simulated loyalty account;
• apply_voucher: validates and applies a simulated voucher;
• create_order: creates a simulated order with duplicate-order protection for the same cart.

The staff dashboard displays carts, new orders, agent activity, and conversations. It also supports human handoff: a staff member can take control of a Zalo session, send a message, and hand control back to the bot.

Data and integration scope

• The menu is a snapshot collected from public information, stored in kfc_menu.json, and imported into SQLite. It is not a live KFC Menu API.
• Voucher, loyalty, cart, and order-management behavior is simulated by the team.
• The PoC is not connected to KFC Vietnam’s production Menu, Voucher, Loyalty, or OMS APIs.
• A Zalo Bot adapter is implemented in the repository. WhatsApp remains an architecture/future extension and is not present in the current source code.

Target AWS architecture

The production design proposes API Gateway and WAF for ingestion, Lambda for webhook handling and orchestration, SQS for durable processing, Bedrock AgentCore for runtime, memory, and gateway capabilities, DynamoDB and OpenSearch for state and search, plus S3, ElastiCache, KMS, IAM, Secrets Manager, and observability services.

These components describe a path from the PoC to a scalable and operable cloud system. They were not deployed end to end during the Hackathon and are therefore not presented as completed implementation results.

Technical decisions

Grounding instead of model-generated business facts

The agent cannot decide product IDs, prices, points, discounts, or order totals on its own. Business-critical facts must come through tools, and backend calculations remain the source of truth. This turns hallucination risk into an enforceable software boundary rather than relying only on prompt quality.

A modular monolith for a 48-hour constraint

The team selected one Node.js process, SQLite, and an in-memory queue to reduce integration time and keep the demo reproducible. The trade-off intentionally favored delivery speed over horizontal scaling and restart resilience.

The current implementation is therefore suitable for local, single-process execution. Queued work can be lost on restart, and in-memory session locking cannot coordinate multiple instances. A cloud rebuild must replace these pieces with durable messaging and appropriate distributed state or locking.

Data-layer idempotency

Zalo webhook events are claimed by external message ID to avoid repeated processing. Order creation uses a unique constraint on the source cart so repeated tool calls cannot create multiple orders for one cart. These mechanisms are implemented. SQS FIFO, a Step Functions Order Saga, and PENDING_OMS remain production architecture proposals.

Separating channel adapters from the agent

The Zalo webhook is normalized into a session ID, user ID, chat ID, and message text before entering ChatService. This keeps agent logic independent of Zalo’s payload and reply formats and provides a foundation for future channel adapters.

Demo-level observability

Tools emit start, completion, and state-update events, while the dashboard displays activity through polling. This is application-level visibility for the demo; it is not equivalent to CloudWatch, X-Ray, CloudTrail, or GuardDuty from the AWS target design.

Results

• Delivered a working end-to-end conversational PoC in under 48 hours.
• Won Top 1 in the “Built with AWS” track at Agentic AI Build Week 2026.
• Demonstrated menu search, complex cart corrections, vouchers, loyalty, simulated order creation, and a staff dashboard.
• Used a local dataset of 94 menu items, making the demo reproducible without a live Menu API.
• At the time of review, the test suite passes 57 of 60 tests; three cart-anomaly tests still fail because quantity limits are inconsistent between the tests, tool schema, and database constraint.

The 3–5 second latency is an architectural target, not a formal benchmark. Approximately USD 0.006 per order and USD 88 per month are AWS Pricing Calculator estimates assuming roughly 500 orders per day, not measured production costs. The claimed 60% reduction in infrastructure code is also a design expectation rather than a measured outcome. None of these figures is presented as a validated result.

Lessons learned

1. Grounding is a system property, not only a prompt technique. Business-critical data should be forced through tools and deterministic backend logic.
2. Demo implementation and target architecture must be described separately. A production design does not prove that every service in the diagram has been deployed or benchmarked.
3. Infrastructure choices directly shape the customer experience. Queues, idempotency, state, and failure recovery determine whether an order is duplicated or lost; they are not merely backend details.