\documentclass[12pt]{article} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{lmodern} \usepackage[a4paper,margin=1in]{geometry} \usepackage{longtable} \usepackage{booktabs} \usepackage{array} \usepackage{graphicx} \usepackage{float} \usepackage{ulem} \usepackage{calc} \usepackage[hidelinks]{hyperref} \usepackage{tabularx} \usepackage{xurl} % Report-style paragraph spacing \setlength{\parindent}{0pt} \setlength{\parskip}{0.7em} \begin{document} \title{An Agentic Approach to Role-Specific Trainers (Dynavera)} \author{Viswamedha Nalabotu\\2402117\\vxn217@student.bham.ac.uk\\University of Birmingham} \date{} \maketitle \section*{AI Use Declaration}\label{ai-use-declaration} In accordance with the University's academic integrity guidelines, I declare that Large Language Models (LLMs) and Chat Completion APIs were used in the preparation of this report and for assisting with coding the project. \textbf{Scope of AI Usage.} AI was used to assist in the structural organization, grammatical refinement, and syntactic formatting of the prose and technical descriptions. \textbf{Prototyping \& Feasibility Research.} LLMs were employed during the R\&D phase to \textbf{scope technical requirements and perform feasibility checks}. This included generating "throwaway" boilerplate code to test the viability of specific architectural branches (e.g., comparing custom fine tuning against LangGraph API) and validating the compatibility of the Model Context Protocol (MCP) with the existing Django environment. \textbf{Originality of Content.} All core architectural concepts, the design of the \emph{Dynavera} system, the "Distributed Agentic Pattern" logic, and the specific implementation strategies are my own original works. \textbf{Fact-Checking and References.} Any external information or technical claims used to ground the AI\textquotesingle s output have been verified against the primary sources listed in the References section. \textbf{Human Oversight.} I have critically reviewed, edited, and refined all AI-generated suggestions to ensure technical accuracy and alignment with the project's objectives. \section*{Inspector Access Details}\label{inspector-access-details} The public deployment for evaluation is available at: \url{https://fyp.viswamedha.com} Use the following credentials for testing: \begin{center} \begin{tabular}{p{0.22\linewidth} p{0.46\linewidth} p{0.22\linewidth}} \toprule Role & Email & Password \\ \midrule Admin & admin@example.com & admin \\ Manager & haleisaac@example.com & password \\ User & j.thompson@example.com & password \\ \bottomrule \end{tabular} \end{center} \textit{Note: I will try to keep the public website available, but the GPU node runs on my home PC and may occasionally go offline. For reliable testing, I recommend running the system locally on a machine with a CUDA-enabled GPU.} Manager registration code (for signup): \texttt{MANAGER2026} \section{Introduction}\label{introduction} \subsection{Background: The Corporate Onboarding Problem}\label{background-the-corporate-onboarding-problem} When a startup or enterprise hires a new team member, they enter a critical induction period requiring exposure to internal tools, organizational context, and role-specific responsibilities. Traditionally, this process is led by a senior colleague who acts as the primary trainer and point of contact. While effective, this model introduces a significant \emph{productivity tax}: every hour spent training represents an hour of lost expert-level output. This issue is amplified in startups, where teams are small, budgets are constrained, and hiring decisions must be highly selective. As a result, training often becomes inconsistent, slow, and difficult to scale. \subsection{Motivation}\label{motivation} The motivation behind Dynavera is to reduce this productivity loss by automating and enhancing role-specific training through AI. By replacing static documentation and repeated human-led instruction with intelligent agents, organizations can reduce reliance on ad-hoc mentorship while preserving access to expert knowledge. I observed this firsthand during my industrial placement at Siemens DISW, where onboarding and training five incoming interns required a significant investment of time in meetings, planning, and repeated knowledge transfer to ensure a graceful handover. Despite careful preparation, much of the training depended on individual availability and tacit understanding, temporarily diverting effort away from feature work. This experience highlighted how difficult it is to scale onboarding without imposing a sustained productivity cost on senior contributors. By addressing this gap, Dynavera enables organizations to: \begin{itemize} \item Scale Mentorship: Support multiple new hires simultaneously while minimising senior staff intervention \item Standardize Quality: Ensure consistent depth, structure, and assessment across all onboarding experiences \item Reduce Time-to-Productivity (TTP): Provide 24/7 access to contextual, role-aware support through AI agents \end{itemize} Dynavera is designed as a proof-of-concept platform that transforms onboarding into a dynamic, adaptive, and reusable training workflow. \section{Project Background \& Context}\label{project-background-context} \subsection{The training bottleneck}\label{the-training-bottleneck} Modern organizations face persistent challenges when standardizing and scaling role-specific training: \begin{itemize} \item Skill-Preloading Bias: Limited training capacity forces organizations to favor candidates with prior experience in specific tools or technology stacks, even when strong general aptitude or learning ability may be sufficient. \item Restricted Talent Pool: By prioritizing immediate productivity over trainability, organizations reduce access to diverse candidates who could otherwise ramp up quickly with adequate onboarding support. \item Inflated Hiring Requirements: Role specifications often expand to include non-essential tooling experience as a substitute for structured training, increasing time-to-hire and cost. \item Uneven Knowledge Transfer: New hires are expected to ``already know'' systems and workflows, resulting in fragmented understanding and slower integration into team-specific practices. \end{itemize} These constraints do more than just increase immediate onboarding friction; their accumulation creates a compounding "productivity tax" that stifles organizational growth. When left unaddressed, the aftermath manifests in three critical areas: \begin{itemize} \item Institutional Fragility: Over-reliance on tribal knowledge and senior-led instruction creates single points of failure. If key mentors depart, the lack of standardized, automated training leads to a permanent loss of institutional memory and a degraded ability to upskill replacements. \item Cultural and Innovation Stagnation: By reinforcing conservative hiring through the prioritization of "plug-and-play" candidates over those with high learning agility, organizations inadvertently filter out the diverse perspectives and outsider logic that drive innovation. This results in a homogenized workforce that excels at maintaining the status quo but struggles to pivot. \item Compounded Opportunity Cost: The delay in reaching full productivity (TTP) is not a linear loss. It represents a systemic lag in project delivery and market responsiveness. For a scaling startup, the cumulative effect of several hires operating at 50\% capacity for months can be the difference between hitting a product milestone or missing a market window entirely. \end{itemize} Ultimately, these factors coalesce into a cycle of restricted scalability. The cost of adding new talent becomes so high that the organization eventually stops growing simply to avoid the sustained pain and friction of integration. \subsection{Recent advancements in agentic AI}\label{recent-advancements-in-agentic-ai} Recent advances in Large Language Models (LLMs) and multi-agent systems offer a viable solution to the onboarding bottleneck. Modern LLMs demonstrate strong capabilities in natural language understanding, contextual reasoning, and adaptive response generation, making them well-suited for interactive, role-aware training scenarios. Unlike static documentation, LLM-driven systems can dynamically tailor explanations and guidance based on a user's specific role and prior knowledge. Rather than relying on a monolithic chatbot, Dynavera employs a collection of specialized, collaborating agents. This modular approach provides several distinct advantages: \begin{itemize} \item Efficient Resource Allocation: By distributing responsibilities across agents, the system maintains clearer reasoning boundaries. This architecture reduces the computational overhead and "token bloat" often associated with all-in-one prompts, leading to faster response times and more efficient use of infrastructure resources. \item Targeted Maintainability and Explainability: Decoupled agents allow for the optimization of specific components, such as the assessment or knowledge retrieval modules, without requiring a total system redesign. Because each agent has a narrow scope, the system provides more transparent reasoning for its guidance, making it easier for human supervisors to audit the AI\textquotesingle s logic. \end{itemize} Furthermore, agent collaboration enables training workflows that more closely resemble human mentorship, where guidance and evaluation occur in parallel. This architecture allows Dynavera to serve not only the trainee but also the broader organizational stakeholders, including HR departments and team leads. By capturing granular interaction data, the system creates a comprehensive oversight landscape that includes: \begin{itemize} \item Integral Progress Analytics: Automated reports and charts track trainee milestones in real-time, allowing HR to identify exactly where a new hire is thriving or stalling without manual check-ins. \item Continuous Curriculum Optimization: The system can flag specific training modules that frequently cause friction or confusion, suggesting content updates or sections that require a human-led review. \item Strategic Escalation: By identifying complex, high-friction topics that exceed the AI\textquotesingle s current scope, Dynavera can pinpoint the exact moments requiring senior staff intervention. This ensures that expert time is reserved for nuanced, high-value coaching rather than repetitive technical basics. \end{itemize} This dual-purpose design ensures that while Dynavera scales the trainee experience, it simultaneously provides the data-driven visibility and administrative control required for long-term organizational growth. \subsection{Theoretical Foundations}\label{theoretical-foundations} Dynavera is grounded in two complementary system design paradigms that enable scalable, context-aware onboarding: \begin{itemize} \item Multi-Agent Systems (MAS): A collection of specialized AI agents collaborate through structured communication to achieve complex objectives that exceed the capability of a single monolithic model. Within Dynavera, this enables separation of instructional delivery, contextual reasoning, knowledge retrieval, and evaluation, improving modularity, explainability, and system adaptability. \item Retrieval-Augmented Generation (RAG): Training responses are grounded in authoritative, organization-specific documentation rather than relying solely on a model's parametric knowledge. This ensures factual accuracy, contextual relevance, and rapid adaptability as organizational knowledge evolves. \end{itemize} To address data privacy and deployment constraints, Dynavera prioritizes local inference using quantized open-weight models (e.g., Llama 3 in GGUF format). This design choice reduces dependency on external cloud APIs, supports offline or air-gapped environments, and aligns with enterprise privacy requirements while maintaining acceptable inference performance. \subsection{Positioning Against Alternative Approaches}\label{positioning-against-alternative-approaches} Dynavera was designed against three practical alternatives. First, human-only onboarding preserves expert nuance but does not scale well and introduces recurring opportunity cost for senior staff. Second, static LMS/document-first onboarding scales distribution but provides limited adaptivity, weak context grounding during Q\&A, and little operational traceability beyond completion events. Third, a single general chatbot can improve interactivity, but it typically blends curriculum, retrieval, assessment, and monitoring concerns into one prompt surface, making governance and iterative improvement harder. The Dynavera architecture chooses a middle path: specialized agent roles within one orchestrated runtime, retrieval-grounded generation, and persisted session state for reviewability. This trade-off accepts added system complexity in exchange for improved modularity, clearer responsibility boundaries, and stronger alignment between training delivery and management oversight. \subsection{Learning Origins}\label{learning-origins} The design and implementation of Dynavera synthesize concepts developed through university coursework and independent technical exploration: \begin{itemize} \item Software Systems Architecture (CS301): Application of decoupled service architectures using Django and Vue.js, alongside the use of sidecar-style components to isolate model execution and agent coordination. \item Machine Learning \& NLP: Practical experimentation with LoRA fine-tuning and low-bit quantization (e.g., 4-bit inference via bitsandbytes) to optimize model performance under local hardware constraints. \item Full-Stack Development: Construction of production-oriented APIs using Django REST Framework and responsive front-end interfaces with Vue 3, enabling real-world interaction with agent-driven workflows. \end{itemize} Together, these learning sources informed both the architectural decisions and implementation strategies underpinning Dynavera. \section{Specification}\label{specification} \subsection{System Overview}\label{system-overview} Dynavera is implemented as a Distributed Agentic System, physically decoupling the administrative and state management logic from the high-latency inference workloads. As illustrated in Figure 1, the architecture is split into two primary environments: \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item The Application Layer: A CPU-optimized environment running Django 5.x. This layer handles user authentication, training state, and the MCP Server, which acts as a standardized "data bridge" for the AI. \item The Inference Layer: A dedicated NVIDIA-based node running a FastAPI inference engine. This layer handles Large Language Model (LLM) execution, semantic chunking, and embedding generation. \end{enumerate} The "brain" of the system is the Orchestrator, which lives within a Django Channels WebSocket consumer. It maintains a persistent, full-duplex connection between the trainee and the distributed AI components, ensuring real-time interactivity. \includegraphics[width=\textwidth,keepaspectratio]{diagrams/system-architecture.png} Figure 1: High-level system architecture of Dynavera, illustrating the interaction between the user, orchestrator, inference layer and the database. \subsection{Technology stack}\label{technology-stack} Dynavera is implemented as a modern full-stack application, with the components presented in Table 1. \begin{table}[H] \centering \begin{tabularx}{\linewidth}{p{0.22\linewidth} p{0.16\linewidth} X} \toprule Component & Technology & Rationale \\ \midrule Frontend/UI & Vue 3 w/ TS & Typesafe, reactive UI enabling rapid iteration and maintainable component design \\ State Management & Pinia & Centralized, predictable state management for real-time training progress tracking \\ Backend/API & Django REST & Secure, mature framework supporting rapid development and scalable API design, informed by prior production experience \\ Database & PostgreSQL & Reliable, production-grade relational database for organizational and user data \\ Vector Store & PgVector & Efficient similarity search over embedded training documentation via PostgreSQL \\ MCP Router & Python & Provides a standardized interface for agents to query data using Model Context Protocol. \\ \bottomrule \end{tabularx} \caption{Architectural components of the Dynavera platform, including frontend, backend, and AI integration technologies.} \end{table} This stack was selected to balance modularity, rapid iteration, and production readiness. A decoupled frontend-backend architecture lets the UI and API evolve independently, while PostgreSQL with pgvector provides one ACID-compliant store for both relational state and vector retrieval. To preserve performance and control, orchestration is implemented in native Python rather than heavier framework abstractions such as LangChain. This keeps agent state handling explicit, reduces latency in the WebSocket loop, and supports local execution, data ownership, and architectural transparency during early-stage development. \subsection{Design Philosophy: The Distributed Agentic Pattern}\label{design-philosophy-the-distributed-agentic-pattern} Dynavera leverages the Model Context Protocol (MCP) to solve the "context gap" in corporate onboarding. Rather than providing the LLM with a static, bloated prompt, the system utilizes a Sidecar Tooling approach: \begin{itemize} \item The MCP Server as a Translator: Integrated directly into the Django ecosystem, the MCP layer exposes specific "Tools" (e.g., search\_knowledge, get\_user\_progress) to the AI. This allows the model to query the organization\textquotesingle s private data safely and efficiently. \item The Streaming Orchestration Loop: Unlike traditional request-response cycles, the system uses an asynchronous loop. The Orchestrator manages the "triangle of communication": \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item Receives user input via WebSockets. \item Prompts the GPU Layer for a decision. \item If the AI requests data, the Orchestrator calls the MCP Tool internally. \item Streams the final result back to the user with minimal latency. \end{enumerate} \end{itemize} This separation ensures that the core application remains responsive while the heavy lifting of "thinking" and "embedding" happens on specialized hardware. It transforms the onboarding experience from a static tutorial into a Streaming Agentic System that adapts to the trainee in real-time. \section{Implementation Overview}\label{implementation-overview} \subsection{Backend Realisation}\label{backend-realisation} This section describes how the architecture in Chapter 3 is implemented in the current Dynavera codebase. The backend is organized into three primary Django app domains: accounts (users, organizations, roles, membership), knowledge (training files, ingestion, chunk/embedding persistence), and onboarding (sessions, orchestration, generated flows, interaction logs). This separation keeps responsibility boundaries explicit while allowing shared infrastructure (authentication, ORM, API routing, and permissions) to remain centralized. The API surface is intentionally split by interaction pattern. Standard management operations are handled through Django REST Framework (for example role membership, training file upload, and session endpoints), while orchestration-time interaction uses Django Channels over WebSockets at /ws/onboarding/\textless session\_uuid\textgreater/. This allows the platform to handle both CRUD-style workflows and long-running, stateful agent interactions without forcing either pattern into the other. For ingestion, the backend follows an asynchronous execution path: uploaded files are stored as TrainingFile records, and a post-save trigger enqueues background processing through Celery (Redis broker). This prevents heavy preprocessing from blocking request-response latency on the main web process. Persistence is model-driven and traceable. Session state, progress, generated onboarding structures, and interaction events are stored in Django models, enabling deterministic recovery and auditability of the onboarding lifecycle. In implementation terms, the backend is less a single monolith and more a coordinated runtime: REST for management, WebSockets for orchestration, Celery for heavy async jobs, and PostgreSQL/pgvector as a unified data plane. \subsection{Data Flow}\label{data-flow} \subsubsection{Knowledge Ingestion Workflow}\label{knowledge-ingestion-workflow} Figure 2 shows the ingestion data flow between the User/UI, Django REST API, Celery worker, PostgreSQL/pgvector database, and GPU endpoint. \includegraphics[width=5.75521in,height=5.14354in]{diagrams/embedding-data-flow.png} Figure 2: Knowledge ingestion data flow diagram, illustrating the interaction between the user, REST API, Celery Worker, Pgvector database \& GPU endpoint. \underline{Asynchronous processing with Celery (Redis broker)}\\ When a manager uploads a training file from the UI, the file is sent to the Django REST API and stored as a TrainingFile record with an initial ingesting status. A post-save hook then enqueues a Celery task via Redis, so heavy processing runs outside the request/response cycle. This keeps the web server responsive even for large documents. \underline{Semantic chunking on the GPU endpoint}\\ The Celery task extracts raw text from uploaded files (PDF/DOCX/TXT), batches long content, and calls the GPU service at /v1/semantic-chunk. The service performs sentence-level semantic breakpoint detection using embedding-distance thresholds, then returns coherent chunks with embeddings. This avoids naive fixed-size splits that can break context mid-concept. \underline{Vector storage and retrieval with pgvector}\\ Returned chunk embeddings are stored in RoleRagDocument.embedding (768 dimensions) in PostgreSQL using pgvector, linked relationally to role and source file metadata. Retrieval is performed in SQL using cosine-distance ranking and top-k selection, allowing role filtering and similarity search in one query path. \subsubsection{Agent Orchestration Workflow (Simplified)}\label{agent-orchestration-workflow-simplified} \includegraphics[width=6.15132in,height=6.00619in]{diagrams/agent-orchestration-loop.png} Figure 3: Agent orchestration data flow diagram, illustrating the interaction between the user/UI, WebSocket Consumer, MCP Router, GPU Endpoint \& Pgvector database. Figure 3 presents a simplified view of the orchestration loop. To keep the diagram readable, it collapses multiple internal components into a single orchestration path and does not show each specialist agent (for example curriculum, knowledge, assessment, and monitor agents) as separate lifelines. The orchestration layer is implemented in a Django Channels WebSocket consumer (/ws/onboarding/\textless session\_uuid\textgreater/). This keeps a persistent two-way connection between the frontend and backend so the client can receive live status events (for example thinking/tool execution/completed) without repeated polling. Once connected, the UI sends a query or action payload, and the orchestrator coordinates model inference and tool usage. The core loop is tool-aware. The orchestrator sends chat-completion requests to the inference endpoint with tool definitions attached. If the model returns a tool call, control is passed to an MCP router, which executes backend tools such as search\_knowledge and update\_progress. For knowledge retrieval, the router generates an embedding for the query via the GPU endpoint, performs cosine-distance top-k lookup against pgvector-backed role documents, and returns the retrieved context to the orchestrator. The tool result is then injected back into the message sequence before the next model call. State is persisted through session and flow models (for example onboarding session state updates and generated flow storage), while interaction events are emitted to the frontend over the same WebSocket channel. This allows the system to remain responsive and traceable while still supporting retrieval-grounded generation. Note: Per-agent branching logic and detailed phase-specific workflows are omitted to keep a simplified diagram. A more detailed diagram is available in the repository (TBM). \subsection{Agentic Runtime Structure}\label{agentic-runtime-structure} Dynavera implements a multi-agent training workflow through role-specialized configurations executed inside a shared orchestration runtime. Conceptually, the system uses four agent roles: Curriculum Agent (CA), Knowledge Agent (KA), Assessment Agent (AA), and Progress Monitor Agent (PMA). In practice, these are represented by agent configuration records and invoked by orchestration logic rather than isolated microservices, which keeps deployment complexity manageable while preserving modular behavior. The Curriculum Agent (CA) defines module order and high-level learning path. The Knowledge Agent (KA) generates grounded instructional content and relies on retrieval tools when additional context is needed. The Assessment Agent (AA) generates evaluation artifacts (for example quiz structures) to validate understanding. The Progress Monitor Agent (PMA) evaluates learner trajectory and produces concise progress-oriented feedback from session context. Together, these roles form a coordinated runtime where each stage contributes to structured onboarding output. Tool-mediated grounding is handled through the MCP router. During orchestration, model responses may include tool calls; the runtime executes approved tools (such as search\_knowledge and update\_progress), retrieves contextual evidence from pgvector-backed documents, and injects those results back into the message loop before final answer generation. This keeps generation anchored in role-specific organizational material while preserving a controlled boundary between model reasoning and data access. \subsection{Workflow Implementation}\label{workflow-implementation} The implemented training workflow follows a staged operational sequence from administrative setup to learner progression. First, administrators/managers configure role context and upload role-relevant documentation through the application interface. These documents are processed through the ingestion pipeline and converted into vectorized knowledge records linked to role scope. Next, a trainee enters a role-specific onboarding session. The frontend opens a persistent WebSocket connection to the orchestration endpoint and submits user prompts/actions as session events. The orchestrator resolves the active configuration for that role/session, runs model inference, executes retrieval tools when required, and emits structured runtime events (status/tool/completion) back to the client. During guided learning, module content generation, context retrieval, and assessment output are coordinated in sequence. The curriculum phase determines structure, the knowledge phase builds role-grounded instructional content, and the assessment phase constructs evaluative checkpoints. Final assessment grading follows a mixed strategy: multiple choice responses are deterministically compared against configured correct options, while non-multiple-choice responses are agent-graded. Per-question grading outcomes are persisted in session state for review and feedback rendering. Progress monitoring then summarizes current status using persisted session state and completed interactions. In the implemented UI path, AI monitor inference is only triggered after onboarding completion; before completion, the system presents a local progress summary. When available, monitor judgements are informed by prior final-quiz question/answer evidence and saved grading details. This keeps learning flow adaptive without abandoning traceability. Finally, workflow state is persisted throughout execution: user responses, progress markers, generated flow structures, and interaction logs are stored in backend models. This enables continuity across reconnects, supports progress review, and allows the system to advance, pause, or remediate onboarding based on recorded outcomes rather than transient in-memory state. \section{Results \& Conclusion - Draft}\label{results-conclusion---draft} \subsection{System Performance \& Evaluation}\label{system-performance-evaluation} The implementation of Dynavera successfully demonstrates the viability of a distributed agentic approach to role-specific training. By decoupling the application layer from the inference layer, the system maintained a responsive UI even during high-latency LLM reasoning phases. Key results observed during testing include: \begin{itemize} \item \textbf{Retrieval Accuracy:} The use of \textbf{semantic chunking} significantly reduced context fragmentation compared to fixed-length splitting, allowing the Knowledge Agent to maintain higher grounding accuracy during complex RAG queries. \item \textbf{Orchestration Latency:} The WebSocket-based orchestration loop provided a near-instantaneous feedback loop for "thinking" and "tool execution" states, which is critical for maintaining user engagement in an interactive learning environment. \item \textbf{Resource Efficiency:} 4-bit quantization enabled the deployment of Llama 3 on consumer-grade hardware without a perceptible loss in the agent's ability to follow the structured curriculum defined by the Curriculum Agent. \end{itemize} \subsubsection{Conclusion}\label{conclusion} Dynavera addresses the "Productivity Tax" of corporate onboarding by transforming static documentation into a dynamic, role-aware mentorship experience. By leveraging the Model Context Protocol (MCP) and a distributed architecture, the platform proves that complex AI training workflows can be delivered in a private, scalable, and operationally practical manner. While this project serves as a proof-of-concept, the modular nature of the specialist agents provides a clear path for future expansion into more nuanced, multi-modal onboarding scenarios. \begin{figure*}[b] \centering \includegraphics[width=\textwidth,height=3.2in,keepaspectratio]{diagrams/home-page.png} \caption{Home page of Dynavera.} \end{figure*} \begin{figure*}[b] \centering \includegraphics[width=\textwidth,height=3.2in,keepaspectratio]{diagrams/organization-page.png} \caption{Organization management view.} \end{figure*} \begin{figure*}[b] \centering \includegraphics[width=\textwidth,height=3.2in,keepaspectratio]{diagrams/onboarding-loading-page.png} \caption{Onboarding generation/loading state.} \end{figure*} \begin{figure*}[b] \centering \includegraphics[width=\textwidth,height=3.2in,keepaspectratio]{diagrams/onboarding-content-page.png} \caption{Onboarding content delivery view.} \end{figure*} \section{References}\label{references} \begin{itemize} \item Anthropic (2024). Model Context Protocol (MCP) Specification. Available at: \url{https://modelcontextprotocol.io} (Accessed: 9 March 2026). \item Hugging Face (2024). Introduction to Model Context Protocol (MCP). Available at: \url{https://huggingface.co/learn/mcp-course/en/unit1/key-concepts} (Accessed: 9 March 2026). \item LangChain (2024). LangGraph: Building Stateful, Multi-agent Applications with LLMs. Available at: \url{https://docs.langchain.com/oss/python/langgraph/workflows-agents} (Accessed: 9 March 2026). \item Meta AI (2024). Llama 3: Open-weight Large Language Models. Available at: \url{https://llama.meta.com/llama3/} (Accessed: 9 March 2026). \item PostgreSQL Global Development Group (2024). pgvector: Open-source vector similarity search for PostgreSQL. Available at: \url{https://github.com/pgvector/pgvector} (Accessed: 9 March 2026). \item Pinecone (2023). Retrieval Augmented Generation (RAG) and Semantic Search. Available at: \url{https://www.pinecone.io/learn/retrieval-augmented-generation/} (Accessed: 9 March 2026). \item Dettmers, T. (2023). 4-bit Quantization and Bitsandbytes for LLMs. Available at: \url{https://huggingface.co/blog/4bit-transformers-bitsandbytes} (Accessed: 9 March 2026). \item vLLM Team (2024). High-Throughput Serving with PagedAttention. Available at: \url{https://vllm.ai} (Accessed: 9 March 2026). \item Django Software Foundation (2024). Django Channels: Real-time WebSockets for Python. Available at: \url{https://channels.readthedocs.io/en/stable/} (Accessed: 9 March 2026). \item Django Software Foundation (2024). Django Documentation. Available at: \url{https://docs.djangoproject.com/} (Accessed: 9 March 2026). \item Encode OSS (2024). Django REST framework Documentation. Available at: \url{https://www.django-rest-framework.org/} (Accessed: 9 March 2026). \item Celery Project (2024). Celery Documentation. Available at: \url{https://docs.celeryq.dev/} (Accessed: 9 March 2026). \item Redis Ltd. (2024). Redis Documentation. Available at: \url{https://redis.io/docs/} (Accessed: 9 March 2026). \item FastAPI (2024). FastAPI Documentation. Available at: \url{https://fastapi.tiangolo.com/} (Accessed: 9 March 2026). \item UKPLab / SBERT (2024). Sentence-Transformers Documentation. Available at: \url{https://www.sbert.net/} (Accessed: 9 March 2026). \item Abetlen (2024). llama-cpp-python Documentation. Available at: \url{https://github.com/abetlen/llama-cpp-python} (Accessed: 9 March 2026). \item ggml-org (2024). llama.cpp Documentation. Available at: \url{https://github.com/ggml-org/llama.cpp} (Accessed: 9 March 2026). \item PyTorch Team (2024). PyTorch Documentation. Available at: \url{https://pytorch.org/docs/} (Accessed: 9 March 2026). \end{itemize} \end{document}