Capstone Phase 1: Prototyping and Tool Schemas

Deconstructing the Customer Support Agent

To build a production-grade customer support agent, we must transition from generic text-completions to structured, safe database interactions and policy lookups. A Customer Support Agent requires two primary datastores:

1. Transactional Data (API): Structured data containing customer accounts, transaction amounts, and order statuses. In a secure production environment, this database is encapsulated behind a secure REST API data access layer, preventing direct SQL injection risks.
2. Policy Guidelines (RAG): Unstructured text containing rules regarding refund eligibility, restocking fees, and escalation parameters.

In this first phase of the capstone project, we establish the mock relational datastores, implement keyword-based search over policy documents, and define the structured REST-like API tool schemas that expose these functions to the language model.

Datastore and Schema Architecture

The relationship between the agent, the tool-calling interface, and the underlying databases is shown below:

• REST API Tools: Parameterized endpoints (get_customer_details, get_order_details) that safely query the underlying database under the hood, protecting backend schemas.
• Policy Vector Array: Stores policy text blocks.
• Schema Registry: Enforces signatures and maps natural language parameters to tool inputs.

Interactive Playground: Data Prototyping

The multi-turn tool calling sequence and execution flow of the prototyping playground is illustrated below:

The following playground establishes the relational tables in an in-memory database and registers parameterized database API endpoints alongside a keyword-based policy lookup function. The model uses these APIs to retrieve transaction details and determine refund constraints.

In this prototyping phase, the agent successfully executes a multi-step verification process:

1. It queries the get_order_details API to retrieve order 101 details (amount: $150.00, status: 'Delivered').
2. It queries the policy store using the keyword "refund".
3. It reads the policy rules, noting that refunds over $100 require manager approval.
4. It synthesizes this data into a final response.

The next phase covers Orchestration and State Routing, where we structure this execution path into an explicit routing graph.