Booster Analytics

As part of a long-term applied AI initiative, I asked my students one question:

“If you had to build a data-driven agentic AI business from scratch, what industry would you choose?”

Their answer?

Suki restaurants. Fiercely competitive. Fast-moving. Full of operational complexity. And in Thailand, the suki space is a warzone of pricing, quality, and customer expectations – perfect for testing the limits of AI.

So we launched a 7-month project. The goal:

Build a full-stack, company-wide Agentic AI system from scratch for a fictional (but realistically modeled) suki restaurant chain using synthetic data, simulated branches, and entirely student-led teams.

I’m acting as the technical advisor, guiding strategy, architecture, and system integrity – but they own the build. This project is what we’re doing, and why it’s worth watching.

The Project Brief: Build Smart from Day One

We’re treating this as a greenfield deployment:

• No existing systems
• No pre-integrated data
• Everything – data, agents, APIs, workflows – must be designed and deployed by the students

To simulate reality, students are creating synthetic datasets:

• Point-of-sale (POS) logs
• Vendor and supply chain records
• ESG tracking
• HR schedules
• Campaign histories
• Financials

These datasets will fuel a Federated Agentic AI system, where each department is represented by a dedicated AI agent. Each agent has a clear mission, a scoped domain, and autonomous planning logic using Modular Cooperative Planning (MCP).

Why Suki Restaurants?

Because it’s brutal.

Margins are tight. Competition is fierce. Customer expectations are high. In this environment, AI isn’t a buzzword – it’s survival, and we liked that.

Students chose this business because it forces them to think like real operators:

– How do you forecast shrimp availability with uncertain vendors?

– How do you balance cost, margin, and promo timing?

– How do you avoid overstaffing while maintaining service quality at peak hours?

These are not academic questions – they’re daily dilemmas for restaurant chains.

How the Project Is Structured

Each student (or student team) chose a business unit domain. Their responsibility is to build a domain-specific RAG agent that can act, respond, and collaborate with other agents.

Roles include:

1. Customer & Marketing Agent – loyalty analysis, campaign testing, trend extraction

2. Branch Operations Agent – labor planning, local adaptation, efficiency tuning

3. Supply Chain Agent – ingredient availability, delivery optimization

4. Finance Agent – margin modeling, pricing simulation

5. ESG Agent – carbon footprint reporting, vendor emissions tracking

6. Risk & Fraud Agent – anomaly detection, behavioral outlier scoring

7. Data Governance Agent – quality enforcement, schema management

Each team is also responsible for:

• Designing a synthetic data schema
• Building a vector database and embedding pipeline
• Developing a FastAPI-based agent service
• Writing the MCP logic for agent negotiation
• Logging decisions, confidence scores, and system feedback

The Architecture: From Query to Cross-Agent Plan

Here’s how the system works:

A user (executive, store manager, planner) submits a complex query:

“Should we launch a squid combo in 15 stores next month – and what price and staffing would make it profitable?”

The Orchestrator Agent decomposes the query into sub-tasks and routes them.

Each RAG Agent:

1. Retrieves its relevant context via semantic search (RAG)

2. Applies local planning logic (MCP)

3. Returns a proposal or warning

4. The orchestrator consolidates input and resolves trade-offs:

• Finance prefers THB 179 for a 22% margin
• Supply Chain prefers squid (stable vendor)
• ESG recommends squid over shrimp (lower emissions)
• Operations requests two extra staff per weekend per store
• Risk Agent flags underperforming locations

The orchestrator returns a full decision brief, with justifications and confidence levels.

The Timeline: 7 Months, End-to-End

We’ve structured the project into phases:

Month

Milestone

1. Domain definition, data schema design, and synthetic data generation

2–3. Agent RAG pipelines and initial API interfaces

4. Orchestrator agent and MCP logic implementation

5. Scenario testing and inter-agent negotiation

6. Feedback loops, memory, and explainability features

7. End-to-end demo, documentation, system review, and retrospective

By Month 7, this mockup will simulate a real-world suki business running on federated AI, from marketing to procurement to ESG.

My Role as Technical Advisor

As an advisor, my job isn’t to code – it’s to push students to think like architects and product owners. I help them:

• Guide mapping from company’s vision to business strategy and then data strategy
• Identify brittle assumptions in agent logic
• Make tradeoffs between precision and speed
• Design fallback logic when agents fail
• Handle unstructured data gracefully
• Think like stakeholders under pressure

I also help enforce systemic discipline:

• Shared schemas
• Common protocols
• Secure access control
• Reusable modules
• Model interpretability

This project isn’t about building “cool tools.” It’s about building accountable, explainable, operational AI.

Why This Matters

Suki may seem simple. But it forces hard, real decisions.

If students can build a lean, intelligent, agentic platform for this business, they can do it anywhere.

And we’re proving that Agentic AI isn’t future-speak.

Students can build it now with the right architecture, the right constraints, and the right guidance.

Next time, w will share our mapping from company’s vision into business strategy and the data strategy.