Forem: gins p cyriac

Smart Customer Support - A Multi Agent Ticketing System Using OpenAI Agents SDK

gins p cyriac — Sun, 01 Feb 2026 23:31:00 +0000

Introduction

In this project, I built an intelligent car customer support system using AI agents which converts customer support emails into structured support tickets with AI generated draft response based on internal document references which are then reviewed by human agents.

Handling hundreds of customer support emails at scale is difficult, especially when many request are repetitive. Currently, the support teams often read through hundreds of emails everyday, analyze each request and send meaningful response to each customer. This is a tedious and time consuming process, especially if the customer service agent has to search through various internal documents before responding to each customer.

My goal with this project is to automate this repetitive parts of the support workflow while still giving the humans the final say. This project is a collaboration between AI and human agents. Full code for this project can be found on Link

Project Features

📩 Email ingestion (Gmail)
🤖 AI agent analyze support emails and generates
- Priority
- Summary
- Draft response
🧑‍💼 Human-in-the-loop approval before sending response to users
- ✏️ Editable draft responses
- ✅ Approve / ❌ Reject tickets
📊 Analytics dashboard
- Tickets per day
- Tickets by priority
- Tickets by status
- Total tickets & pending review

🚀 Technologies

PostgreSQL – Data storage
FastAPI – Backend API implementation
LLM (GPT-5 Nano) – Language model powering the AI agent
Next.js – Frontend web application
Docker Compose – Service orchestration

Architecture Overview

AI Agent Orchestration Design

Instead of using a single agent with a large prompt, in this project I have used separate specialized agents with a clear defined role and strict boundaries.

1. Email Analyzer Agent

The Email Analyzer Agent is responsible for processing incoming emails.

Its job is to:

Inspect the email body
Detect whether it contains a valid customer complaint or request
Assign a priority level (LOW, MEDIUM, HIGH, CRITICAL)
Generate a one sentence summary

If the email does not contain a valid request, the agent explicitly marks priority as INVALID.

2. Car Expert Agent (RAG based Domain Expert)

The Car Expert Agent acts as a car specific knowledge agent. It does not rely on general LLM knowledge. The agent provide response by strictly referencing car documentation using a Retrieval-Augmented Generation (RAG) approach. If the requested information is not found, then the agent provide the response accordingly.

3. Orchestrator Agent (Coordinator & Decision Maker)

The Orchestrator Agent is the brain of the system. It coordinates the entire workflow by invoking other agents as tools and enforcing business rules.

Its responsibilities include:

Calling the Email Analyzer Agent
Deciding whether a ticket should be created
Generating a human-readable ticket number
Detecting whether the request is car-related
Conditionally invoking the Car Expert Agent
Producing a draft email response for human review

class OrchestratorAgentOutput(BaseModel):
    priority:str
    summary:str
    draft_response: str
    subject: str
    ticket_number: str

orchestrator_agent = Agent(name="orchestrator agent",
                           instructions=""" 
                            You are a customer care car support orchestrator.
                            Process:
                            1. Use email_analyzer to classify priority and summarize.
                            2. If priority == INVALID:
                            - Create a polite rejection response
                            3. If priority != INVALID:
                            - Determine if the request is about car operation, maintenance, or faults
                            - ONLY IF it is car-related, call car_expert
                            4. Use car_expert output strictly; do not add assumptions
                            5. Produce a draft email response and subject

                            Output MUST match OrchestratorAgentOutput. 
                           """, 
                           model="gpt-5-nano",
                           tools=[    
                            create_ticket_number,     
                            email_analyzer_agent.as_tool(
                                tool_name="email_analyzer",
                                tool_description="Perform analysis of the email and provide a brief summary and priority of the email",
                            ),         
                            car_expert_agent.as_tool(
                                tool_name="car_expert",
                                tool_description="Provides correct answers regarding the car by referring the car documentation",
                            ),
                           ],
                           output_type=OrchestratorAgentOutput
                           )

Here, the orchestrator agent use the email_analyzer_agent and car_expert_agent as tools. This approach keeps the prompts small and focused, it prevents role overlap while also allowing easy tool extension.

Human-in-the-Loop By Design

The orchestrator agent produces a draft response, not a final answer.

