🧠 E-commerce Operations Brain

An AI-powered multi-agent system that operates like a smart operations manager for your online store — diagnosing issues, recommending actions, and learning from the past.

📖 Table of Contents

Overview
Problem Statement
System Architecture
Agent Roles & Responsibilities
Key Features
Tech Stack
Project Structure
Getting Started
Usage Examples
Dashboard Notes
Core Scenarios
Tool Catalog
Memory System
Human-in-the-Loop (HITL)
Observability & Logging
Evaluation & Testing
Roadmap
Contributing
License

🌐 Overview

The E-commerce Operations Brain is a multi-agent AI system designed to simulate an intelligent operations team for an online store. Instead of querying a single dashboard, a business user can ask natural-language questions and receive:

🔍 Root cause analysis across multiple business domains
📋 Actionable recommendations with reasoning
✅ Safe execution — actions only happen after human approval
🧠 Memory-backed insights — learns from past incidents

This system is built with agentic AI principles: specialized agents collaborate, share findings, and synthesize a final decision — just like a real ops team.

❗ Problem Statement

E-commerce businesses generate signals across dozens of systems: sales data, inventory levels, marketing dashboards, customer support tickets, and more. When something goes wrong — like a revenue drop — no single system tells the full story.

The operational question is always cross-domain:

"Was yesterday's sales drop caused by inventory going out of stock, a campaign failing, or a surge in customer complaints?"

Traditional BI dashboards require a human analyst to manually correlate these signals. This project replaces that manual effort with an autonomous, reasoning AI system that:

Understands the business question in natural language
Investigates each relevant domain independently
Correlates findings to identify root causes
Recommends and executes corrective actions with human oversight

🏗️ System Architecture

