Intellex an Multi Agent based decision system

Intellex is a multi-agent decision system where each agent is defined at runtime by a custom system prompt and a chosen language model. User queries are submitted through a Streamlit interface and forwarded to a FastAPI backend, which passes them to a LangGraph ReAct agent. The agent decides whether to answer from the model's own knowledge or invoke Tavily web search, executes the appropriate tool chain, and returns a grounded response.

The system supports two Groq-hosted LLaMA 3 models (llama3-70b-8192 and llama-3.3-70b-versatile), selectable per session. Web search is opt-in per query — when enabled, the ReAct agent is equipped with a Tavily search tool capped at two results, keeping responses fast and focused. The frontend and backend run as concurrent threads from a single entry point, communicating over a local HTTP interface.

Deployment is handled through a Jenkins CI/CD pipeline running inside a custom Docker image that bundles Jenkins LTS, the Docker daemon, SonarQube Scanner, and the AWS CLI, so the build agent needs no pre-installed tooling on the host. On every push to main, Jenkins clones the repo, runs a SonarQube static analysis pass, builds the application image, tags it, and pushes it to a private AWS ECR repository. A final stage triggers a forced redeployment on the ECS Fargate service, replacing the running task with the new image automatically.

---

Architecture

User (Browser)
    │
    ▼
Streamlit Frontend  (port 8501)
    │   HTTP POST /chat
    ▼
FastAPI Backend     (port 9999)
    │
    ▼
LangGraph ReAct Agent
    ├── ChatGroq (LLaMA 3 via Groq API)
    └── TavilySearchResults (optional, max 2 results)

CI/CD Pipeline (Jenkins → ECR → ECS Fargate)

GitHub push → Jenkins (custom Docker image)
    ├── Stage 1: Clone repo
    ├── Stage 2: SonarQube static analysis
    ├── Stage 3: Docker build → ECR push
    └── Stage 4: ECS Fargate force-redeploy

---

Project Structure

Intellex/
├── app/
│   ├── main.py                  # Entry point — launches backend + frontend as threads
│   ├── backend/
│   │   └── api.py               # FastAPI app — /chat endpoint
│   ├── core/
│   │   └── ai_agent.py          # LangGraph ReAct agent + Groq LLM setup
│   ├── frontend/
│   │   └── ui.py                # Streamlit UI
│   ├── config/
│   │   └── settings.py          # API keys + allowed model names
│   └── common/
│       ├── logger.py            # File-based rotating logger
│       └── custom_exception.py  # Structured exception with file + line context
│
├── custom_jenkins/
│   └── Dockerfile               # Custom Jenkins image (Docker-in-Docker + AWS CLI + Trivy)
│
├── logs/                        # Runtime log files (git-ignored)
├── Dockerfile                   # Application image (python:3.10-slim)
├── Jenkinsfile                  # 4-stage CI/CD pipeline
├── requirements.txt             # Pinned Python dependencies
├── setup.py                     # Package setup (name: Intellex)
├── FULL_DOCUMENTATION.md        # Full deployment walkthrough (WSL → Jenkins → ECS)
└── .gitignore

---

Running Locally

1. Clone the repository

git clone https://github.com/itsabhishekm/Intellex.git
cd Intellex

2. Create and activate a virtual environment

python -m venv venv
venv\Scripts\activate        # Windows
source venv/bin/activate     # macOS / Linux

3. Install dependencies

pip install -e .

4. Set environment variables

Create a .env file in the project root:

GROQ_API_KEY=gsk_...
TAVILY_API_KEY=tvly-dev-...

5. Run the application

python app/main.py

This starts the FastAPI backend on http://127.0.0.1:9999 and the Streamlit frontend on http://localhost:8501 concurrently.

---

Models Supported

Model	Provider	Context
llama3-70b-8192	Groq	8,192 tokens
llama-3.3-70b-versatile	Groq	High-context versatile

---

CI/CD Pipeline

The Jenkinsfile defines four sequential stages:

Stage 1 Clone: Jenkins pulls the latest code from main using a stored GitHub credential (github-token).

Stage 2 SonarQube Analysis: Static code quality analysis runs against the project key Intellex using a self-hosted SonarQube container (sonarqube-dind) on the same Docker network as Jenkins.

Stage 3 Build and Push to ECR: The application Docker image is built, tagged with latest, and pushed to a private AWS ECR repository using stored AWS credentials (aws-token). The ECR URL is resolved dynamically from the account ID at runtime.

Stage 4 Deploy to ECS Fargate: A force-new-deployment command triggers ECS to pull the new image and replace the running task in the multi-ai-agent-cluster without any manual intervention.

Custom Jenkins image

The custom_jenkins/Dockerfile builds a Jenkins image with Docker-in-Docker support pre-configured Docker CE is installed and the Jenkins user is added to the Docker group so pipeline stages can build and push images directly. AWS CLI and SonarQube Scanner are set up separately during the initial Jenkins configuration (see FULL_DOCUMENTATION.md).

---

Environment Variables

Variable	Description
GROQ_API_KEY	API key for Groq LLM inference
TAVILY_API_KEY	API key for Tavily web search

Both are loaded via python-dotenv locally and via ECS task definition environment variables in production. Never commit .env to Git — it is listed in .gitignore.

---

Key Dependencies

Package	Role
langchain-groq	Groq LLM client for LangChain
langgraph	ReAct agent orchestration
langchain-community	Tavily search tool integration
fastapi + uvicorn	Backend REST API server
streamlit	Frontend chat interface
pydantic	Request validation
python-dotenv	Environment variable management

---

Deployment Notes

• The application exposes port 8501 (Streamlit) and 9999 (FastAPI) inside the container.
• For ECS Fargate deployment, map port 8501 in the task definition and allow it through the security group inbound rules.
• Update ECR_REPO in the Jenkinsfile to match your ECR repository name before the first pipeline run.
• Update the ECS --cluster and --service values in the deploy stage to match your Fargate service names.