Inspiration

Most businesses already meet customers online, but many still cannot guide them the way a good service team would. Human support understands context, but it is hard to scale across every channel and every hour. Traditional chatbots can scale, but they often stop at menus, scripted answers, and handoffs.

AI Customer Service Engine was inspired by that gap. The goal is to make online service feel closer to a capable business representative: someone who can understand the customer's need, ask the next useful question, compare real options, apply business policy, and complete a confirmed action.

What It Does

AI Customer Service Engine is a reusable foundation for business-specific AI customer-service agents. Each deployment has its own profile, tone, business data, policy rules, integrations, customer identification needs, and action flow.

The demo covers ten customer-service scenarios, from low-risk public journeys such as retail product guidance and real estate tour scheduling to more sensitive journeys such as prescription refills, insurance claims, and banking disputes.

The assistant is designed to guide the customer, not just answer them. It can compare products, check availability, explain policy, verify the customer when needed, and complete actions only after clear confirmation.

How I Built It

The system uses Google ADK as the agent runtime and Gemini as the reasoning and response layer. The engine exposes a chat API, loads a selected business profile, and gives Gemini access to business tools that retrieve Firestore data, call configured external APIs, enforce policy, and execute confirmed actions.

Firestore stores profile-specific business data such as products, schedules, customer records, documents, policies, claims, transactions, and action records. Cloud Run hosts the engine and web chat services. The web chat is a lightweight Angular interface that talks only to the engine and displays the returned answer.

Arize/Phoenix is used for evaluation and observability. Response guardrails and action results are traced and evaluated. Recent evaluation signals can then be summarized into runtime quality guidance, so the next agent instruction can react to issues such as missing grounding evidence, internal implementation leakage, or action results that require review.

Challenges

One major challenge was keeping the frontend simple while making the engine responsible for the real decisions. The web chat should not know whether a response was blocked, retrieved, verified, or handled by a tool. It should only send a message and display the customer-facing answer.

Another challenge was making the scenarios feel realistic. Customers are often brief, uncertain, and do not know what the system can do. The assistant needed to guide them proactively while still staying inside the business domain and using real configured data.

The most important design challenge was balancing flexibility with control. Gemini can interpret the conversation and decide when a capability is needed, but engine-owned tools still enforce identification, verification, policy, confirmation, and action boundaries.

What I Learned

I learned that an agentic customer-service system needs more than a good model response. It needs business context, reliable retrieval, policy boundaries, action confirmation, observability, and feedback loops.

I also learned that evaluation should not be treated as a dashboard-only feature. When quality signals can influence runtime guidance, the system becomes more practical for production: it can notice recurring issues and adjust how it asks, retrieves, explains, and confirms.

What's Next

The next step is to expand the quality loop with richer Phoenix insights, stronger long-term session handling, more production-grade security controls, and additional business profiles. The direction is a reusable customer-service engine that companies can configure for their own domain without rebuilding the agent logic from scratch.

Built With

Share this project:

Updates