┌─────────────────────────────────────────────────────────────────┐
│              REACT + EPAM UUI LOVESHIP FRONTEND                 │
│        Chat Console │ HITL Panel │ Dashboard │ Incidents        │
│               nginx (port 3000) → proxies /api/*                │
└───────────────────────────┬─────────────────────────────────────┘
                            │  Natural Language Query
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                    FASTAPI BACKEND                              │
│    POST /api/query/submit  │  GET /api/query/{job_id}           │
│    POST /api/actions       │  GET /api/incidents                │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                    ORCHESTRATOR NODE                            │
│   • Classifies intent (diagnosis/action/memory/report/chitchat) │
│   • Selects active agents via AGENT_REGISTRY                    │
│   • Loads session context from Redis                            │
│   • Pre-fetches similar past incidents from ChromaDB (RAG)      │
└──────┬──────────┬──────────┬──────────┬──────────┬─────────────┘
       │          │          │          │          │
       ▼          ▼          ▼          ▼          ▼
  ┌─────────┐ ┌──────────┐ ┌────────┐ ┌────────┐  parallel via asyncio
  │  Sales  │ │Inventory │ │ Mktg & │ │Support │
  │  Agent  │ │  Agent   │ │Campaign│ │& CX    │
  └────┬────┘ └────┬─────┘ │ Agent  │ │ Agent  │
       │           │       └───┬────┘ └───┬────┘
       └───────────┴───────────┴──────────┘
                            │
                            ▼  (all join into analyst_outputs)
┌─────────────────────────────────────────────────────────────────┐
│  MOCK TOOL APIS  (GET /tools/sales|inventory|marketing|support) │
└─────────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                    SYNTHESIS NODE                               │
│   Merges analyst outputs + RAG past incidents → root causes     │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                    REFLECTION NODE                              │
│   Self-audits conclusions for gaps and low-confidence signals   │
└──────┬─────────────────────────────────────────────────────────┘
       │
   ┌───┴─────────────────────────┐
   │ Action proposed?            │
   ▼ yes                         ▼ no
┌──────────┐               ┌─────────────┐
│ HITL Gate│               │Final Response│
│ (pause)  │               └──────┬──────┘
└────┬─────┘                      │
     │ approved                   │
     ▼                            ▼
┌──────────────┐        ┌─────────────────────────────────────────┐
│Action        │        │           MEMORY WRITER                 │
│Executor      │───────►│  PostgreSQL (incident log)              │
│POST /tools/  │        │  ChromaDB (vector embed for future RAG) │
│actions/...   │        │  Redis (session history TTL 30 min)     │
└──────────────┘        └─────────────────────────────────────────┘

🤖 Agent Roles & Responsibilities

Agent	Responsibility	Invoked for
Orchestrator	Classifies intent, selects active agents, loads Redis session, fetches RAG context	Every query
Sales Agent	Calls `GET /tools/sales`, analyses revenue trends, order volume, regional performance	diagnosis, action, memory, report
Inventory Agent	Calls `GET /tools/inventory`, detects stockouts and low-stock impact	diagnosis, action, memory, report
Marketing Agent	Calls `GET /tools/marketing`, surfaces campaign pauses and promo issues	diagnosis, action, memory, report
Support Agent	Calls `GET /tools/support`, correlates complaint volume with business events	diagnosis, action, memory, report
Synthesis Node	Merges all analyst outputs + RAG past incidents into ranked root causes	Every query (post-agents)
Reflection Node	Self-audits synthesis for weak or incomplete conclusions	Every query (post-synthesis)
HITL Node	Emits ActionProposal, checkpoints state to Redis, pauses for human approval	action queries
Action Executor	Calls `POST /tools/actions/{type}` only after `hitl_approved == True`	Approved actions only
Memory Writer	Single write path: PostgreSQL + ChromaDB + Redis session	Every resolved query

✨ Key Features

🔁 Multi-Agent Orchestration — Specialist agents work in parallel, findings get synthesized
🌐 Cross-Domain Root Cause Analysis — Correlates signals across sales, inventory, marketing, and CX
🧠 Dual Memory System — Short-term session context + long-term incident memory
🛑 Human-in-the-Loop (HITL) — All destructive or impactful actions require explicit approval
🪞 Self-Reflection Layer — Orchestrator checks for weak conclusions before finalizing
📐 Structured Outputs — Every response is machine-readable and downstream-ready
🔭 Observability — Every agent decision and tool call is logged with reasoning traces
🧪 Evaluation Suite — Automated tests for agent behavior on business scenarios

🛠️ Tech Stack

Layer	Technology	Notes
LLM	EPAM DIAL (GPT-4o via AzureChatOpenAI)	OpenAI-compatible API — configured via `DIAL_API_KEY`
Agent Framework	LangGraph 0.2	Single adaptive graph; one graph, not multiple
Backend	FastAPI 0.115 + uvicorn	Mock tool APIs + async job endpoints
Memory — Short-Term	Redis (TTL 30 min)	Session context + in-flight graph state checkpoint
Memory — Long-Term	PostgreSQL + asyncpg + SQLAlchemy	Incident log (query → root causes → actions → outcome)
Memory — Vector	ChromaDB 0.5 (embedded, no server)	Semantic search for RAG over past incidents
Observability	LangSmith	Trace spans around graph execution, configured at app startup
UI	React 18 + EPAM UUI Loveship + Vite	Chat console, operations dashboard, HITL panel, incident history — served via nginx
Async	Python asyncio	Parallel analyst execution + non-blocking query jobs
Testing	Pytest + pytest-asyncio	Unit + integration + 5 core scenario tests

📁 Project Structure

ecomm-ops-brain/
│
├── app/
│   ├── main.py                      # FastAPI entry point + CORS middleware
│   ├── config.py                    # Settings (env vars) + get_llm() + AGENT_REGISTRY
│   │
│   ├── api/
│   │   ├── query.py                 # POST /api/query/submit, GET /api/query/{job_id}, DELETE
│   │   ├── actions.py               # POST /api/actions (HITL resume)
│   │   ├── incidents.py             # GET /api/incidents
│   │   └── dashboard.py             # GET /api/dashboard (operations dashboard payload)
│   │
│   ├── graph/
│   │   ├── state.py                 # AgentState TypedDict
│   │   ├── graph.py                 # LangGraph graph compilation
│   │   ├── builder.py               # Node + edge wiring
│   │   ├── agents_runner.py         # Parallel analyst execution via asyncio.gather
│   │   ├── routing.py               # Conditional edge logic
│   │   └── nodes/
│   │       ├── orchestrator.py      # Intent classification + RAG fetch
│   │       ├── synthesis.py         # Cross-domain root-cause synthesis
│   │       ├── reflection.py        # Self-check for weak conclusions
│   │       ├── hitl.py              # HITL pause gate + Redis checkpoint
│   │       └── action_executor.py   # Executes approved actions
│   │
│   ├── agents/                      # Analyst agents (called by agents_runner.py)
│   │   ├── base_agent.py
│   │   ├── sales_agent.py
│   │   ├── inventory_agent.py
│   │   ├── marketing_agent.py
│   │   └── support_agent.py
│   │
│   ├── services/
│   │   ├── query_service.py         # Graph invocation + runtime stage signalling
│   │   ├── action_service.py        # HITL resume + action execution + runtime stage updates
│   │   ├── dashboard_service.py     # Dashboard stats, backend health, and data-source labels
│   │   └── incident_service.py      # Incident read + ChromaDB semantic search
│   │
│   ├── tools/                       # Mock FastAPI routes
│   │   ├── sales.py                 # GET /tools/sales
│   │   ├── inventory.py             # GET /tools/inventory
│   │   ├── marketing.py             # GET /tools/marketing
│   │   ├── support.py               # GET /tools/support
│   │   └── actions.py               # POST /tools/actions/{action_type}
│   │
│   ├── memory/
│   │   ├── redis_client.py          # Session state + runtime stage diagnostics
│   │   ├── postgres_client.py       # Incident CRUD
│   │   ├── chroma_client.py         # Vector embed + cosine similarity search
│   │   └── memory_writer.py         # Single write path for all three stores
│   │
│   ├── schemas/
│   │   ├── query.py                 # QueryResult, IncidentContext
│   │   ├── agents.py                # AnalystOutput per domain
│   │   ├── actions.py               # ActionProposal, ActionResult
│   │   └── incidents.py             # Incident, IncidentSummary
│   │
│   ├── core/
│   │   ├── error_handler.py         # Global FastAPI exception handlers
│   │   ├── dependencies.py          # DI: shared httpx/redis client instances
│   │   ├── llm_utils.py             # invoke_with_retry() — tenacity wrapper for all LLM calls
│   │   └── rate_limiter.py          # slowapi Limiter singleton (avoids circular import)
│   │
│   └── observability/
│       └── tracer.py                # configure_tracing() for LangSmith environment bootstrap
│
├── frontend/                        # React + EPAM UUI Loveship frontend
│   ├── Dockerfile                   # Multi-stage: node:20 builds, nginx:alpine serves
│   ├── nginx.conf                   # /api/* proxied to backend container
│   ├── package.json                 # @epam/loveship, react-router-dom, vite
│   ├── vite.config.ts
│   └── src/
│       ├── main.tsx                 # React entry + loveship CSS import
│       ├── App.tsx                  # BrowserRouter + layout
│       ├── index.css                # Loveship dark theme CSS variables
│       ├── api/client.ts            # All fetch calls (submit, poll, cancel, action, dashboard)
│       ├── types/index.ts           # TypeScript types matching backend schemas
│       ├── components/
│       │   ├── Sidebar.tsx          # Dark nav sidebar (Chat / Dashboard / Incidents)
│       │   ├── ChatPage.tsx         # Chat UI with polling, badges, expanders
│       │   ├── HITLPanel.tsx        # Per-action-type editable approval panel
│       │   ├── DashboardPage.tsx    # Metrics grid, agent cards, bar chart, event feed
│       │   └── IncidentsPage.tsx    # Searchable incident history with expandable cards
│       └── pages/                   # Barrel re-exports for React Router
│
├── data/
│   └── incidents.json               # 2000 seeded incidents
│
├── scripts/
│   └── seed_incidents.py            # Seeds PostgreSQL + ChromaDB (idempotent)
│
├── tests/
│   ├── unit/
│   │   ├── test_agents.py
│   │   ├── test_nodes.py
│   │   ├── test_schemas.py
│   │   └── test_memory.py
│   └── integration/
│       ├── test_api.py
│       ├── test_graph.py
│       └── test_scenarios.py        # 5 core demo scenarios
│
├── alembic/                         # Database migrations
├── .env.example
├── requirements.txt
└── CLAUDE.md                        # AI coding context and conventions

🚀 Getting Started

Prerequisites

Docker Desktop with WSL 2 backend (recommended) — runs all services in containers
An EPAM DIAL API key (OpenAI-compatible endpoint)
(Optional) LangSmith account for tracing

For local development without Docker: Python 3.11+, Node 20+, Redis, PostgreSQL 16

Installation

# 1. Clone the repository
git clone https://git.epam.com/your-username/ecomm-ops-brain.git
cd ecomm-ops-brain

# 2. Create a virtual environment
python -m venv .venv
source .venv/bin/activate        # On Windows: .venv\Scripts\activate

# 3. Install dependencies
pip install -r requirements.txt

Environment Variables

Copy .env.example to .env and fill in your values:

cp .env.example .env

# EPAM DIAL
DIAL_API_KEY=your-dial-api-key-here
DIAL_API_BASE=https://your-dial-endpoint/openai
DIAL_MODEL=gpt-4o

# LangSmith (optional, for observability)
LANGCHAIN_TRACING_V2=true
LANGCHAIN_API_KEY=your-langsmith-api-key-here
LANGCHAIN_PROJECT=ecomm-ops-brain

# Redis (start via WSL: sudo service redis-server start)
REDIS_URL=redis://localhost:6379

# PostgreSQL
POSTGRES_URL=postgresql+asyncpg://postgres:postgres@localhost:5432/ecomm_ops

# ChromaDB (embedded — no server needed)
CHROMA_PATH=./chroma_data

# App
LOG_LEVEL=INFO
HITL_TIMEOUT_SECONDS=120

Running the System

🐳 Docker (recommended)

# Clone and configure env
git clone https://git.epam.com/your-username/ecomm-ops-brain.git
cd ecomm-ops-brain
cp .env.example .env   # fill in DIAL_API_KEY and optionally LANGCHAIN_API_KEY

# Build and start all 4 services (postgres, redis, backend, frontend)
docker compose up --build

Service	URL
React frontend	http://localhost:3000
FastAPI backend	http://localhost:8000
Swagger docs	http://localhost:8000/docs

docker-entrypoint.sh automatically runs Alembic migrations and seeds 2000 incidents on first start.

💻 Local (without Docker)

# 1. Start Redis + PostgreSQL manually (or via WSL)
sudo service redis-server start
sudo service postgresql start

# 2. Install Python dependencies
pip install -r requirements.txt

# 3. Run migrations and seed
alembic upgrade head
python scripts/seed_incidents.py

# 4. Start backend
uvicorn app.main:app --reload --port 8000

# 5. Start React frontend (separate terminal)
cd frontend
npm install
npm run dev   # http://localhost:3000

Run tests:

pytest tests/ -v

💬 Usage Examples

📊 Dashboard Notes

The dashboard (/dashboard) is an operations view — business health score, inventory risk table, agent work cards, regional revenue bar chart, and recent activity feed.
All data is live from PostgreSQL and Redis — no mock data on the dashboard.
Revenue cards, regional sales breakdown, and support SLA/CSAT trends are sourced from the sales_daily_metrics and support_daily_metrics PostgreSQL tables.

1. Diagnosing a Business Issue

Input:

"Why did sales drop yesterday?"

System Output (structured):

{
  "summary": "Sales dropped 34% yesterday compared to the prior 7-day average.",
  "root_causes": [
    {
      "domain": "Inventory",
      "finding": "3 top-selling SKUs were out of stock for 14+ hours",
      "confidence": 0.91
    },
    {
      "domain": "Marketing",
      "finding": "Email campaign scheduled for 10am was not sent due to a config error",
      "confidence": 0.87
    }
  ],
  "recommended_actions": [
    "Restock SKUs: SKU-102, SKU-207, SKU-334",
    "Reschedule or resend email campaign",
    "Apply 10% promotional discount to affected products"
  ],
  "memory_context": "Similar drop occurred on 2024-11-03 — resolved by restocking + campaign relaunch"
}

2. Taking Corrective Action (HITL)

Input:

"Fix the issue."

System pauses and displays:

⚠️  The following actions require your approval before execution:

  [1] Restock SKU-102, SKU-207, SKU-334 (triggers purchase order)
  [2] Reschedule email campaign for 2pm today
  [3] Apply 10% discount to top 3 affected products for 48 hours

Approve all? [yes/no] or select: [1, 2, 3]

User input: 1 2

System executes approved actions only and logs outcome.

3. Memory-Based Recall

Input:

"What did we do last time this happened?"

Output:

On 2024-11-03, a similar 31% sales drop was caused by stockouts + a failed campaign.
Actions taken:
  ✅ Restocked 4 SKUs → resolved within 6 hours
  ✅ Relaunched campaign → recovered 80% of lost revenue by EOD
  ❌ Discount offer — not used, deemed unnecessary

Recommendation: Prioritize restock + campaign relaunch over discount.

🧰 Tool Catalog

All tools are mock FastAPI routes under /tools/ that return realistic seeded data for three core scenarios.

Endpoint	Method	Domain	Description
`/tools/sales`	GET	Sales	Revenue, order count, AOV, regional breakdown, promo status
`/tools/inventory`	GET	Inventory	Stock levels, stockout products, low-stock alerts
`/tools/marketing`	GET	Marketing	Campaign performance, paused campaigns, active promos
`/tools/support`	GET	Support	Complaint volume, top issue categories, CSAT score
`/tools/actions/restock`	POST	Action	Restocks products to 100 units (HITL)
`/tools/actions/resume_campaign`	POST	Action	Resumes a paused campaign (HITL)
`/tools/actions/apply_discount`	POST	Action	Applies promotional discount to SKUs (HITL)
`/tools/actions/extend_promo`	POST	Action	Extends an active promotion's end date (HITL)
`/tools/actions/create_support_ticket`	POST	Action	Opens a support escalation ticket (HITL)
`/tools/actions/escalate`	POST	Action	Escalates an existing issue (HITL)

⚠️ All /tools/actions/ endpoints are guarded by HITL — they will never be called without hitl_approved == True.

🧠 Memory System

The system uses a three-layer memory architecture, all written through a single memory_writer.py to avoid scattered writes.

Short-Term Memory (Redis)

Keyed by session_id, TTL = 30 minutes
Stores the current AgentState snapshot so the graph can be resumed after HITL pause
Also tracks runtime stage (orchestrator → agents → synthesis → reflection → hitl → action → done → idle) for internal diagnostics and troubleshooting

Long-Term Memory (PostgreSQL)

incidents table: id, timestamp, query, query_type, root_causes, actions_proposed, actions_approved, outcome_notes, conversation_history
Written by memory_writer.py at the end of every resolved query
Managed with Alembic migrations

Vector Memory (ChromaDB — embedded)

Each resolved incident is embedded and stored on write
Retrieved via cosine similarity search at the start of every query (RAG)
Top-3 similar past incidents are injected into the synthesis prompt as context
No separate ChromaDB server needed — runs embedded in ./chroma_data/

Schema of a stored incident:

{
  "incident_id": "uuid",
  "timestamp": "2026-04-13T10:00:00Z",
  "query": "Why did sales drop yesterday?",
  "query_type": "diagnosis",
  "root_causes": ["3 SKUs out of stock", "campaign paused"],
  "actions_proposed": ["restock", "resume_campaign"],
  "actions_approved": ["restock"],
  "outcome_notes": "Revenue recovered 80% within 24h"
}

🛑 Human-in-the-Loop (HITL)

Any action that modifies business state is gated behind a mandatory human approval step enforced in two places in code — hitl.py (graph node) and action_executor.py (both assert hitl_approved == True before proceeding).

Flow:

Synthesis determines an action is needed → hitl_node emits ActionProposal and sets hitl_approved = None
Graph checkpoints full AgentState to Redis and returns control to the UI
Streamlit hitl_panel.py renders the approval card — operator clicks Approve, Reject, or edits parameters
UI sends POST /api/actions with { session_id, decision, selected_action_index }
action_service.py loads the paused state from Redis, sets hitl_approved, and invokes action_executor_node

Principles:

✅ The system will always propose before executing
✅ Operators can approve, reject, or modify action parameters before confirming
✅ Rejected actions are logged as "declined" in the incident record
✅ HITL timeout: HITL_TIMEOUT_SECONDS (default 120 s) — returns 408 if not actioned in time
❌ No action bypasses this gate — the guard is enforced in both node and executor code

🔭 Observability & Logging

Graph execution is instrumented end-to-end:

LangSmith Integration — Application startup calls configure_tracing() and the graph uses LangSmith trace spans around orchestrator, agent runner, synthesis, reflection, HITL, and action execution.
Redis Stage Tracking — Each node updates its runtime stage (orchestrator → agents → synthesis → reflection → hitl → action → done → idle) so execution state is available for debugging and future admin diagnostics.
Dashboard Data Labels — The operations dashboard distinguishes persisted operational data from demo sales/support snapshots so the UI does not imply unavailable historical data is live.

To view LangSmith traces: https://smith.langchain.com → Project: ecomm-ops-brain

🧪 Evaluation & Testing

tests/
├── unit/
│   ├── test_agents.py       # Each analyst agent in isolation (mock tool responses)
│   ├── test_nodes.py        # Graph nodes in isolation (mock AgentState)
│   ├── test_schemas.py      # Pydantic schema validation + serialisation
│   └── test_memory.py       # Memory clients with mock backends
└── integration/
    ├── test_api.py          # FastAPI endpoint tests (TestClient)
    ├── test_graph.py        # Full graph execution against mock tool APIs
    └── test_scenarios.py    # 5 core demo scenarios end-to-end

5 core demo scenarios (must all pass before the project is considered complete):

#	Question	Expected behaviour
1	"Why did sales drop yesterday?"	Cross-domain synthesis citing inventory + campaign signals
2	"Fix the problem."	ActionProposal emitted, graph pauses for HITL
3	"What did we do last time this happened?"	ChromaDB recall surfaces ≥1 past incident
4	"Which products are close to stock-out?"	Inventory analyst only, structured list response
5	"Summarize yesterday's business health."	Full structured report, no action proposed

# Run all tests
pytest tests/ -v

# Run only scenario tests
pytest tests/integration/test_scenarios.py -v

🗺️ Roadmap

🤝 Contributing

Contributions, issues, and feature requests are welcome!

Fork the repository
Create a feature branch: git checkout -b feature/your-feature-name
Commit your changes: git commit -m 'feat: add your feature'
Push to the branch: git push origin feature/your-feature-name
Open a Pull Request

📄 License

This project is under the EPAM R&D Python Training.

👤 Author

Esha Jawade Built with ❤️ as a deep-learning AI engineering project.
Guided by principles of multi-agent design, responsible AI (HITL), and production-grade observability.

"The best ops team is one that never sleeps, never misses a signal, and always asks before acting."

Navigation Menu

Repository files navigation

🧠 E-commerce Operations Brain

📖 Table of Contents

🌐 Overview

❗ Problem Statement

🏗️ System Architecture

🤖 Agent Roles & Responsibilities

✨ Key Features

🛠️ Tech Stack

📁 Project Structure

🚀 Getting Started

Prerequisites

Installation

Environment Variables

Running the System

🐳 Docker (recommended)

💻 Local (without Docker)

💬 Usage Examples

📊 Dashboard Notes

1. Diagnosing a Business Issue

2. Taking Corrective Action (HITL)

3. Memory-Based Recall

🧰 Tool Catalog

🧠 Memory System

Short-Term Memory (Redis)

Long-Term Memory (PostgreSQL)

Vector Memory (ChromaDB — embedded)

🛑 Human-in-the-Loop (HITL)

🔭 Observability & Logging

🧪 Evaluation & Testing

🗺️ Roadmap

🤝 Contributing

📄 License

👤 Author

About

Releases

Packages

Contributors

Languages

Name		Name	Last commit message	Last commit date
alembic		alembic
app		app
data		data
frontend		frontend
scripts		scripts
tests		tests
.dockerignore		.dockerignore
.env.example		.env.example
.gitignore		.gitignore
Dockerfile		Dockerfile
README.md		README.md
alembic.ini		alembic.ini
docker-compose.yml		docker-compose.yml
docker-entrypoint.sh		docker-entrypoint.sh
requirements.txt		requirements.txt

Latest commit

History

Folders and files

Repository files navigation

🧠 E-commerce Operations Brain

📖 Table of Contents

🌐 Overview

❗ Problem Statement

🏗️ System Architecture

🤖 Agent Roles & Responsibilities

✨ Key Features

🛠️ Tech Stack

📁 Project Structure

🚀 Getting Started

Prerequisites

Installation

Environment Variables

Running the System

🐳 Docker (recommended)

💻 Local (without Docker)

💬 Usage Examples

📊 Dashboard Notes

1. Diagnosing a Business Issue

2. Taking Corrective Action (HITL)

3. Memory-Based Recall

🧰 Tool Catalog

🧠 Memory System

Short-Term Memory (Redis)

Long-Term Memory (PostgreSQL)

Vector Memory (ChromaDB — embedded)

🛑 Human-in-the-Loop (HITL)

🔭 Observability & Logging

🧪 Evaluation & Testing

🗺️ Roadmap

🤝 Contributing

📄 License

👤 Author

About

Topics

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages