# Linkedin Projects My agentic RAG system uses an arXiv cs.AI corpus of 50 papers sorted by submission date. My documents use RecursiveCharacterTextSplitter with chunk_size=1024 and overlap=150. My embeddings use nomic-embed-text through local Ollama. I build the FAISS index once via vector.py and load it at startup with @st.cache_resource to avoid redundant deserialization. At 10k+ documents, I would move to a persistent store like Qdrant. I chose LangGraph because I needed explicit state management, conditional routing across more than three nodes, and the ability to pause mid-graph via interrupt() and resume on user input. All my models connect to Ollama on host.docker.internal:11434, making the stack fully portable via Docker without any API keys. My evaluation covered 10 test cases across all 5 routing decisions and achieved final accuracy of 100% (10/10). I must pre-build the FAISS index with python vector.py before launching; the app errors if faiss_index/ does not exist. My PythonREPLTool runs unsandboxed: LLM-generated code executes in-process with full Python privileges, including filesystem writes and os.system() calls. Under heavy usage, arXiv rate limits cause HTTP 429 errors; retry and backoff logic is not currently implemented. One proposed follow-up is to expand evaluation to 25+ cases with a held-out test set. My GreenPack EPR Compliance API repository started 2026-05 and was last updated 2026-05. I chose FastAPI for async support, automatic OpenAPI docs, and Pydantic integration. I chose an in-memory Python dict because it is sufficient for this scope, has no overhead, and is easy to swap to SQLite or Postgres later. The task explicitly noted Ollama as an acceptable workflow for my project. My project structure includes main.py as the FastAPI app for all three endpoints, erp_data.csv as a mock ERP procurement feed, and requirements.txt for Python dependencies. I require Ollama to be installed and running locally before setup. ``` ollama pull llama3.1:8b ollama pull nomic-embed-text pip install -r requirements.txt uvicorn main:app --reload ``` My GreenPack EPR Compliance API exposes POST /submit; GET /summary; POST /ask. I use Pydantic v2 for validation, which is deterministic and does not need an LLM. For `POST /submit`, no LLM is involved; validation is purely deterministic via Pydantic. My declaration validation rule is: All weight fields must be ≥ 0. My declaration validation rule is: `month` must match `YYYY-MM` format. My declaration validation rule is: `producer_id` must be non-empty. My example declaration is for producer GREENPACK-001, month 2026-04, with 12000 kg rigid plastic, 8500 kg flexible plastic, and 3200 kg multilayer plastic. My example submission response has record ID REC-A3F2B1C9 and timestamp 2026-04-15T10:32:00.000000. My rigid-plastic reconciliation is 12000.0 kg declared; 11800.0 kg procured; 200.0 kg difference; not flagged. My flexible-plastic reconciliation is 8500.0 kg declared; 9100.0 kg procured; -600.0 kg difference; flagged. My multilayer-plastic reconciliation is 3200.0 kg declared; 3200.0 kg procured; 0.0 kg difference; not flagged. My flexible-plastic example is 6.6% below procurement; 5% tolerance threshold. My `/summary` endpoint reads the stored declaration, cross-references the mock ERP CSV, flags categories with >5% variance, and uses an LLM to generate a plain-English compliance narrative. My reconciliation narrative says rigid plastic and multilayer plastic are within acceptable variance. My reconciliation narrative recommends reviewing the flexible plastic declaration, investigating data-entry error or unreported usage, and filing a corrected submission before the monthly deadline. My example `/ask` answer says producers who fail to meet annual plastic waste collection targets may face suspension of EPR registration and restrictions on further plastic packaging usage until compliance is demonstrated. My example `/ask` response cites “CPCB EPR Guidelines 2022 - Section 4: Obligations of Producers” and “Plastic Waste Management Rules 2016 (Amended 2022) - Rule 9”. My source describes five EPR policy documents as being used to seed the RAG vector store. My source labels the mock documents clearly and says they are not sourced from live government publications. For real compliance, my source points readers to the CPCB EPR Guidelines at https://cpcb.nic.in and the Plastic Waste Management Rules 2016 at https://egazette.gov.in. I iterated on the summary prompt to enforce “3-5 sentences, no fluff” and prevent the model from doing analysis instead of narration. I chose a Python dict over SQLite to keep setup friction zero; declarations do not survive a server restart. For a real system, I would use SQLite because it is a single file with no server and is still trivial to set up, or Postgres if multi-instance deployment is needed. I consider Claude's instruction following on structured-output tasks such as “write exactly 3-5 sentences, no fluff” noticeably more reliable than the local deepseek-r1 and llama3 models. I identified adding auth middleware as proposed work because any caller can currently read any producer's data. I identified making the Endpoint 2 ERP read asynchronous as proposed work because the CSV read is synchronous and would block under load. I identified streaming responses on `/ask` as proposed work to improve the user experience on slow local models. I built this project as part of the Innotechwise / Futuryntix Group Junior AI Engineer screening task. The endpoint description says: Answers are grounded exclusively in the loaded document corpus — no hallucination. When the corpus lacks an answer, the endpoint returns: I do not know based on the provided documents. The mock policy content says producers must recycle ≥50% of rigid plastic waste by 2026. The mock policy content describes a ₹5,000/day penalty for inaccurate reporting. The mock policy content says 100% of multilayer plastic must go to end-of-life disposal if it cannot be recycled. The corpus-source section enumerates three documents in epr_documents.json. The source describes the policy corpus as fabricated mocks; not legally accurate. I chose a Python dict for zero setup friction; declarations do not survive server restart; SQLite proposed for real use and Postgres for multi-instance deployment. With another day, I would Swap Ollama models for the Anthropic API (Claude) for more reliable structured-output instruction following. My proposed engineering work includes Persistent storage (SQLite with SQLAlchemy). My reconciliation flagging math currently has no test coverage. Claude drafted the get_erp_data CSV reader and percentage-diff flagging loop; procured_val = 0 edge case reviewed and tightened. Claude Code scaffolded FAISS + LangChain + Ollama embeddings wiring; OllamaEmbeddings import path changed in recent LangChain versions. I used a prompt to get the @field_validator / @classmethod syntax right quickly. All AI-assisted sections were reviewed, understood, and adjusted before committing. My summary flow uses deepseek-r1:8b via Ollama for structured compliance narratives; the model is described as strong at reasoning, free, and local with no API cost. My RAG Q&A model is llama3.1:8b via Ollama; it is described as fast and instruction-following, and as handling strict “only answer from context” prompting well. My embeddings and vector store are nomic-embed-text via Ollama; FAISS via LangChain. I chose local Ollama for zero API spend; no keys to manage; data sovereignty. My project prerequisites and policy corpus size are Python 3.10+; 5 EPR/plastic policy documents. One of my local setup commands is `ollama pull deepseek-r1:8b`; the setup also pulls the other two Ollama models, installs Python dependencies, and starts Uvicorn. My local API and Swagger documentation URLs are http://localhost:8000; http://localhost:8000/docs. I built GreenPack EPR Compliance API for GreenPack Industries as part of the Innotechwise Junior AI Engineer screening task. The service supports monthly plastic declarations, reconciliation against ERP procurement data, and compliance-policy Q&A. Declarations are validated and held in an in-memory Python dict; reconciliation reads ERP CSV data and generates an LLM narrative, while policy Q&A uses FAISS retrieval and an LLM over EPR policy documents. My project files include main.py, erp_data.csv, epr_documents.json, requirements.txt, and README.md. The captured README does not provide endpoint schemas or payload examples, reconciliation formulas, validation rules, performance or evaluation results, or deployment details beyond local Uvicorn use. My local-llm-performance-predictor benchmark dataset is 288 rows from 8 local LLMs, spanning 1B to 12B parameters. My measurement methods are psutil RAM every 60ms; system-wide pynvml VRAM delta; wall-clock latency from first token request to last token received. My test hardware is AMD Ryzen; 32GB RAM; NVIDIA RTX 5060 8GB VRAM; Windows 11. My model-size correlations are latency r = 0.79; VRAM r = 0.83; strongest predictor across all three targets. My selected algorithms are Ridge for latency; Random Forest for RAM and VRAM. My latency cross-validation scores are Ridge (α=0.01) 0.54; Random Forest 0.81; Gradient Boosting 0.72; winner Ridge. My RAM cross-validation scores are Ridge 65.4; Random Forest 7.6; Gradient Boosting 9.4; winner Random Forest. My VRAM cross-validation scores are Ridge 143.9; Random Forest 0.32; Gradient Boosting 12.0; winner Random Forest. My model measurements for the first group are gemma3:1b: 848 MB RAM, 999 MB VRAM, 6.9s; llama3.1:8b: 715 MB RAM, 5,233 MB VRAM, 11.1s; qwen3.5:9b: 2,767 MB RAM, 4,637 MB VRAM, 24.3s. My model measurements for the second group are gemma4:latest: 7,386 MB RAM, 3,175 MB VRAM, 13.6s; gemma3:12b: 5,017 MB RAM, 5,042 MB VRAM, 49.5s. My gemma3:12b offload pattern is 10× slower per GB of VRAM than the 8B cluster; exceeds available VRAM and spills layers to CPU; system RAM above 5GB is the offload fingerprint. My supported model size range is 1B–12B parameters; inputs above 12.0 are rejected. My excluded model was qwen3-coder:30b excluded after ollama.generate() consistently produced CUDA out-of-memory errors on 8GB VRAM; explicit num_ctx allocation was a likely cause. My example prediction is 11.20 seconds latency; 718.38 MB (0.70 GB) peak RAM; 5664.88 MB (5.53 GB) peak VRAM delta. My API input constraints are model_size_b at most 12.0; context-window choices [2048, 4096, 8192]. My benchmark design is 8 models × 4 prompts × 3 context windows × 3 runs, with repeated runs averaged to reduce system noise. I capture the VRAM baseline after 3 stable readings within 5MB to eliminate carry-over from previous runs. My EDA found prompt length and latency correlation at r ≈ 0.00; with a 768-token output cap, generation time dominates and input processing is negligible. My context-window and VRAM correlation is r = 0.13, a statistically present but small effect compared with model size, consistent with the theoretical KV cache relationship. My gemma3:12b one-hot flag became the single most important latency-prediction feature, with 48% importance. My Gradient Boosting comparison landed between Ridge and Random Forest on every target, but was less suitable than Random Forest for this dataset's discrete-cluster structure. My near-perfect VRAM Random Forest score reflects highly deterministic usage across only 8 discrete models and low variance, not necessarily generalization to unseen architectures. My project uses a scikit-learn ColumnTransformer with StandardScaler and OneHotEncoder, GridSearchCV, 5-fold cross-validation, and joblib persistence. I run the API with `uvicorn backend:app --reload`. I run the frontend with `streamlit run user_interface.py`. My API provides POST /predict and GET /health endpoints, with Pydantic validation and 1B–12B range enforcement. My predictions may not generalize to architectures absent from the eight-model dataset; a similarly sized model with a very different architecture may fall outside the prediction distribution. My README reports cross-validation values but does not specify the quality metric name used for its cross-validation table. My system-wide VRAM delta can be noisy when other GPU-using applications are running. I built this project on real benchmark data, with no synthetic data, no cloud APIs, and fully local operation. My Question Answer Agent uses an in-memory vector store that retrieves the closest matching document chunk using its built-in embedding, without an external API. My QA Agent cleans raw ChromaDB chunks before display by converting large headings to bold, collapsing excess whitespace, and auto-formatting short lines as titles. When Gemini returns a 429 error, my app asks users to wait ~60 seconds before retrying. I split Study Buddy into a full conversational mode and a lightweight QA mode so people without an API key, or who do not want to use one, can still use the app. My default PDF parser often loses tables and structured formatting. My in-process ChromaDB client handles vector storage and retrieval without external dependencies. ChromaDB's internal embedding gives my basic QA mode zero setup cost. I store ChatMemoryBuffer in st.session_state so it persists across reruns without re-caching the agent. I inject the last 4 conversation turns alongside the memory buffer so follow-ups remain understandable even if the buffer is truncated. My English Language Lock is intended to prevent multilingual models such as Qwen from switching languages mid-session. For follow-up questions, my system prompt says to include the prior topic in the tool query. My agent must never answer from memory alone and must retrieve fresh context through tools. My system prompt says to explain concepts clearly using bullet points. My agent redirects off-topic questions back to the syllabus. My agent maintains a formal, academic, yet encouraging tone. My follow-up example uses the injected history to turn “What happens after that?” into the tool query `mitosis phases after metaphase`; the example answer begins, “Following metaphase, the cell enters Anaphase”. My linked-list QA example retrieves the top chunk and streams an excerpt defining each node as containing a data field and a reference to the next node. My first load, including embedding-model download and document indexing, takes ~1-2 minutes and is cached for the session. When a new file is added, my app automatically resets the index, memory, and chat history. My Gemini mode is described as fast cloud inference with minimal local resource use. My QA Agent mode is described as near-instant through ChromaDB with no API latency. For optimal indexing performance on large documents, my guidance is to split them into 20–30 page chunks. I recommend using a Gemini key for the best conversational experience and QA Agent mode for quick lookups without an API key. When Gemini rate-limits the app, users can switch to Question Answer Agent mode while waiting ~60 seconds. If Ollama cannot find the model, my troubleshooting instruction is `ollama pull qwen3:4b`. For poor PDF extraction, users can enter a LlamaCloud key in the sidebar to enable LlamaParse. If follow-up handling still fails, my troubleshooting advice is to ask with explicit context, such as “what happens after mitosis metaphase?” instead of “what happens next?”. If Ollama responses are slow, users can switch to Gemini or check that they have ~2GB of free RAM for Qwen3:4b. My free-use FAQ says Question Answer Agent mode needs no API key and makes no external API calls. My documentation describes LlamaParse as optional and especially useful for PDFs with tables, multi-column layouts, or structured formatting. My documentation says Google Gemini has a free tier sufficient for most student use. My documentation says LlamaCloud also has a free tier. My documentation describes the QA Agent mode as completely free. My documentation says embeddings always run locally for free. My system prompt restricts all responses to uploaded document content only. When LlamaParse is used, PDF content is sent to LlamaCloud for parsing. My index is the heavy component that is cached; only the lightweight agent wrapper rebuilds per query. I reset the index, chat history, and memory buffer automatically when switching to a new document to avoid contamination from previous documents. For issues, questions, or suggestions about my project, I ask people to open an issue on GitHub. My Study Buddy splits documents into 1024-token chunks with SentenceSplitter. My Conversational Agent architecture is VectorStoreIndex; SummaryIndex; ReActAgent selects vector_tool and summary_tool. My Conversational Agent retrieves the top 5 chunks, while the QA Agent retrieves the top 1. My embeddings are BAAI/bge-small-en-v1.5 local, 384-dim; QA uses ChromaDB internal embedding. My RAG Amnesia Fix uses Last 4 messages prepended to every new prompt. My models are gemini-1.5-flash primary; qwen3:4b fallback. My Conversational Agent has a memory limit and Ollama timeout of 4096 tokens; 150 seconds. My index caching configuration is build_index uses @st.cache_resource and rebuilds only on file change; build_agent is not cached. My PDF parsing configuration is LlamaParse produces clean Markdown preserving tables, headings, and structure; falls back to SimpleDirectoryReader without a key. My data handling is Gemini conversational queries are sent to Google; QA mode stays on the user's machine. My system prompt rules are Always respond in English; retrieve context for every question; use summary_tool only for broad overviews. For event-loop stability, my app uses Set asyncio.DefaultEventLoopPolicy() before nest_asyncio.apply(). My QA Agent uses a word-by-word generator stream_text with st.write_stream. My Ollama resource guidance is ~2GB RAM; CPU-friendly; GPU optional. My Katta-Nitish.github.io repository is listed with HTML, 2 stars, and a last-updated date of 2026-07. My Katta-Nitish repository is listed with 2 stars and a last-updated date of 2026-06. My tutorial_builder repository was last updated 2026-10. I use my GitHub profile to showcase projects across agentic AI, RAG, local LLM applications, dashboards, and practice work. The repository descriptions below reflect what my profile says; they do not provide implementation or adoption details beyond those summaries. My ClauseIQ repository metadata is Python; 2 stars; started 2026-07; last updated 2026-07. My ClauseIQ privacy design is 100% offline; zero API keys; data never leaves my machine. ClauseIQ extracts termination, confidentiality, and liability clauses; summarizes purpose, obligations, and risk exposure consistently. ClauseIQ uses one structured extraction-and-summarization call per contract, faster than four separate calls and supporting consistent terminology. ClauseIQ checks summaries against a target word range and retries with the previous attempt and corrective feedback when out of range. ClauseIQ isolates per-contract failures; a 50-contract run can complete despite a handful of malformed PDFs or scanned images. ClauseIQ uses Pydantic and LangChain schema-enforced structured output for extraction. ClauseIQ uses local embeddings with nomic-embed-text via Ollama, indexed in FAISS for semantic clause search. ClauseIQ uses gemma3:12b for extraction and Q&A generation; nomic-embed-text for local embeddings. ClauseIQ writes the extraction outputs cuad_extracted_output.csv; cuad_extracted_output.json. ClauseIQ uses a LangChain LCEL retrieval-to-generation chain and Streamlit dashboard. ClauseIQ quickstart: ollama serve &, pull gemma3:12b and nomic-embed-text, create and activate .venv, install requirements, run main.py, vector_db.py, and streamlit run app.py. I built ClauseIQ as a local RAG pipeline for legal contract intelligence. It processes a folder of PDFs, indexes extracted clauses, answers natural-language questions across the library with cited sources, and presents per-contract summaries and clauses alongside chat-based Q&A. The design keeps contract text, embeddings, and questions on my machine, without a hosted vector database. The README describes a pipeline in which main.py loads and normalizes PDFs and makes the structured extraction call; vector_db.py builds the local FAISS index; qna_backend.py retrieves clauses and generates answers; and app.py provides the Streamlit interface. I chose Pydantic structured output to avoid fragile regex or JSON parsing, and LangChain LCEL for a composable retrieval-to-generation chain. The README also describes Streamlit as a quick way to build an interactive demo. For summaries outside the configured word range, the pipeline checks the generated output in code and asks the model to correct it using the prior attempt and specific feedback. The README says prompting a local model harder alone often does not fix format-following. Per-contract error handling is intended to let a batch continue when an individual PDF is malformed or the model response is unreliable. ``` ollama serve & ollama pull gemma3:12b ollama pull nomic-embed-text python3 -m venv .venv && source .venv/bin/activate pip install -r requirements.txt python main.py python vector_db.py streamlit run app.py ``` After setup, the README directs me to open the local URL printed by Streamlit, choose a contract to review, or ask questions across the library. The README does not report measured extraction-quality scores, latency, evaluation results, or the numeric target summary word range. It also leaves open the configured contracts-folder path, hardware requirements, supported PDF characteristics, exact extraction schema and missing-clause handling, citation-linking details, FAISS persistence and retrieval settings, and implementation and evaluation of roadmap items such as relevance-based chunking, few-shot extraction examples, more clause types, and a model-comparison evaluation harness. My GitHub profile says: On GitHub since 2025. 3 followers. The language totals shown on my profile are Python (17), HTML (1). My lesson-forge repository is described as: An agentic content pipeline that writes beginner lessons, grades them against a strict pass/fail rubric, and rewrites on failure — with memory that persists across sessions to avoid repeating past mistakes. Built with LangGraph + local LLMs via Ollama. I describe lesson-forge in my README as a Self-Evaluating Lesson Content Generator. Its example topic is Introduction to RAG (Retrieval-Augmented Generation). It is a small LangGraph state machine with two nodes and one conditional router, wrapped in a Streamlit UI for observability. My lesson-forge repository metadata is Python, 3 stars; started 2026-08, last updated 2026-08. I use qwen3.5:9b generation at 0.3; deepseek-r1:8b evaluation at 0.1. The separate models reduce the risk of a model rubber-stamping its own blind spots; the trade-off is latency from two model loads per cycle, which I consider acceptable for a non-real-time content pipeline. My rubric has 6 hard binary pass/fail checks; all must pass and there is no partial credit. The checks cover accuracy and internal consistency, beginner-friendliness for a 12th-grade graduate with limited English, examples, key-point coverage, unexplained jargon, and coherent flow. A single unexplained jargon word automatically fails that dimension in my lesson rubric. My retry limit is 2 retries; failure at the limit exits as max_retries_reached and ships as best effort. The graph routes to END on a pass, retries a failure while below the limit, and ends at the limit. My Pydantic EvaluationRubric schema passed through with_structured_output produces a typed object rather than free text to parse. The evaluator returns a specific, actionable failure_reason, which I feed into the next generation prompt as an urgent fix instruction. My eval_memory.json is generated at runtime and committed as demo evidence. It stores deduplicated failure reasons across runs and injects them into future generation prompts, including for new topics. The project files are agent.py, app.py, eval_memory.json, requirements.txt, .gitignore, README.md. agent.py contains the state machine, nodes, rubric, memory, and routing; app.py provides the Streamlit UI. My lesson-forge has No retrieval or external fact-checking; accuracy is judged by an LLM's internal knowledge and draft coherence. I describe accuracy as internally consistent rather than grounded because there is no retrieval or external verification. Within a run, rejection_log keeps the most recent failure available for the next retry. Across runs, every failure is saved—even when a retry fixes it—because a corrected failure still provides useful learning. The router should remain a pure function: should_regenerate reads passed_all and retry_count and returns pass, retry, or max_retries_reached, while evaluation owns state mutation and bookkeeping. This keeps routing free of side effects and avoids depending on implementation-specific behavior. My setup requires Python 3.10+, Ollama running locally, and the pulled qwen3.5:9b and deepseek-r1:8b models. I create and activate a virtual environment, install requirements.txt, then run streamlit run app.py for the UI or python agent.py for a headless run that prints the final draft, evaluation results, and rejection history. The UI displays cross-run memory in the sidebar and rubric checks and rejection history in the main panel. The README's demo is illustrative, not a measured benchmark: it describes a first lesson draft on Introduction to RAG, a detected or injected failure, regeneration using the exact failure reason, and a passing lesson with the rejection log and persistent memory surfaced. No pass-rate, latency, or lesson-quality improvement metrics are reported. The fixed retry cap guarantees termination but can leave a difficult topic as an imperfect best-effort lesson; the flat failure-reason list could eventually benefit from consolidation. My ai-appointment-booking-agent repository is described as: AI-powered appointment booking assistant built with LangGraph, Ollama, SQLite, and Google Calendar integration. My ai-appointment-booking-agent repository has 3 stars; started 2026-05; last updated 2026-05. My booking workflow uses route_intent() is a deterministic router with no LLM. The README describes the default model configuration as all nodes defaulting to a single model, `qwen3.5:9b`, for demo stability and lower-resource environments. - My booking assistant offers Consultation (30 min), Demo Call (45 min), and Support Session (60 min). The booking assistant rejects bookings less than 30 minutes from now and checks time conflicts across all services, not just exact matches. My booking assistant uses LLM-based yes/no detection; never assumed from context. The appointment table stores `booking_date` in YYYY-MM-DD format, `booking_time` in HH:MM (24-hour) format, and defaults `status` to "Active". My example booking conversation shows a Consultation on 2026-10-05 at 11:00. My repository README says credentials.json is listed in .gitignore and must never be committed. I built this conversational appointment-booking assistant with LangGraph, Ollama, SQLite, and Google Calendar integration. It gathers service, date, and time through chat, checks availability, asks for explicit confirmation, and then creates a database record and calendar event. The workflow has intent analysis, deterministic routing, collection of missing details, availability checking, confirmation, and booking or decline handling. Its implementation is divided among main.py for workflow and routing, tools.py for availability and integrations, database.py for the SQLModel schema and SQLite engine, prompts.py for LLM prompts, and user_interface.py for the Streamlit chat UI. The README describes a multi-model design: gemma3:12b for intent analysis, qwen3.5:9b for chat, and llama3:8b for confirmation classification. It explains that using three large local models can lead to repeated loading and unloading, latency, or freezing on consumer hardware, so the demo configuration uses one model for stability and lower resource use. The README frames this as a tradeoff favoring reliability and deployment simplicity over marginal per-task specialization, while noting that each node can be configured independently with an Ollama-compatible model. I use SQLModel with SQLite for appointment records. The documented appointment table includes an auto-incrementing ID, service_type, booking_date, booking_time, status, created_at as an ISO timestamp, and gcal_event_link. The README also describes automatic calendar events with a duration determined by the selected service, overlap checks across services, and a past-date guard that requires at least 30 minutes' notice. To run the project, the README requires Python 3.10+, a locally installed and running Ollama, and a Google Cloud service account with the Calendar API enabled. It lists Streamlit, LangGraph, langchain-core, langchain-ollama, SQLModel, google-auth, and google-api-python-client as dependencies. Its instructions include pulling gemma3:12b, qwen3.5:9b, and llama3:8b; cloning the GitHub repository; installing requirements; sharing a calendar with the service account with “Make changes to events” permission; setting CALENDAR_ID in a root .env file; running python database.py once; and launching with streamlit run user_interface.py. The documented local UI address is http://localhost:8501, and python tools.py is listed as a way to inspect the database. The README's example conversation books a Consultation for October 5th at 11am, identifies the open slot as 2026-10-05 at 11:00, requests confirmation, and reports that the booking was added to the calendar. Its happy-path test flow greets the user, captures a Demo Call and “Next Monday at 3pm,” and books after “Yes, go ahead.” Suggested edge-case checks include attempting the same slot twice, declining at confirmation, requesting a time 10 minutes away, asking about the weather, and changing service mid-conversation. The README provides these setup and testing instructions but does not report test outcomes or measured performance. I keep credentials.json and .env out of source control; the README says credentials must never be committed and that API keys are not hardcoded. It describes the service account as having access only to calendars explicitly shared with it. The documentation says credentials are loaded via environment variables while also instructing users to place the service-account JSON key at the project root as credentials.json, without detailing how that key is loaded. It also clones ai-appointment-booking-agent but changes into ai-booking-assistant, without explaining the directory-name difference. The README does not specify a timezone policy or describe cancellation, post-booking modification, end-user authentication, or deployment beyond local use. It also gives no measured latency, resource usage, comparison of single-model and multi-model operation, or reported results showing whether the booking flow and integrations have been tested successfully. My intent analyzer extracts the service, date, and time. My intent analyzer retains state across turns. My appointment-booking assistant has a chat interface with session memory. My Study Buddy profile description reads: An intelligent study companion using Retrieval Augmented Generation (RAG). Upload your lesson documents (PDF, TXT, DOCX) and get instant answers based ONLY on your materials. Features dual-index search, conversation memory, and support for both OpenAI and local Ollama. My ClauseIQ repository is described as: Local RAG pipeline that extracts legal clauses, summarizes contracts, and answers natural-language questions across a document library — 100% offline via Ollama + FAISS, zero API keys. My local-llm-performance-predictor repository is described as: Predicts RAM, VRAM, and inference latency for local Ollama models before you run them — trained on 288 real benchmarks across 8 LLMs using scikit-learn + FastAPI + Streamlit. My mcp-agentic-rag repository is described as: A production-ready, decoupled Agentic RAG architecture powered by the Model Context Protocol (MCP), LangGraph, and FastAPI. My agentic-rag-system repository is described as: A multi-node LangGraph agentic RAG system with retrieval routing, ambiguity-aware clarification, tool orchestration, evaluator-based grounding, and structured refusal handling. I built `agentic-rag-system` as a multi-node LangGraph research-paper assistant. It rewrites queries before routing, can pause for clarification, and evaluates evidence before generating a grounded answer or structured refusal. Its corpus contains 50 arXiv cs.AI papers; the repository is https://github.com/Katta-Nitish/agentic-rag-system. My agentic RAG system uses five routing actions: `RETRIEVE`, `CLARIFY`, `TOOL`, `REFUSE`, and `DIRECT_ANSWER`. My retrieval pipeline uses FAISS top-20 search followed by cross-encoder reranking to top-6; in the reported evaluation, this achieved 100% (10/10), compared with 60% (6/10) for direct FAISS top-6 retrieval without reranking. My system uses LangGraph's `InMemorySaver` to preserve full graph state across turns within a session, keyed by a unique conversation `thread_id` generated at session start via `time.time()`. I keep the system episodic and session-scoped: it does not implement semantic summaries or cross-session persistent memory. I would add summarization to compress older turns while preserving useful context and managing the context window. The query rewriter can use conversation history to retain established references when unambiguous, while the analyzer can judge whether ambiguity is new or already addressed. My system's available tools include live arXiv API search, deterministic calculation using `numexpr` and `ne.evaluate()`, and Python execution through `PythonREPL` from `langchain-experimental`. My evaluator checks evidence sufficiency before generation and can return typed failure reasons including `INSUFFICIENT_CONTEXT`, `LOW_RELEVANCE`, and `CONTRADICTORY_CONTEXT`; the refusal node uses the failure reason to return a structured refusal. I keep the system prompts as named constants in `prompts.py`, separate from logic so each agent's behavior can be audited and iterated without changing `assignment.py`. My README estimates setup at ~10 minutes, excluding model downloads. ``` git clone https://github.com/Katta-Nitish/agentic-rag-system.git cd agentic-rag-system pip install -r requirements.txt ollama pull qwen3:4b ollama pull gemma3:12b ollama pull llama3:8b ollama pull qwen3.5:9b ollama pull nomic-embed-text python file.py python vector.py streamlit run assignment.py ``` For Docker, I build with `docker build -t agentic-rag .` and run with `docker run -p 8501:8501 agentic-rag`. Ollama must be running on the host at `host.docker.internal:11434`, and all five models must be pulled before starting the container. I test tools with `pytest test_tools.py` and run the routing evaluation with `python eval.py`. The tool tests cover valid calculation, division by zero, syntax errors, successful PythonREPL execution, and `NameError` propagation. The evaluation covers all five routing decisions across 10 cases and writes `evaluation_results.json`. My self-improving-rag-agent repository is described as: A LangGraph RAG pipeline that evaluates its own responses with RAGAS and automatically retries with adaptive retrieval — fully local via Ollama. My greenpack-epr-compliance-api repository is described as: AI-powered EPR compliance backend for plastic packaging producers — FastAPI service with LLM-generated reconciliation summaries and a RAG pipeline for EPR policy Q&A. Built with Ollama + FAISS. My internet-researcher-agent repository is described as: AI-powered research agent that searches the web, retrieves semantic context, and generates structured reports — with built-in chat. Supports local (Ollama) and cloud (OpenAI) models. My grid07-cognitive-agent repository is described as: An autonomous social media agent built with LangGraph and local LLMs, featuring vector-based persona routing, tool-augmented post generation, and robust RAG prompt injection defense. My Agent-Registry-API repository is described as: A lightweight FastAPI service for registering, discovering, and tracking usage of AI agents. My genotek-ai-evaluator repository is described as: A ruthless, AI-powered technical screening tool that separates real engineers from buzzword merchants — locally, privately, and brutally fast. My Amazon luggage dashboard repository is described as: An AI-powered competitive intelligence dashboard for luggage brands on Amazon India. Built for the Moonshot AI Agent Internship Assignment. My Binance futures bot repository is described as: A lightweight CLI trading bot for placing Market and Limit orders on the Binance Futures Testnet (USDT-M). Built with Python and Typer. My Roast Bot repository is described as: Why be nice when you can be witty? A Streamlit app that uses Google Gemini to roast your statements with zero mercy. 🔥. My Practice-projects repository says: All the projects done by me during my practice sessions will be posted here 🌱. My skills-communicate-using-markdown and skills-introduction-to-github repositories are each described as: My clone repository. My profile lists the following entries with limited descriptions: rider-payout-dispute-desk: Python. tutorial_builder: My profile shows 1 merged. for codedex-io/github-chapter-2-contributions; the contribution text is “Added my name and date”. My profile also lists Katta-Nitish.github.io, Katta-Nitish, and other repositories spanning agentic systems, RAG, local-model tools, dashboards, and practice projects. Repository descriptions do not provide further implementation, usage, deployment, benchmark-result, or adoption details. I am currently seeking an AI Engineering Internship. My engineering philosophy is: Every claim should trace back to actual code. I am exploring deeper LangGraph extensions and agent memory architectures. For project architecture diagrams and actual numbers, I point readers to each project's README. My GitHub repository has 2 stars; started 2026-06; last updated 2026-06. I am a third-year CS (AI & ML) student; began building after a Streamlit app that roasts text messages. I design multi-agent systems that route, reason, and self-correct. Most projects run entirely on local models with no API keys or rate limits, using Ollama on my own machine. My focus areas are Agentic Systems; RAG Pipelines; LLM Orchestration. My listed stack is LangGraph; FAISS; Ollama; FastAPI; PyTorch. My Agentic RAG System uses a 5-action LangGraph router; 4 specialized local LLMs; FAISS; cross-encoder reranking. My Agentic RAG System improved routing accuracy from 60% to 100% through iterative tuning. My Self-Improving RAG Agent uses a 4-node StateGraph that evaluates retrieval quality with RAGAS and iterates until good enough. My Internet Researcher Agent uses a 3-node pipeline; Tavily live-web search; ChromaDB indexing; structured research reports with citations. My Local Job-Hunting Agent is a fully local FastAPI + React app; resume reading, voice cloning, job discovery, cold-email drafting, outreach tracking; zero paid APIs. The additional stack for my Local Job-Hunting Agent is SQLite; Ollama. My Study Buddy accepts PDF/TXT/DOCX lecture notes; dual-index retrieval; answers grounded only in uploaded materials to avoid hallucinated textbook facts. My Roast Bot is a Streamlit app powered by Gemini; first real project and most fun one. I rebuilt my resume from a 51 → 72 ATS score; fixing things that mattered instead of stuffing keywords. My listed credentials are IIT Madras (NPTEL Data Science); AWS Cloud Architecting; Cisco Cybersecurity. I build projects across agentic workflows, retrieval-augmented generation, conversational AI, and research tools. My projects include local and containerized deployments, evaluation and retrieval feedback, and assistants designed around specific user materials or tasks. My project is Dockerized Agentic RAG Architecture, May 2026, May 2026, Developed a containerized multi-node state machine using LangGraph to dynamically route user queries to the appropriate execution paths based on intent. The Dockerized Agentic RAG Architecture integrated a PythonREPL tool to allow the agent to autonomously write, execute, and return results for complex programmatic tasks (e.g., multi-dimensional matrix operations) instead of relying on standard LLM reasoning. The Dockerized Agentic RAG Architecture engineered a "Human-in-the-Loop" safeguard using LangGraph interrupts to automatically pause execution and request user clarification when ambiguous queries are detected. The Dockerized Agentic RAG Architecture built a local cross-encoder reranking pipeline over a custom arXiv document corpus and containerized the entire application with Docker for seamless deployment alongside local Ollama models (DeepSeek/Gemma). My project is Self-Improving RAG Agent with Automated Evaluation, Apr 2026, Apr 2026. The Self-Improving RAG Agent implemented an adaptive retrieval feedback loop that automatically expands vector search parameters (k-value) if the initial Answer Relevancy score falls below a predetermined safety threshold. The Self-Improving RAG Agent achieved a quantitative +73% improvement in Answer Relevancy (from 0.49 to 0.85) on complex queries by forcing the agent to self-correct during edge-case failures. The Self-Improving RAG Agent built the local vector store using FAISS and deployed the interactive evaluation dashboard using Streamlit. My Internet-Researcher-Agent is an AI-powered research agent that searches the web, understands context, and delivers structured reports — then lets you chat with the findings. My Roast Bot — Context-Aware Conversational AI is an engineered persona-driven chatbot using a GenAI API that analyzes user-provided profiles and generates witty, personalized roast responses. I designed a multi-layered prompt engineering system to control tone, safety constraints, and persona consistency, which was successfully validated across 50+ manual test cases with zero safety violations. I optimized the API call structure and response streaming to reduce perceived latency, achieving a noticeably smoother chat experience on a 512MB RAM Streamlit Cloud deployment. My Study Buddy — Agentic AI Tutoring Assistant is an intelligent study companion using Retrieval Augmented Generation (RAG). Upload your lesson documents (PDF, TXT, DOCX) and get instant answers based ONLY on your materials. Fully open source. Study Buddy features dual-index search, conversation memory, and support for both OpenAI and local Ollama; it supports PDF, TXT, and DOCX lesson documents. --- From KATTA NITISH GOUD's second brain at agentsocialx.com/nitish