Every generated response is:

Stored as a draft.
Reviewed by a human agent.
Edited or Approved / Rejected by a human agent.

This ensures trust in AI-assisted workflows and also keeping the accountability.

🖼 Screenshots

Below are a few screenshots highlighting key parts of the system

Dashboard

Ticket Lists

Edit Response

🚀 Next Steps

Pluggable LLM Provider Support.
Enhanced RAG Pipeline.
Mentioning source in AI Responses.
Add support for more agents (e.g., billing, warranty, returns)
UI Improvements

Connecting AI Agents to Factory Data with MCP, Node.js & TypeScript

gins p cyriac — Mon, 22 Sep 2025 18:56:19 +0000

Introduction

AI is rapidly evolving and disrupting many industries. Initially, LLM agents were only able to provide us insights based on their training data, which was very limited and this prevented us from using AI agent from obtaining real-time insights and using it efficiently in an enterprise context.

The introduction of MCP (Model Context Protocol) became a game changer in this field and it enabled the AI agents to get the real-time information and also to access enterprise data, which unlocked a whole new scope for using AI agents and implementing powerful new use-cases.

In this post, I would like to share my learning about MCP Server and also a walk through a sample project where I am getting the factory machine data stored in a PostgreSQL database using MCP Server and the AI agent invokes the tools exposed by the MCP server for obtaining the machine data based on the user input and provide user with a structured response.

Full code for this project can be found on Link

Before we get into the details of the project implementation, Let us first understand what is MCP, what is the benefit of using it and how the it unlocks new abilities for the AI agents.

MCP Server

MCP (Model Context Protocol) was introduced by Anthropic in November 2024, it provides a standardized way for AI applications to connect with external systems and data. With MCP, LLMs are no longer limited to static training data, now they can access real-time information and enterprise systems securely.

MCP Server exposes 3 Primitives

Tools: Executable functions that AI applications can invoke (e.g., API calls, database queries)
Resources: Data sources that provide context (e.g., file contents, database records, API responses)
Prompts: Structured templates that help guide LLMs (e.g., system prompts, few-shot examples)

Benefits of using MCP Server in Enterprise context

Secure Access: Secure data access only to authorized programs.
Restricted Access: Fine grained control over data used by AI agents.
Standard Integration: Instead of building custom connectors for every AI agent, MCP provides a common protocol for connecting to databases, APIs, and internal tools.
Auditability & Compliance: Every tool call and database request by the AI agent can be logged, which helps to meet the compliance requirement and track AI behavior.

Project Architecture

In this project, I have setup a MCP Server that exposes factory data stored in a PostgreSQL as tool. The chat-client application communicates with MCP Server using Streamable HTTP calls. In this implementation, I have seeded the PostgreSQL database using a sample Industrial Energy Forecast Dataset obtained from Kaggle. The dataset can be downloaded from Link

MCP Server: Provides tools which AI agent calls to get the machine data stored in database.
PostgreSQL: Stores the seeded dataset from Kaggle.
Ollama: Local LLM (llama3.1)
Chat Client: An express application which interacts with MCP server and LLM to get response for the user request.

Setup

Start services

   docker compose up -d

Pull llm model for llama

   docker exec -it ollama ollama pull llama3.1

Core Application logic

MCP Server

In this project, MCP Server as an express application that exposes tools the AI agents can use to fetch the requested data on demand.

I have created a function registerTools which registers all the available tools provided by the MCP server in tools.ts (mcp-server/src/modules/tools.ts). Currently, I have only one tool get-machine-record which gets the latest record of a given machineId from the postgres database.

Each tool is defined with following components:

Name: identifier for the tool (e.g., "get-machine-record")
Input Schema: JSON schema describing required arguments (e.g., { "device": "string" })
Callback: the function that contains the logic (e.g., SQL query).

Example:

  server.tool(
    "get-machine-record",
    "Gets latest record for a machine",
    {
      machineId: z.string(),
    },
    async ({ machineId }) => {
      // Fetch data from PostgreSQL
      console.log(`Fetching record for machine ${machineId}`);
      const machineRecord = await getLatestMachineRecord(machineId);
      if (machineRecord) {
        return {
          content: [{ type: "text", text: JSON.stringify(machineRecord) }],
        };
      } else {
        return {
          content: [{ type: "text", text: "[]" }],
        };
      }
    }
  );

Chat Client

Chat client is also an express application which exposes 2 APIs.

1. Direct MCP query

http://localhost:4001/machines/${machineID} → Fetch raw machine data of the mentioned machineID from the MCP server by directly calling the get-machine-record tool.

2. AI-assisted query

http://localhost:4001/chat → This API provides AI generated response for the requested details of a machine. The core logic is implemented in chat.service.ts (chat-client/src/services/chat.services.ts).

Workflow:

The user message is converted into a prompt and sent to Ollama (local LLM).
If the LLM decides it needs external data, it calls the tool provided by the MCP server.
The tool fetches the machine data from PostgreSQL and provides back to the chat client.
The result is then fed back into the LLM.
The LLM generates a refined, human-readable answer for the user.

Next Steps 🚀

For the next iteration of this project, I am planning to implement below features:
1. Integrate live data feeds: Ingest real-time factory telemetry into PostgreSQL, so the AI agent works with fresh data.
2. Add authentication to the MCP Server: Restrict access to only authorized applications and users.
3. Expand toolset: Create more tools
4. Support multiple MCP Servers: Allow the client to connect to and aggregate responses from different MCP servers

AWS CDK + Localstack (API Gateway, Lambda, SQS, DynamoDB,TypeScript)

gins p cyriac — Sun, 03 Nov 2024 18:05:49 +0000

Introduction

This project is a Fleet Emission Data Management System designed to track and manage emissions data for various vehicles within a fleet. Built using AWS infrastructure, the project leverages AWS Lambda for serverless compute, DynamoDB for highly scalable storage, and Amazon SQS for asynchronous message queuing. The application is developed with modular code and follows a well-defined structure to enhance reusability, maintainability, and scalability. By using TypeScript, we ensure strong type-checking, which helps maintain code quality and minimize runtime errors.

Full code for this project can be found on [https://github.com/Gins47/fleet-emission-calculator]

For local AWS development and testing we will be making use of LocalStack.

Prerequisites

Make sure that you have the following installed in you local development setup.

NodeJS
Docker
AWS CLI
Localstack

For this project we will be using AWS CDK for the infrastructure setup and deployment.

Install AWS CDK

npm install -g aws-cdk

Architecture Diagram

DynamoDB Table Design

The DynamoDB table uses a standardized approach to defining the partition key (pk) and sort key (sk) to make it adaptable for multiple data entities. This structure allows us to store and retrieve different types of data (e.g., vehicle data, company data) while keeping the data organized and easily queryable.

Partition Key (pk): Uniquely identifies each entity type in the table.
Sort Key (sk): Provides the secondary key to allow range queries and ordering within each partition.

Primary Key Format:

Partition Key (pk): Composed of the entity type and unique identifier, following the format entityType#identifier.
Example: For a vehicle emission entry, the pk could be vehicle#M-MJ-456.

Sort Key (sk): Used for time-series data or sub-entities within the same partition, following the format attribute#value.
Example: For vehicle data, the sk could be creationTime#1730641488.

This structure allows the table to support multiple entities (such as vehicles and companies) by defining each type with a specific prefix, while also allowing range queries on creationTime.

Project Setup

Project Structure

I followed clean architecture principles, with separate folders for handlers, controllers, models, repositories, services, and error handling. Below is a breakdown of each main folder and its purpose:

lib/resources/lambdas/src: This is the main source folder for the Lambda functions and supporting files. It includes subdirectories for controllers, handlers, models, repositories, services, and error handling.

Folders

controllers: Contains controllers responsible for handling incoming requests and directing them to the appropriate services.
services: Includes general application services that provide reusable business logic across various controllers and handlers.
repository: This folder contains classes and methods for interacting with DynamoDB.
models: Defines TypeScript models or interfaces used throughout the application.
errors: This folder manages custom error classes for the application.
handlers: Contains the AWS Lambda handler functions, which serve as entry points for each Lambda function.
- consumeEmissionData.ts: Consumes emission data from an SQS queue.
- createVehicleLambda.ts: Handles vehicle data creation.
- getVehicleDataLambda.ts: Retrieves vehicle data by vehicleNumber and CreationTime.
- publishEmissionData.ts: Publishes emission data to an SQS queue.

AWS CDK Stack

By using AWS CDK we can create the required resources very easily. Below, you can find the way to create various AWS resources using AWS CDK.

API Gateway

 const api = new RestApi(this, "ApiGateway", {
      restApiName: "Fleet Emission API",
      deployOptions: {
        stageName: "dev",
      },
    });

   const queue = new sqs.Queue(this, "FleetEmissionQueue", {
      visibilityTimeout: cdk.Duration.seconds(300),
    });

DynamoDB

 const table = new dynamodb.Table(this, "FleetEmissionDataTable", {
      partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
      sortKey: { name: "sk", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      tableName: "FleetEmissionData",
    });

In this set up, I am adding a Global Secondary Index (GSI) called VehicleCompanyTypeIndex with the following structure:

Partition Key: vehicleCompany (string) - Enables queries to be grouped by the company.
Sort Key: vehicleType (string) - Allows sorting and filtering by vehicle type within each company.
Projection Type: ALL - Includes all attributes from the original table in the index, making it possible to access the entire item data without referring back to the main table.

 table.addGlobalSecondaryIndex({
      indexName: "VehicleCompanyTypeIndex",
      partitionKey: {
        name: "vehicleCompany",
        type: dynamodb.AttributeType.STRING,
      },
      sortKey: { name: "vehicleType", type: dynamodb.AttributeType.STRING },
      projectionType: dynamodb.ProjectionType.ALL,
    });

Create Vehicle Data Lambda function

    const createVehicleDataFunction = new lambda.Function(
      this,
      `createVehicleDataFunction`,
      {
        runtime: lambda.Runtime.NODEJS_20_X,
        memorySize: 128,
        timeout: cdk.Duration.seconds(100),
        architecture: lambda.Architecture.X86_64,
        handler: "createVehicleLambda.handler",
        code: lambda.Code.fromAsset("dist/handlers"),
        environment: {
          DYNAMODB_TABLE: table.tableName,
        },
      }
    );

We need to give access permission to the lambda function to write data to DynamoDB. This can be achieved using below command.

    table.grantReadWriteData(createVehicleDataFunction);

In order to integrate the API Gateway with our Lambda function, we can create a new route in the API Gateway and trigger the Lambda function using below command.

    const vehicle = api.root.addResource("vehicle");
    vehicle.addMethod("POST", new LambdaIntegration(createVehicleDataFunction));

Publish data to SQS

In order to publish data to SQS, I used a lambda function.

   const publishVehicleDataFunction = new lambda.Function(
      this,
      `publishVehicleDataFunction`,
      {
        runtime: lambda.Runtime.NODEJS_20_X,
        memorySize: 128,
        timeout: cdk.Duration.seconds(100),
        architecture: lambda.Architecture.X86_64,
        handler: "publishEmissionData.handler",
        code: lambda.Code.fromAsset("dist/handlers"),
        environment: {
          QUEUE_URL: queue.queueUrl,
        },
      }
    );

We also need to give permission for this lambda function to send message to SQS queue.

 queue.grantSendMessages(publishVehicleDataFunction);

Now lets link this lambda function to API Gateway.

    const publishResource = vehicle.addResource("publish");
    publishResource.addMethod(
      "POST",
      new LambdaIntegration(publishVehicleDataFunction)
    );

Deployment to LocalStack

Lets start the localstack using the command below

localstack start

After LocalStack is ready, lets bootstrap the cdk using below command.

npm run cdk:local bootstrap

After successfully bootstapping lets build project for deployment.

npm run build

Now, Lets deploy the project to localstack using the command below.

npm run cdk:local deploy

API Endpoints

Method	Endpoint	Description
GET	`/vehicle/{VehicleNumber}/time/{creationTime}`	Retrieve vehicle data by creationTime
POST	`/vehicle`	Create new vehicle Emission Data
POST	`/vehicle/sqs`	Publish emission data to SQS

API Test

Create vehicle data

curl --location '{API Gateway Endpoint}/dev/vehicle' \
--header 'Content-Type: application/json' \
--data '{
    "creationTime": 1730641478,
    "creationTimeISO": "2024-11-03T13:44:38+00:00",
    "userId": "user12",
    "vehicleNumber": "M-GC-123",
    "vehicleType": "CAR",
    "vehicleCompany": "BMW",
    "fuelType": "Petrol",
    "liters": 5.7,
    "cost": 324,
    "co2EmissionFactor": 34
}'

Get vehicle data by vehicle number and creation timestamp

curl --location '{API Gateway Endpoint}/dev/vehicle/M-GC-123/time/1730641478'

Publish vehicle data to SQS queue

curl --location '{API Gateway Endpoint}/dev/vehicle/publish' \
--header 'Content-Type: application/json' \
--data '{
    "creationTime": 1730641488,
    "creationTimeISO": "2024-11-03T14:44:38+00:00",
    "userId": "user12",
    "vehicleNumber": "M-MJ-456",
    "vehicleType": "CAR",
    "vehicleCompany": "Benz",
    "fuelType": "Petrol",
    "liters": 9.7,
    "cost": 1234,
    "co2EmissionFactor": 50
}'

AWS CLI Commands

Below are some of the useful AWS CLI commands.

# CloudFormation

aws cloudformation list-stacks --endpoint-url=http://localhost:4566  --region us-east-1 

aws cloudformation delete-stack --stack-name FleetEmissionStack --region us-east-1 --endpoint-url=http://localhost:4566

aws cloudformation list-stacks --stack-status-filter DELETE_COMPLETE --region us-east-1 --endpoint-url=http://localhost:4566

aws cloudformation describe-stacks --stack-name FleetEmissionStack --endpoint-url=http://localhost:4566  --region us-east-1

aws cloudformation describe-stack-resources --stack-name FleetEmissionStack --endpoint-url=http://localhost:4566 --region us-east-1


# API Gateway

aws apigateway get-rest-apis --endpoint-url=http://localhost:4566 --region us-east-1

aws apigateway delete-stage --rest-api-id szt80q7wda --stage-name DevStage --endpoint-url=http://localhost:4566 --region us-east-1

aws apigateway delete-rest-api  --rest-api-id szt80q7wda  --endpoint-url=http://localhost:4566 --region us-east-1

aws apigateway get-api-keys --include-values --region us-east-1 --endpoint-url=http://localhost:4566

aws apigateway get-resources --rest-api-id egpnkrrsgi --region us-east-1 --endpoint-url=http://localhost:4566

# Lambda

aws lambda list-functions --endpoint-url=http://localhost:4566 --region us-east-1

aws lambda list-event-source-mappings --endpoint-url=http://localhost:4566 --region us-east-1

# dynamodb

aws dynamodb list-tables --endpoint-url=http://localhost:4566 --region us-east-1

aws dynamodb scan --table-name FleetEmissionData --endpoint-url=http://localhost:4566 --region us-east-1

aws dynamodb describe-table --table-name FleetEmissionData --endpoint-url=http://localhost:4566 --region us-east-1


# SQS

aws sqs list-queues --endpoint-url=http://localhost:4566 --region eu-central-1

aws sqs receive-message --queue-url=http://sqs.eu-central-1.localhost.localstack.cloud:4566/000000000000/FleetEmissionStack-FleetEmissionQueue2C4D14-9b6bdecd --endpoint-url=http://localhost:4566  --region us-east-1

Conclusion

This project showcases a highly scalable and maintainable serverless architecture for managing vehicle emissions data. By using AWS services like Lambda, DynamoDB, and SQS, the system can handle high volumes of data with low operational overhead. The modular design and organized project structure facilitate easy integration of new features and enhancements. With a reliable and efficient mechanism for capturing, storing, and retrieving data, this project sets a strong foundation for building a comprehensive fleet management solution.

The implementation of Global Secondary Indexes (GSIs) on key fields like vehicleCompany and vehicleType has also enhanced the system’s querying capability, enabling more efficient data retrieval and expanding the types of insights that can be derived from the data. This architecture can seamlessly accommodate future enhancements as the data volume and complexity grow.

Next Steps

Adding validation for APIs
Authentication and Authorization
Automated Testing
Analytics
Web UI