3f:I[364919,["/_next/static/chunks/33t46atd3n2zd.js","/_next/static/chunks/38r_rkalpuvrx.js","/_next/static/chunks/3pliqc5iq66rs.js","/_next/static/chunks/3xkm7-761u942.js","/_next/static/chunks/2hvqdza9c-59_.js","/_next/static/chunks/3e1m5dzsq4y6q.js","/_next/static/chunks/0ov62vkkchqce.js","/_next/static/chunks/3-19kflbg236j.js","/_next/static/chunks/31re9s7oba_ny.js","/_next/static/chunks/3n_o-hl59nvll.js","/_next/static/chunks/2479fir_u237n.js","/_next/static/chunks/2f6zgiqyi_1--.js","/_next/static/chunks/0wr9zr-vdsp5b.js","/_next/static/chunks/36lursfxj3go0.js","/_next/static/chunks/2p-s5uml3utj_.js","/_next/static/chunks/21n-q4x2-xe54.js","/_next/static/chunks/222d4e_n5pmv8.js","/_next/static/chunks/0iusuo7n2jfc0.js","/_next/static/chunks/406141pkuqyvy.js","/_next/static/chunks/3tbnnyggf5uf6.js","/_next/static/chunks/1733hkl5boa9f.js","/_next/static/chunks/0zl8uahwme1j2.js","/_next/static/chunks/3ciulhomhm7ip.js","/_next/static/chunks/0gdvg-4qnll4q.js","/_next/static/chunks/2latbtyywyamz.js","/_next/static/chunks/3_26gicdnc3rm.js","/_next/static/chunks/0pdq1s9h8mxp_.js","/_next/static/chunks/0l8n_cq9z7i4m.js","/_next/static/chunks/03msb5avskn3d.js"],"default"] 40:I[680993,["/_next/static/chunks/33t46atd3n2zd.js","/_next/static/chunks/38r_rkalpuvrx.js","/_next/static/chunks/3pliqc5iq66rs.js","/_next/static/chunks/3xkm7-761u942.js","/_next/static/chunks/2hvqdza9c-59_.js","/_next/static/chunks/3e1m5dzsq4y6q.js","/_next/static/chunks/0ov62vkkchqce.js","/_next/static/chunks/3-19kflbg236j.js","/_next/static/chunks/31re9s7oba_ny.js","/_next/static/chunks/3n_o-hl59nvll.js","/_next/static/chunks/2479fir_u237n.js","/_next/static/chunks/2f6zgiqyi_1--.js","/_next/static/chunks/0wr9zr-vdsp5b.js","/_next/static/chunks/36lursfxj3go0.js","/_next/static/chunks/2p-s5uml3utj_.js","/_next/static/chunks/21n-q4x2-xe54.js","/_next/static/chunks/222d4e_n5pmv8.js","/_next/static/chunks/0iusuo7n2jfc0.js","/_next/static/chunks/406141pkuqyvy.js","/_next/static/chunks/3tbnnyggf5uf6.js","/_next/static/chunks/1733hkl5boa9f.js","/_next/static/chunks/0zl8uahwme1j2.js","/_next/static/chunks/3ciulhomhm7ip.js","/_next/static/chunks/0gdvg-4qnll4q.js","/_next/static/chunks/2latbtyywyamz.js","/_next/static/chunks/3_26gicdnc3rm.js","/_next/static/chunks/0pdq1s9h8mxp_.js","/_next/static/chunks/0l8n_cq9z7i4m.js","/_next/static/chunks/03msb5avskn3d.js"],"default"] 41:I[164222,["/_next/static/chunks/33t46atd3n2zd.js","/_next/static/chunks/38r_rkalpuvrx.js","/_next/static/chunks/3pliqc5iq66rs.js","/_next/static/chunks/3xkm7-761u942.js","/_next/static/chunks/2hvqdza9c-59_.js","/_next/static/chunks/3e1m5dzsq4y6q.js","/_next/static/chunks/0ov62vkkchqce.js","/_next/static/chunks/3-19kflbg236j.js","/_next/static/chunks/31re9s7oba_ny.js","/_next/static/chunks/3n_o-hl59nvll.js","/_next/static/chunks/2479fir_u237n.js","/_next/static/chunks/2f6zgiqyi_1--.js","/_next/static/chunks/0wr9zr-vdsp5b.js","/_next/static/chunks/36lursfxj3go0.js","/_next/static/chunks/2p-s5uml3utj_.js","/_next/static/chunks/21n-q4x2-xe54.js","/_next/static/chunks/222d4e_n5pmv8.js","/_next/static/chunks/0iusuo7n2jfc0.js","/_next/static/chunks/406141pkuqyvy.js","/_next/static/chunks/3tbnnyggf5uf6.js","/_next/static/chunks/1733hkl5boa9f.js","/_next/static/chunks/0zl8uahwme1j2.js","/_next/static/chunks/3ciulhomhm7ip.js","/_next/static/chunks/0gdvg-4qnll4q.js","/_next/static/chunks/2latbtyywyamz.js","/_next/static/chunks/3_26gicdnc3rm.js","/_next/static/chunks/0pdq1s9h8mxp_.js","/_next/static/chunks/0l8n_cq9z7i4m.js","/_next/static/chunks/03msb5avskn3d.js"],"default"] 42:I[443565,["/_next/static/chunks/33t46atd3n2zd.js","/_next/static/chunks/38r_rkalpuvrx.js","/_next/static/chunks/3pliqc5iq66rs.js","/_next/static/chunks/3xkm7-761u942.js","/_next/static/chunks/2hvqdza9c-59_.js","/_next/static/chunks/3e1m5dzsq4y6q.js","/_next/static/chunks/0ov62vkkchqce.js","/_next/static/chunks/3-19kflbg236j.js","/_next/static/chunks/31re9s7oba_ny.js","/_next/static/chunks/3n_o-hl59nvll.js","/_next/static/chunks/2479fir_u237n.js","/_next/static/chunks/2f6zgiqyi_1--.js","/_next/static/chunks/0wr9zr-vdsp5b.js","/_next/static/chunks/36lursfxj3go0.js","/_next/static/chunks/2p-s5uml3utj_.js","/_next/static/chunks/21n-q4x2-xe54.js","/_next/static/chunks/222d4e_n5pmv8.js","/_next/static/chunks/0iusuo7n2jfc0.js","/_next/static/chunks/406141pkuqyvy.js","/_next/static/chunks/3tbnnyggf5uf6.js","/_next/static/chunks/1733hkl5boa9f.js","/_next/static/chunks/0zl8uahwme1j2.js","/_next/static/chunks/3ciulhomhm7ip.js","/_next/static/chunks/0gdvg-4qnll4q.js","/_next/static/chunks/2latbtyywyamz.js","/_next/static/chunks/3_26gicdnc3rm.js","/_next/static/chunks/0pdq1s9h8mxp_.js","/_next/static/chunks/0l8n_cq9z7i4m.js","/_next/static/chunks/03msb5avskn3d.js"],"default"] 43:I[822536,["/_next/static/chunks/33t46atd3n2zd.js","/_next/static/chunks/38r_rkalpuvrx.js","/_next/static/chunks/3pliqc5iq66rs.js","/_next/static/chunks/3xkm7-761u942.js","/_next/static/chunks/2hvqdza9c-59_.js","/_next/static/chunks/3e1m5dzsq4y6q.js","/_next/static/chunks/0ov62vkkchqce.js","/_next/static/chunks/3-19kflbg236j.js","/_next/static/chunks/31re9s7oba_ny.js","/_next/static/chunks/3n_o-hl59nvll.js","/_next/static/chunks/2479fir_u237n.js","/_next/static/chunks/2f6zgiqyi_1--.js","/_next/static/chunks/0wr9zr-vdsp5b.js","/_next/static/chunks/36lursfxj3go0.js","/_next/static/chunks/2p-s5uml3utj_.js","/_next/static/chunks/21n-q4x2-xe54.js","/_next/static/chunks/222d4e_n5pmv8.js","/_next/static/chunks/0iusuo7n2jfc0.js","/_next/static/chunks/406141pkuqyvy.js","/_next/static/chunks/3tbnnyggf5uf6.js","/_next/static/chunks/1733hkl5boa9f.js","/_next/static/chunks/0zl8uahwme1j2.js","/_next/static/chunks/3ciulhomhm7ip.js","/_next/static/chunks/0gdvg-4qnll4q.js","/_next/static/chunks/2latbtyywyamz.js","/_next/static/chunks/3_26gicdnc3rm.js","/_next/static/chunks/0pdq1s9h8mxp_.js","/_next/static/chunks/0l8n_cq9z7i4m.js","/_next/static/chunks/03msb5avskn3d.js"],"default"] 3d:["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"NewsArticle\",\"headline\":\"Mastering AI Agents\",\"image\":[\"https://app-cdn.readytensor.ai/programs/mvPXwlXz/files/3GuThgwrXT4sk2pMDdtbb/aaidc-cert2-program-hero.jpeg?versionId=PYufKxV4RWYvQEWDASO3g_oVA6MYJ4JW&Expires=1788926993&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=SuQ499Mn50GYKQEkxIbi8XIrA3FcGa4rp0-lm6jCrj-LT-9~hh4puoj0Wx4SXOzQswDcBCPffF3ldYAYwxI3iHjwmr0WQInrx8q9eC9qMbo5hYpzVC5jKtyINZQBYnhH7F6~nTzrSjkN5ArM3q9nFHlIiEACFrPJp7DXqcNfcffdsKQeabo~EIRbBzsj9q8NWfzdWcKT6snQQ1L0bmdT-Mdoa-JQk8Cb5UpFld6PjfTrpIlQBjRCQgVXOW-~9CPeomYiWI7xjiCeveeMgC60uUbtvMUUuBCuvnWs3SDDZeFyG7gwUek5B-R8FnajYwDjMGXZsG3f6qVDlRojJys9Tg__\"],\"author\":[{\"@type\":\"Person\",\"name\":\"Ready Tensor\",\"url\":\"https://app.readytensor.ai/users/ready-tensor\"}]}"}}] 44:T3eb9,## #TL;DR *Onboarding a new API normally means hours of manual work: reading docs, mapping endpoints, figuring out auth, hand-writing a client SDK, and hand-writing the guide that explains it, repeated almost identically for every integration. Agent-Powered API Onboarding automates that end-to-end: give it a documentation URL, and a pipeline of specialized agents researches the API's real surface, builds a dependency-ordered execution plan, dry-run tests it against the live API, generates a syntax-validated Python SDK, and writes a full integration guide, then reviews everything and returns a PASS/FAIL verdict with every artifact attached. Validated against the live Stripe API: 58 endpoints extracted, a 64-task plan executed with 0 failures, and a final PASS, all in a single run.* ![Screenshot_9-8-2026_22213_integrationos.streamlit.app.jpeg](Screenshot_9-8-2026_22213_integrationos.streamlit.app.jpeg) ## Abstract In an ecosystem where every product now exposes an API but few ship documentation good enough to build against quickly, developers still spend hours doing the same manual work on every integration: reading docs, mapping endpoints, figuring out auth, hand-writing a client, and hand-writing the guide that explains it all. Traditional approaches leave this entirely to the developer or lean on a single monolithic LLM call to "summarize the docs," which breaks down on anything beyond a handful of endpoints and produces unverified, often unusable output. Agent-Powered API Onboarding (https://integrationos.streamlit.app) is a multi-agent pipeline that automates this workflow end-to-end. Given nothing but a documentation URL, it researches the API's surface, builds a dependency-ordered execution plan, dispatches that plan to specialized worker agents that dry-run test the live API, generate a working SDK, and write a full integration guide — then reviews the results and reports a pass/fail verdict with every artifact attached. This system leverages a collaborative pipeline of specialized agents, each responsible for a distinct phase of the onboarding lifecycle. Whether it's crawling and extracting structured API data, planning validation tasks, executing live dry-run tests, generating client code, or writing documentation, these agents function under the coordination of a LangGraph state machine, with a caching layer (Remem) so repeat runs against the same API skip redundant work entirely. **Highlights:** - 🤖 Multi-agent orchestration (Research → Plan → Dispatch → Review) - 🔎 Real, live-crawled research — not model guesswork - 🧪 Dry-run endpoint, auth, rate-limit, and webhook validation against the actual API - 📦 Generated, syntax-validated Python SDK + full integration guide in one run - 🧠 Caching layer avoids re-researching and re-planning APIs you've already onboarded - 🖥️ CLI and Streamlit web UI, both backed by the same pipeline ## Methodology ### System Architecture Overview Agent-Powered API Onboarding is built on a foundational belief: onboarding a new API should be fast, verifiable, and reproducible — not a manual afternoon of reading docs and guessing at edge cases. This philosophy drives every component of the architecture, from how research is gathered to how generated code is validated before it's ever shown to the user. The core of the system is a LangGraph StateGraph at the Orchestrator level, coordinating a set of subgraphs and worker agents, each with its own typed state and clearly scoped responsibility. The high-level flow begins when a user submits a documentation URL. This activates a pipeline of agents, each executing a role akin to a specialized member of an integration team. ### Agents and Roles Agent workflow: Orchestrator → ResearchAgent → Planner → TaskDispatcher → {TesterWorker, SDKWorker, WriterWorker} → ReviewerAgent | Agent | Description | |---|---| | Orchestrator | Validates input, sequences every other agent, aggregates errors across stages, and produces the final pipeline summary | | Research Agent | Runs a safety guardrail, checks a Remem cache, and — on a miss — crawls and extracts structured API data from live documentation | | Planner Agent | Converts research output into a dependency-ordered execution plan of concrete validation and generation tasks | | Task Dispatcher | Batches tasks by dependency order and routes each to the worker that handles its tool type, running independent tasks concurrently | | Tester Worker | Executes live dry-run validation against the real API — auth challenges, endpoint reachability, rate-limit headers, error-code plausibility, webhook event names | | SDK Worker | Generates a complete Python client SDK from the endpoint list and validates it with `ast.parse` before accepting it | | Writer Worker | Generates the markdown integration guide in batches (intro/auth section, then endpoints in fixed-size groups, then a quick-start) to avoid the structural breakdown large single-shot LLM generations are prone to | | Reviewer Agent | Evaluates all task results, retries recoverable failures, and emits the final PASS/FAIL verdict with a full report | ### Detailed Responsibilities **Research Agent** - Screens input through a safety guardrail before any crawling begins - Checks Remem for cached research on the same API domain, skipping the crawl entirely on a hit - Discovers a target site's sitemap (including recursing into sitemap indexes and checking robots.txt), filters to relevant documentation paths, and crawls filtered pages via Firecrawl - Drives a tool-calling LLM loop (validate URL → crawl → parse) until enough raw content is gathered - Extracts a structured research profile — base URL, auth method, endpoints, parameters, rate limits, pagination, error codes, webhooks, API versioning — and scores its own completeness with a weighted confidence metric **Planner Agent** - Converts the research profile into a concrete, dependency-ordered list of tasks: auth verification, per-endpoint tests, rate-limit and error-code checks, webhook validation, SDK generation, and documentation writing - Checks Remem for a prior plan on the same API before generating a new one **Task Dispatcher** - Reads the plan's task dependency graph and executes independent tasks concurrently in batches - Routes each task to whichever worker declares it can handle that task's tool type **Tester Worker** - Performs real dry-run HTTP requests (GET/HEAD/OPTIONS only — mutating methods are flagged for manual review rather than executed) against the live API - Confirms auth challenges are enforced, endpoints are reachable, rate-limit headers are present, documented error codes are plausible HTTP codes, and webhook event names are valid **SDK Worker** - Generates a Python httpx-based client covering every discovered endpoint - Rejects and reports any generated code that fails to parse as valid Python before it's returned **Writer Worker** - Generates the integration guide in stages rather than one giant completion: overview/auth/rate-limits first, then endpoint documentation in fixed-size batches, then a quick-start example referencing the generated SDK - Validates that the assembled guide actually mentions the base URL, auth method, and every documented endpoint path before marking itself verified **Reviewer Agent** - Aggregates pass/fail/skip counts across every dispatched task - Retries recoverable failures where appropriate - Produces the final verdict and a human-readable report All components are tied into typed, accumulating LangGraph state — `OrchestratorState` and `AgentState` — ensuring traceable transitions between stages. Each stage produces a tangible, inspectable output (a `ResearchOutput`, an `ExecutionPlan`, a `DispatchResult`) rather than passing free-text between agents. **The Architecture at a Glance** Agent Pipeline: Orchestrator → ResearchAgent → Planner → TaskDispatcher → {TesterWorker, SDKWorker, WriterWorker} → ReviewerAgent, backed by Firecrawl, Gemini LLM, Remem Cache, and httpx (live API). This agent pipeline model not only makes each stage's output independently inspectable, it also means a single stage — say, the crawler's path-filtering logic, or the writer's batching strategy — can be revised without touching the rest of the pipeline. ### Human-in-the-Loop Design While the pipeline automates research, testing, code generation, and documentation, it is deliberately built to keep the human in control at the points that matter most rather than treat the run as a black box. - **Initiation:** the user is the trigger for every run, supplying the target documentation URL and any configuration up front — nothing is onboarded without an explicit request. - **Guarded execution:** all user-supplied input and intermediate agent text passes through a safety guardrail before crawling or generation proceeds, and mutating HTTP methods (POST/PUT/DELETE) are never executed automatically — only safe, read-only dry-run checks run without a human present. - **Inspectable output, not blind trust:** every artifact — the research profile, the execution plan, the generated SDK, the integration guide, and the final PASS/FAIL report — is written to `output/` for the user to review before it's used, rather than being silently accepted as correct. The confidence score attached to research output is a deliberate signal to the user about how much scrutiny a given run deserves. - **Feedback loop:** if the generated SDK or guide doesn't hold up against the real API, the user re-runs the pipeline with adjusted input; per-domain Remem caching means that re-run doesn't repeat work that was already validated. The current pipeline does not pause mid-run for manual approval between stages — review happens after the run completes, against the full set of generated artifacts. A manual approval gate before the SDK/guide are marked final is a natural next step and is on the roadmap. ### Tool Integration | Tool / Service | Purpose | Key Features | |---|---|---| | Firecrawl | Live documentation crawling | Sitemap discovery (including recursive sitemap indexes and robots.txt parsing), path-based include/exclude filtering, page-count-capped crawl jobs, retry/backoff on rate limits | | Remem | Cross-run memory-as-a-service | Caches research profiles and execution plans per API domain; skips redundant crawling and planning on repeat runs against a known API | | Gemini (via LangChain `init_chat_model`) | LLM inference for research, planning, and generation | Provider-agnostic client initialization; structured output extraction for typed research and plan schemas | | httpx-based live testers | Real dry-run API validation | Direct network calls to the target API's actual endpoints — not simulated — with timeout and error handling | | Guardrail checks | Input and content safety | Screens the input URL and intermediate agent text for unsafe content or prompt-injection attempts before crawling or generation proceeds | ### Project Structure Snapshot ``` agent-powered-api-onboarding/ ├── main.py # CLI entry point ├── streamlit_ui.py # Streamlit web interface ├── agents/ │ ├── Orchestrator.py # Top-level LangGraph pipeline │ ├── ResearchAgent.py # Crawl + extract subgraph │ ├── Planner.py # Execution plan generation │ ├── TaskDispatcher.py # Dependency-ordered task batching │ ├── ExecutorAgent.py # TesterWorker / SDKWorker / WriterWorker │ └── ReviewerAgent.py # Final review and verdict ├── guardrails/ # Input/content safety checks ├── LLM/ # Model client initialization ├── schemas/ # Shared Pydantic models ├── tool/ # Crawling, parsing, validation tools ├── settings/ # Config and Remem client setup ├── tests/ # Regression tests └── output/ # Generated SDK, guide, and task results per run ``` Designed with a clear separation of concerns: each agent's file is independently readable and testable, and the pipeline's stages can be re-run individually via their own compiled subgraphs. ## Installation & Quick-Start Guide Clone the repository and set up a virtual environment: ``` python -m venv .venv .venv\Scripts\Activate.ps1 # Windows ``` Install dependencies: ``` pip install -e . ``` Configure environment variables in a `.env` file: ``` GOOGLE_API_KEY=your_gemini_key MODEL_NAME=gemini-2.5-flash FIRECRAW_API_KEY=your_firecrawl_key REMEM_API_KEY=your_remem_key REMEM_BASE_URL=https://api.remem.online ``` Run the pipeline: ``` python main.py --url https://docs.stripe.com/api ``` Generated artifacts land in `output/`: `generated_sdk.py`, `integration_guide.md`, and `task_results.json`. **▶️ Streamlit Quickstart** ``` streamlit run streamlit_ui.py ``` UI highlights: - Single-field input for the target API's documentation URL - Live per-stage status updates (validating, crawling, extracting, planning, dispatching, reviewing) - Inline rendering of the generated integration guide and SDK, with copy-to-clipboard support **✅ Testing** The project includes regression tests covering the core workflow components, run via: ``` pytest -q ``` **📊 Results** Validated end-to-end against the live Stripe API documentation: 58 endpoints extracted with full confidence (1.0), a 64-task execution plan generated and dispatched (0 failed, 0 skipped), a syntax-valid SDK produced, and a complete integration guide written — all in a single pipeline run with a final PASS verdict. ## Significance & Implications By coordinating specialized agents around real, live-verified data — actual crawled documentation, actual dry-run HTTP requests against the target API — rather than a single model asked to "just summarize the docs," this system demonstrates that API onboarding can be both fast and verifiable, producing artifacts a developer can trust rather than ones they still have to fact-check line by line. ## Security, Privacy & Safety **Threat model & trust boundaries** - Guardrail checks run on all user-supplied input and intermediate agent text before any crawl or generation proceeds, screening for unsafe content and prompt-injection attempts - Live API testing is strictly dry-run: mutating HTTP methods (POST/PUT/DELETE) are never executed against a target API without explicit sandboxing — only GET/HEAD/OPTIONS reachability checks are performed automatically - Generated SDK code is syntax-validated (`ast.parse`) before being surfaced, rejecting output that would fail to run - Secrets (LLM, Firecrawl, and Remem API keys) are read from environment variables or a deployment platform's secrets manager, never hardcoded or logged **Controls** - Structured output validation: research and plan data is extracted into typed schemas (`ResearchOutput`, `ExecutionPlan`) rather than trusted as raw model text - Confidence scoring: research completeness is scored and surfaced with the final result rather than presented as unconditionally reliable - Retry and backoff: crawler and LLM calls use exponential backoff against rate limits rather than hammering external services on failure - Caching boundary: Remem caches are keyed per API domain, so cached research from one API is never served for a different one **Compliance alignment** - No data is retained beyond what's written to local run artifacts (`output/`) and the optional Remem cache - Users control which APIs are onboarded and can inspect every generated artifact before use ## Licensing & Usage Rights This project is released under the **MIT License**. Users are free to use, modify, and distribute the code — including for commercial purposes — provided the original copyright and license notice are retained. A `LICENSE` file with the full text accompanies the repository.45:T7790, ![image.png](image.png) ## Abstract (TL;DR) AI and machine learning repositories often contain valuable technical work but fail to communicate their contributions effectively because of incomplete documentation, poor organization, or weak project presentation. This project introduces a **tool-augmented multi-agent system** that automatically analyzes AI/ML repositories and produces publication-ready documentation tailored to the repository's content and the user's presentation goals. Rather than relying on a single large language model, the system employs **five specialized AI agents** that collaboratively analyze repository structure, evaluate documentation quality, generate improvements, validate technical claims, and refine the final publication. The workflow is orchestrated using **LangGraph**, enabling structured collaboration between agents while integrating external tools such as GitHub repository analysis, web search, retrieval, keyword extraction, and documentation processing. The resulting documentation is repository-specific, technically grounded, and optimized for discoverability, readability, and public sharing. By combining collaborative reasoning with tool augmentation, the system demonstrates how multi-agent AI can improve the quality and consistency of technical documentation for open-source AI/ML projects. --- ## Introduction Open-source AI and machine learning projects continue to grow rapidly, yet many repositories struggle to communicate their value effectively. Excellent implementations frequently remain unnoticed because project documentation lacks clarity, completeness, discoverability, or technical organization. Creating publication-quality documentation is a time-consuming process requiring technical writing, repository analysis, content organization, verification of claims, and knowledge of documentation best practices. These tasks extend well beyond simple text generation and require understanding the repository itself. This project presents a **multi-agent publication assistant** designed specifically for AI and machine learning repositories. Unlike repository-specific documentation generators, this system is designed to generalize across AI and machine learning repositories. By relying on repository analysis, retrieval, and configurable generation goals instead of hardcoded project assumptions, it adapts its recommendations to each project's unique content and audience. Each agent focuses on a distinct responsibility such as repository analysis, metadata optimization, documentation enhancement, quality review, or factual verification. The complete workflow is orchestrated using LangGraph, enabling coordinated decision-making while integrating external tools that provide repository context and supporting evidence. The system accepts a GitHub repository or local repo path together with an optional project description, optional goal, and preferred writing style, then produces documentation tailored to the repository's content, audience, and publication objectives. --- ## Prerequisites - Familiarity with AI/ML repository structure and README conventions. - Python 3.11+ installed in a local environment. - Basic experience with CLI tools for running Python scripts. - Optional familiarity with LLM provider configuration and API key management. This section helps readers know the environment and background needed before using the system. --- ## Why This Matters High-quality documentation increases adoption because it helps developers, researchers, and contributors understand a project quickly and accurately. - Good documentation turns strong code into usable deliverables. - Many AI/ML repositories fail despite strong technical work because they do not explain the problem, architecture, or how to use the project. - Multi-agent systems outperform a single LLM for this task by separating analysis, metadata, content generation, review, and verification. - Developers benefit from clearer onboarding. - Researchers benefit from reproducible project summaries. - Open-source communities benefit from discoverable, trustworthy publications. This project emphasizes not only what the system generates, but why it is needed to make repository content visible and credible. --- ## Problem Statement Although modern language models can generate documentation, they often produce generic content that is disconnected from the actual repository. Common challenges include: - Incomplete README files - Missing architectural explanations - Poor project discoverability - Weak technical summaries - Inconsistent documentation structure - Missing examples and onboarding guidance - Unsupported or hallucinated technical claims Single-agent systems frequently struggle to balance repository understanding, technical accuracy, presentation quality, and validation simultaneously. --- ## Objectives The primary objectives of this project are: - ✅ Automatically analyze AI/ML repositories. - ✅ Improve project documentation for public sharing. - ✅ Generate repository-specific documentation instead of generic templates. - ✅ Increase documentation clarity and completeness. - ✅ Improve discoverability through better project presentation. - ✅ Validate generated content using external tools whenever possible. - ✅ Demonstrate effective collaboration among multiple AI agents. --- ## System Overview The Publication Assistant operates as a collaborative multi-agent system where specialized agents work together to transform repository information into publication-ready documentation. Instead of one model performing every task, responsibilities are distributed among independent agents that exchange structured information throughout the workflow. The orchestration layer coordinates execution order, information sharing, and decision-making to ensure consistent outputs. --- ## Inputs and Outputs ### Input - GitHub repository URL - Local repository path - Optional project description - Optional generation goal - Writing style selection ### Output - Improved README content - Repository summary - Metadata and suggested title(s) - Keywords/tags - Quality review report - Verification report This clarifies the interface and makes the system easier to reproduce. --- ## Multi-Agent Architecture The system consists of five collaborating agents: ### Repository Analysis Agent - Understands repository structure - Extracts README content and file statistics - Detects missing docs sections - Builds a repository summary ### Metadata Recommendation Agent - Improves project title suggestions - Generates short descriptions - Optimizes discoverability with keywords and tags - Uses Gemini when available, falls back to heuristics otherwise ### Documentation Enhancement Agent - Produces improved README content - Reorganizes and expands sections - Injects best-practice hints from RAG retrieval - Synthesizes examples from repository evidence ### Quality Review Agent - Reviews readability and structure - Detects documentation gaps - Identifies missing sections such as Installation or Usage - Provides a review score and actionable recommendations ### Verification Agent - Extracts scientific-looking claims from README text - Cross-checks claims against Arxiv search results - Flags uncertain or unsupported statements - Helps reduce hallucinations --- ## Design Decisions ### Why LangGraph instead of a sequential chain? LangGraph enables structured state passing and reproducible execution. It allows each agent to consume and extend shared context rather than forcing all logic into a linear prompt chain. ### Why five specialized agents? Each agent handles one distinct concern: - analysis - metadata - content improvement - review - verification This separation reduces dependency on a single model and improves transparency and maintainability. ### Why RAG? RAG retrieval is used when enabled and available. It can ground the content improvement step in best-practice documentation examples and repository evidence, which helps the system avoid generic outputs and stay aligned with real documentation patterns. ### Why verification last? Verification is applied after the final draft is generated so the system validates what is actually produced. This avoids spending resources on poor drafts and ensures the final output is checked. ### Why separate metadata generation from README generation? Metadata guides the writing process and improves discoverability independently. By separating these responsibilities, the system can produce better titles, summaries, and tags while still generating rich README content. ### Why model-agnostic architecture? The orchestration pipeline is independent of any single LLM provider and can operate with different supported models, allowing users to balance cost, performance, and availability. --- ## Methodology The system follows a staged methodology that mirrors how humans prepare technical publications. 1. **Repository ingestion**: The repository is acquired from a local path, ZIP archive, or git URL and parsed into files and README content. 2. **Repository analysis**: The analyzer extracts file statistics, README structure, missing section signals, and a short project summary. 3. **Metadata generation**: Titles, short descriptions, and tag suggestions are created based on extracted keywords and repository context. 4. **Documentation enhancement**: The README is rewritten using retrieval hints and web search examples, while preserving repository-specific evidence. 5. **Quality review**: The reviewer checks the draft for missing sections, readability issues, and structure problems. 6. **Fact verification**: Technical claims are identified and evaluated against Arxiv search results. 7. **Final publication generation**: The system assembles the improved README, metadata, review findings, and verification report. Each stage passes structured outputs into shared state so later stages build on the results of earlier analysis. --- ## Agent Communication The agents collaborate through shared state managed by LangGraph. Outputs from one agent become inputs for the next. ```mermaid flowchart TD RepoAnalyzer[Repository Analyzer] --> SharedState1[Shared State] SharedState1 --> MetadataAgent[Metadata Agent] MetadataAgent --> SharedState2[Shared State] SharedState2 --> READMEAgent[Documentation Enhancement Agent] READMEAgent --> SharedState3[Shared State] SharedState3 --> Reviewer[Quality Review Agent] Reviewer --> FactChecker[Verification Agent] ``` LangGraph’s shared state enables each agent to consume outputs from previous agents instead of operating independently. This ensures the workflow is coherent and avoids repeated analysis. --- ## Performance Considerations - The system is designed to avoid repeated computation by passing state through LangGraph rather than recalculating the same repository context. - Retrieval-Augmented Generation reduces hallucination by grounding README improvements in actual documentation examples. - Optional external services degrade gracefully, allowing the pipeline to continue even if some APIs are unavailable. - The pipeline scales to different repository sizes by analyzing file content selectively and ignoring overly large files. --- ## Failure Handling The project includes defensive behavior for common failure modes: - If no README exists, analysis continues with an empty README and the system detects missing documentation sections. - If a repository cannot be cloned or parsed, the parser raises an error and the UI can report the failure. - If an API is unavailable, tools fall back to heuristics or skip optional behavior instead of breaking the pipeline. - If the RAG database has no relevant hits, the content improvement step still proceeds with whatever evidence is available. - If no internet access exists, the system can still use local heuristics for keyword extraction and metadata generation. --- ## Technical Architecture The system employs LangGraph to orchestrate interactions among agents. Agents do not operate in isolation; they exchange intermediate outputs and build on prior analysis. This architecture supports: - modularity - reproducibility - graceful fallback when optional tools are unavailable - easier extension with new agents or tools ```mermaid flowchart TD Analyze[Repo Analysis] --> Metadata[Metadata Recommendation] Metadata --> Improve[Content Improvement] Improve --> Review[Quality Review] Review --> Verify[Fact Verification] Verify --> Final[Final Output] ``` The orchestrator is implemented in `orchestration/graph.py` and uses a `StateGraph` to compile the pipeline. --- ## Workflow Rationale - **Repository analysis first** because later agents need accurate context. - **Metadata before content** so title and discoverability signals guide the writing style. - **Review before verification** to ensure only refined content is checked. - **Verification last** because the final output is the one that must be credible. This ordered workflow reduces wasted work and reinforces quality at each stage. --- ## Tool Selection | Tool | Purpose | | ------------------ | -------------------------------------------------------------------------------------------------------------- | | `RepoParser` | Provides structural understanding of the repository by reading files, README content, and repository metadata. | | `KeywordExtractor` | Improves discoverability by extracting relevant technical terms from README text and repository content. | | `WebSearchTool` | Adds external context from similar repositories and documentation examples when Tavily is available. | | `RAGRetriever` | Injects best-practice documentation guidance from ChromaDB retrieval results. | | `ArxivScholarTool` | Validates technical claims against academic literature, reducing unsupported statements. | These five tools were selected to give each agent strong evidence sources, enabling the system to produce grounded, repository-specific documentation rather than generic text. --- ## System Requirements | Requirement | Value | | --------------- | ------------------------------------- | | Python | 3.11+ | | Framework | LangGraph | | UI | Gradio | | LLM | Gemini / Groq / OpenAI (configurable) | | Vector Store | ChromaDB | | Supported Input | GitHub URL, Local Folder, ZIP | --- ## Deployment and Usage The project can be deployed locally or served as a Gradio web interface. Core functionality requires Python 3.11+ and the repository dependencies. 1. Install dependencies: ```bash pip install -r requirements.txt ``` 2. Run the interactive Gradio app: ```bash python app.py ``` 3. Run the pipeline from the CLI: ```bash python main.py --repo /path/to/repo ``` 4. Optional environment variables: - `GOOGLE_API_KEY` - `GROQ_API_KEY` - `TAVILY_API_KEY` External services are optional; if API keys are not provided, the pipeline falls back to heuristic behavior and still produces documentation recommendations. Deployment considerations: - A local Python environment is sufficient for the core pipeline. - The Gradio interface can be hosted on a secure server for team access. - Optional external services improve grounding but are not required for basic repository analysis and documentation improvement. Monitoring and maintenance considerations: - Track model provider availability and API usage to avoid unexpected service interruptions. - Review generated documentation outputs periodically to ensure content remains aligned with repository changes. - Update dependency versions and environment variables as external APIs evolve. --- ## End-to-End Example **Input** - Repository: `github.com/user/rag-chatbot` - Goal: Improve documentation for researchers - Style: Technical Blog **Output** - ✓ Improved title suggestions - ✓ Better project summary - ✓ Missing installation section detected - ✓ Repository-aware README organization - ✓ Suggested metadata tags and keywords - ✓ Review report with issues and strengths - ✓ Verification report for scientific claims This example shows how the system converts repository input into a publication-ready output list. --- ## Key Features - 🧠 **Multi-agent collaboration** across repository analysis, metadata, content, review, and verification - 🛠️ **Tool-augmented reasoning** with GitHub parsing, keyword extraction, web search, retrieval, and Arxiv validation - 📄 **Repository-aware documentation generation** instead of generic README templates - 🔎 **Discoverability optimization** via titles, summaries, tags, and better structure - ✅ **Quality review and issue detection** with actionable output - 🔍 **Technical claim verification** to reduce unsupported statements - ⚡ **Graceful fallback** when optional external APIs are unavailable --- ## Implementation Details The repository contains these major components: | Component | Description | | ------------------------ | ----------------------------------------------------------------------------------------- | --- | | `agents/` | Five agent modules for analysis, metadata, content improvement, review, and fact checking | | `tools/` | Repository parser, web search, keyword extraction, retrieval, and Arxiv scholar tooling | | `orchestration/graph.py` | LangGraph orchestrator that compiles and runs the pipeline | | `app.py` | Gradio web UI for interactive publication generation | | `main.py` | CLI entrypoint for batch or local repository execution | | ### Tool Behavior - `RepoParser.parse()` supports local folders, ZIP archives, and remote git URLs. - `RepoAnalyzerAgent` computes file statistics, extracts README content, detects missing sections, and derives a short summary. - `KeywordExtractor` uses Gemini if available, otherwise falls back to frequency-based heuristic extraction. - `MetadataRecommenderAgent` generates title suggestions and short descriptions, using Gemini only when configured. - `ContentImproverAgent` synthesizes improved README content by combining web search examples and retrieved best-practice hints. - `ReviewerCriticAgent` returns a simple review score with issues, strengths, and recommendations. - `FactCheckerAgent` extracts claims from README text and checks them against Arxiv search results. ### Gradio Interface The Gradio app in `app.py` enables users to: - validate a repository URL - choose a writing style and publication length - select an AI model provider - generate an improved README and metadata - view tags rendered as visual badge elements Output is formatted as a polished title, tag section, and cleaned improved README body. **Screenshot of the Interface:** ![Screenshot 5.png](Screenshot%205.png)![Screenshot 4.png](Screenshot%204.png) --- ## Novel Contributions - A generalized multi-agent documentation workflow for AI/ML repositories. - Goal-driven publication generation instead of template-based README rewriting. - Repository-aware documentation grounded in actual repository evidence. - Integration of verification and review into documentation generation. - Modular LangGraph architecture supporting extensibility and shared state. --- ## Comparative Analysis The Publication Assistant is evaluated relative to several alternative approaches: - **Original README**: the baseline repository documentation without automated assistance. - **Single-pass LLM rewriting**: an LLM-only approach that rewrites a README from the same source. - **Static README generator**: template-based solutions that fill predefined sections without repository understanding. - **Documentation linting tools**: tools that assess structure and style but do not generate new content. - **Manual expert editing**: human-guided README improvement using established documentation checklists. Trade-offs: - original README preserves exact repository facts but often lacks structure and completeness. - single-pass LLM rewriting can improve language but may hallucinate and miss repository-specific details. - static generators are fast but produce generic outputs with low technical grounding. - linting tools identify issues but do not synthesize improved prose or metadata. - manual editing is high quality but time-consuming and inconsistent across repositories. The Publication Assistant aims to combine evidence grounding, structure generation, and verification in a way that balances automation with repository specificity. --- ## Application Case Studies The system has been applied to representative AI/ML repositories with varying documentation quality. Example outcomes include: - A repository with an incomplete README gained clearer installation, usage, and architecture sections while preserving its technical implementation details. - A second repository with scattered documentation benefited from unified metadata generation and a consolidated project summary. - A third repository with ambitious technical claims received targeted verification feedback that flagged unsupported statements and suggested corrections. Lessons learned: - repositories with sparse README content require stronger evidence synthesis from repository files; - verification is particularly valuable for academic or research-oriented projects that cite technical claims; - optional retrieval and web search sources improve output quality, but the system must degrade gracefully when external services are unavailable. These case notes provide practical success stories and show how the system behaves in real usage. --- ## Applications This system can assist: - research repositories - computer vision projects - NLP libraries - agentic AI systems - MLOps tools - Kaggle projects - university coursework - startup AI products --- ## Evaluation Framework The system is evaluated by running it on multiple AI/ML repositories with varying documentation quality, using a defined framework of metrics and baselines. Key evaluation metrics: - **Readability**: changes in readability scores such as Flesch Reading Ease or similar text quality measures. - **Documentation completeness**: presence of core sections (Installation, Usage, Architecture, Contributions) before and after improvement. - **Reviewer quality score**: the system’s internal review output measured as a composite score of clarity, structure, and section coverage. - **Verification precision**: proportion of extracted technical claims that are supported or flagged by Arxiv search. - **Metadata relevance**: match of generated titles, descriptions, and tags to repository keywords and intent. - **Time to publish**: estimated authoring effort reduction compared to manual README improvement. Comparison baselines: - original repository README without automated assistance - single-pass LLM README rewriting - static README template generators - traditional documentation linting tools - manual author editing supported by standard documentation checklists Evaluation criteria: - improvement in completeness and structure relative to the original README - reduction in unsupported or hallucinated statements - quality of metadata suggestions and discoverability signals - ability to generalize across diverse AI/ML repositories Measurement approach: - apply the system to representative AI/ML projects and record metric changes before/after. - compare generated documentation against baseline outputs using the same metrics. - review qualitative differences in structure, language, and technical grounding. - collect user or reviewer feedback where available to validate improvements. This evaluation framework gives clear success criteria and a repeatable approach for assessing the tool's effectiveness. --- ## Results Across representative AI/ML repositories with varying documentation quality, the system consistently: - generated repository-specific documentation - identified missing sections such as Installation and Usage - improved README organization and summary quality - produced clearer metadata suggestions - reduced unsupported technical statements through verification These results are qualitative and trace the system’s ability to produce better documentation than generic README rewriting. --- ## Results Interpretation The observed improvements indicate that structured repository analysis and tool-augmented agent collaboration can produce more coherent and complete documentation than generic rewriting approaches. By focusing on repository-specific evidence, the system is able to preserve technical details while improving clarity. Key insights: - stronger documentation structure correlates with higher reviewer scores and clearer onboarding paths; - verification feedback helps identify unsupported claims that would otherwise persist in generated content; - metadata generation improves discoverability by aligning titles and descriptions with extracted repository keywords. Unexpected findings and implications: - some repositories required more aggressive section reconstruction than simple rewriting, highlighting the need for deep repository context; - optional external tools such as RAG retrieval and web search improve grounding, but the system must still handle cases where those services are unavailable. These interpretations clarify the meaning of the system’s results and what stakeholders can expect when using it. --- ## Discussion The design trades off modularity and reliability against added orchestration complexity: - Multi-agent systems improve modularity but require careful state management. - Verification increases reliability but adds execution time. - Tool integration improves grounding but depends on external services. - Shared state with LangGraph minimizes repeated computation while preserving agent independence. This discussion emphasizes the practical trade-offs in building robust documentation automation. --- ## Future Directions Future work can extend the system in several ways: - Add automated evaluation metrics for documentation quality and change impact. - Integrate richer repository signals such as test coverage, dependency graphs, and issue tracker context. - Expand retrieval sources beyond ChromaDB to include custom domain corpora or internal documentation. - Add automated monitoring for drift in generated outputs as repository content changes. These extensions would make the system more robust for long-term adoption and broader AI/ML repository support. --- ## Success Metrics Success is measured by: - Documentation completeness - Readability - Technical accuracy - Discoverability - User satisfaction - README quality score These metrics align with the goals of a publication-ready documentation workflow. --- ## Limitations The system is intentionally practical, but it has limitations: - Depends on repository quality and available README content. - Cannot verify proprietary code or private repository details. - Web search may be unavailable if Tavily or API keys are missing. - Large repositories may increase processing time. - Some recommendations still require human judgment before publication. --- ## Reproducibility To reproduce this work, the repository includes: - `requirements.txt` for Python dependencies - `app.py` and `main.py` as execution entry points - optional environment variables: `GOOGLE_API_KEY`, `GROQ_API_KEY`, `TAVILY_API_KEY` - support for offline heuristic behavior when LLM or web search services are unavailable - Python 3.11+ recommendation This makes the system easier to run in different environments. --- ## Access, License, and Support The project is published as an open-source implementation. See the `LICENSE` file for usage rights, redistribution terms, and license details. Support and maintenance are provided through the GitHub repository. Users can report issues, request features, and submit contributions via the repository issue tracker. The project is intended as a practical reference implementation for collaborative AI agent systems rather than a production SaaS offering. --- ## Ethical Considerations - Generated documentation should be reviewed by humans. - The system avoids inventing repository features and explicitly flags uncertainty where necessary. - Verification is used to reduce unsupported claims. - Final documentation should accurately represent implementation details. --- ## References 1. LangChain Inc. LangGraph Documentation. https://langchain-ai.github.io/langgraph/ 2. LangChain Documentation. https://python.langchain.com/ 3. ChromaDB Documentation. https://docs.trychroma.com/ 4. arXiv API Documentation. https://info.arxiv.org/help/api/ 5. Tavily Search API. https://docs.tavily.com/ 6. Google Gemini API Documentation. https://ai.google.dev/ 7. Gradio Documentation. https://www.gradio.app/ --- ## Conclusion Effective documentation is essential for communicating the value of AI and machine learning projects, yet producing high-quality technical publications remains challenging and time intensive. This project shows how specialized AI agents combined with external tools and structured orchestration can automate complex documentation work while preserving technical grounding. By transforming raw repository information into publication-ready documentation, the Publication Assistant provides a practical example of how multi-agent systems can improve the visibility, accessibility, and impact of open-source AI/ML repositories. More broadly, the project demonstrates how decomposing complex documentation tasks into specialized, tool-augmented agents can improve both the quality and reliability of AI-assisted technical writing. The architecture is modular, extensible, and applicable to a wide range of AI/ML repositories, making it a practical reference implementation for collaborative AI agent systems. 46:T2f81,![hero-image.svg](hero-image.svg) **Program:** Mastering AI Agents Certification — Multi-Agent System Capstone **Category:** Technical Assets → Tool/App/Software **Author:** Joram Kirubi **Code:** https://github.com/joramkirubi/Publication-assistant ## TL;DR This project is a four-agent, LangGraph-orchestrated system that takes a GitHub repository URL and returns a concrete, actionable report: a better title and summary, relevant publication tags, and exactly which standard documentation sections are missing — checked against objective, rule-based criteria rather than a single LLM's opinion. It satisfies the Mastering AI Agents capstone requirements (minimum 3 agents, minimum 3 tools, orchestration framework) with margin: 4 agents, 4 tools, LangGraph. ## What Is This About? This project builds a multi-agent system, Publication Assistant, that helps AI/ML practitioners prepare a GitHub repository for public sharing by automatically reviewing it against Ready Tensor's own documentation standards. Give it a repo URL; it returns a suggested title and summary, suggested publication tags, a checklist of missing documentation sections, and an overall recommendation — all synthesized into one markdown report. The system uses 4 agents (Repo Analyzer, Metadata Recommender, Content Improver, Reviewer/Critic) coordinated by LangGraph, and integrates 4 tools (a GitHub API reader, a rule-based README structure checker, a keyword extractor, and a web search tool), exceeding the capstone's minimum requirements of 3 agents and 3 tools. ## Why Does It Matter? Most shared AI/ML repositories fall short of the documentation standards that would make them genuinely useful to others — missing installation steps, no license, titles that don't explain what the project actually does. Ready Tensor's own Open Source Repository Guide and Technical Evaluation Rubric lay out clear, objective criteria for what "good" looks like, but manually checking a repository against that checklist is tedious and easy to skip under deadline pressure. This system automates that first pass. It applies the same Essential/Professional documentation criteria programmatically, so an author gets a concrete, prioritized list of what to fix in seconds — before investing time polishing the wrong thing, or nothing at all. ## System Architecture Four agents collaborate through a single shared state object, coordinated by a LangGraph graph with a deliberate fan-out/fan-in shape: ![architecture-diagram (1).svg](architecture-diagram%20(1).svg) | # | Agent | Role | Tool(s) used | |---|---|---|---| | 1 | Repo Analyzer | Fetches README text, file structure, and repo metadata (stars, license, language) | github_repo_reader | | 2 | Metadata Recommender | Extracts candidate keywords, then uses an LLM to refine them into publication-quality tags | keyword_extractor | | 3 | Content Improver | Searches the web for how similar projects are positioned, then drafts a grounded title/summary | web_search | | 4 | Reviewer / Critic | Checks the README against Ready Tensor's Essential/Professional documentation tiers, synthesizes everything into one final report | readme_structure_checker | **Design decision — why parallel branches?** Metadata Recommender and Content Improver don't depend on each other's output, so they run concurrently rather than in a strict chain, cutting end-to-end latency since both branches' LLM calls happen at the same time instead of sequentially. **Design decision — why a rule-based tool alongside LLM agents?** The readme_structure_checker tool is deliberately deterministic (regex/heading matching against Ready Tensor's own documented Essential-tier criteria), not another LLM call. This gives the Reviewer agent an objective, reproducible signal to reason over, rather than compounding LLM opinion on LLM opinion. ## Human-in-the-Loop Review The graph genuinely pauses before the Reviewer/Critic agent runs — using LangGraph's `interrupt_before` mechanism backed by a checkpointer — so a person can inspect the suggested title, summary, and tags, edit any of them, and leave free-text feedback before the final report is generated. This isn't a cosmetic log message: the edited values and feedback are injected back into the shared state via `update_state()` and are what the Reviewer/Critic agent actually reads when it resumes, which we verify with a dedicated test that inspects the exact text sent to the LLM after an edit. **Two issues surfaced only through real, interactive execution — not the mocked test suite alone:** 1. Because Metadata Recommender and Content Improver write to state in the same parallel step, applying a human's edit via `update_state()` raised `InvalidUpdateError: Ambiguous update, specify as_node` — LangGraph couldn't infer which of the two simultaneous writers the edit belonged to. Fixed by explicitly passing `as_node="content_improver"`. 2. The interactive approve/edit prompt initially treated any unrecognized input — not just `n` or `e` — as silent approval. Fixed by validating input and re-prompting until a real Y/n/e answer is given, backed by a dedicated regression test. Both issues trace back to the same architectural choice: Metadata Recommender and Content Improver running in parallel for latency. That's a deliberate tradeoff, and these two bugs are a concrete part of its cost — evidence of a real design decision with real, findable edges, not a frictionless demo. **Proof the human's input genuinely reaches the model, not just gets stored.** Approving as-is with no edits in a real run against `medical-rag-assistant` produced this actual excerpt from the final report: > "Given the human reviewer's approval and the absence of specific feedback, it is recommended to proceed with the suggested title, summary, and tags..." The model is explicitly reasoning about the human's approval status inside its own recommendation — a genuine conditional response to what happened at the checkpoint, not a static template. Running with `--auto-approve` skips the interactive prompt for scripted or non-interactive use; the checkpoint is on by default otherwise. ## Can I Trust It? — Technical Quality & Proof of Execution **Automated tests.** The tool logic and agent orchestration are covered by 21 automated tests, including agent-level tests that mock the GitHub API and LLM calls so they run deterministically without needing live credentials, a regression test for a real concurrency bug caught during development (details below), dedicated tests proving the human-in-the-loop checkpoint genuinely pauses execution and that edits made during the pause reach the LLM call, and regression tests for the CLI input-validation fix described above. **Grounded generation.** The Content Improver agent's system prompt explicitly instructs the LLM to draft claims only from the provided README text, not to invent features or metrics — reducing hallucinated claims in the suggested title/summary. **Graceful degradation.** Every agent has explicit error handling. If the GitHub API fails, the web search API key is missing, or an LLM call errors, the pipeline continues and surfaces the issue in the final report rather than crashing. **A real run, not a mocked example.** The following is unedited output from running the system against a real, independent repository ([medical-rag-assistant](https://github.com/joramkirubi/medical-rag-assistant)): $ python main.py --repo https://github.com/joramkirubi/medical-rag-assistant ![demo-interaction.svg](demo-interaction.svg) ## Summary of Findings The provided README for MedAssist, a medical AI assistant, covers essential sections such as project title, installation, and license. However, it lacks critical sections like overview/description, usage, configuration, testing, and contributing. ## Suggested Title & Summary MedAssist — Medical AI Assistant: uses Retrieval-Augmented Generation (RAG) and ReAct reasoning strategy for medical question answering. ## Suggested Tags Retrieval-Augmented-Generation, RAG, LangChain, HuggingFace, Groq, ChromaDB, ReAct, MedicalQuestionAnswering, Streamlit ## Missing Sections - Overview / Description - Usage - Configuration - Testing - Contributing ## Overall Recommendation Add the missing essential and professional sections to improve usability, maintainability, and community engagement. ✅ Report saved to reports/joramkirubi_medical-rag-assistant_20260702-143012.md This demonstrates all four agents completing successfully against a repo the system had never seen, with tags and structural gaps that are independently verifiable by checking the target repository directly. ## Can I Use It? — Documentation & Usage Prerequisites: Python 3.10+, a free Groq API key (required), optionally a Tavily API key (enables web search positioning context) and a GitHub token (raises API rate limits). **Installation:** git clone https://github.com/joramkirubi/Publication-assistant.git cd publication-assistant python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt cp .env.example .env python main.py --repo https://github.com/owner/repo Every run auto-saves a timestamped markdown report under `reports/`, in addition to printing it to the console. **Testing:** pytest tests/ -v ## Limitations & Future Work - Only public GitHub repositories are currently supported (no GitLab, Bitbucket, or private repos without a token that has access). - The structure checker is heading/regex-based — a README that documents installation steps in prose without a heading may be under-flagged. - Content Improver's suggestions are only as strong as the web search context available; without a Tavily key it drafts from the README alone. - No automated fact-checking agent yet — the Reviewer/Critic asks the LLM to ground claims in the README but doesn't independently verify them. - Formal evaluation metrics were considered as an optional enhancement but were deliberately scoped out of this submission to keep the four core agents solid and well-tested — noted here as a scope decision, not an oversight. ## Repository & License **Code:** https://github.com/joramkirubi/Publication-assistant **License:** MIT **Contact:** open an issue on the repository for questions or bug reports. ## Support & Maintenance - **Getting help:** open a GitHub issue on the repository — this is the primary support channel and keeps Q&A visible for future users hitting the same problem. - **Bug reports:** please include the repo URL you ran it against, the full error output, and your Python/LangGraph version. - **Maintenance status:** actively maintained as a personal/portfolio project. There's no fixed SLA on issue response time, but issues are monitored and triaged. - **Versioning:** currently pre-1.0 (no formal semantic versioning yet); breaking changes will be called out in commit messages and, once versioning starts, in a CHANGELOG.md. - **Planned improvements:** see Limitations & Future Work above — GitLab/Bitbucket support and an automated fact-checking pass are the top candidates. ## Conclusion Publication Assistant demonstrates a multi-agent system where the agent/tool split reflects genuinely different sub-problems — deterministic structural analysis, LLM-refined metadata extraction, web-grounded content drafting, and final synthesis — coordinated through LangGraph's graph model rather than a single linear chain. It's a small system by design: four agents with clear, separable responsibilities, each independently testable, run successfully against a real, independent repository, with an honest account of where it can still fail.47:T3a86,

# FinSight — A Multi-Agent Financial Research Assistant with RAG, MCP Tools, and Grounded Citations > **AAIDC Module 2 — Build Your Multi-Agent System.** > Repository: https://github.com/phanminhtai23/finsight-multi-agent ## TL;DR FinSight is a production-style, multi-agent system that answers financial questions about **any company** — from documents you upload (PDF / Word / TXT) or from **live web sources** — and **always answers with inline citations** back to the exact source. A LangGraph supervisor coordinates six specialized agents over a retrieval-augmented-generation (RAG) layer backed by **Qdrant**, with tools exposed through a dedicated **Model Context Protocol (MCP)** server. Long jobs (document ingestion) run asynchronously so the user can keep chatting. A full **React** app wraps it with auth, **token streaming**, a live "thinking" view, on-the-fly **charts**, and per-topic knowledge bases. The whole stack runs with one `docker compose up` and is verified end-to-end. ## The Problem Reading financial reports is slow, and generic chatbots are untrustworthy for finance: they hallucinate figures and can't show *where* a number came from. FinSight targets exactly this gap — grounded, **cited** answers that combine a user's private documents with live market research. ## What FinSight Does - **Upload any document** (PDF, DOCX, TXT) → it is parsed, chunked, embedded, and indexed automatically (in the background). - **Ask questions in natural language** → a team of agents retrieves evidence, analyzes it, writes the answer, and a Critic verifies it is grounded and cited. - **Researches the live web** (via MCP tools) for companies not in your documents. - **Every claim is cited** `[n]`, mapping to a document page (deep-linked on Cloudinary) or a web URL. - **Visualizes on demand** — ask to "plot" or "compare" and a Visualization agent renders bar / line / area / pie charts alongside the answer. - **Real application** — sign-up with email verification + Google Sign-In, per-topic knowledge bases (each = a Qdrant collection), storage quota, dark mode, token streaming, a toggleable reasoning view, and the **names of the tools the agent invoked** shown inline. ## Architecture ```mermaid flowchart TD U["🖥️ React UI (Vite + TS)"] -->|"REST · SSE · WebSocket"| API["⚡ FastAPI
(RESTful · SOLID · DI)"] subgraph AGENTS["🤖 LangGraph multi-agent graph"] direction TB SUP(["🧭 Supervisor
triage & route"]) RET["📚 Retrieval
(RAG)"] MR["🌐 Market Research"] AN["📊 Analyst"] WR["✍️ Writer
+ citations"] CR["🔎 Critic
grounding check"] SUP --> RET --> AN --> WR --> CR SUP --> MR --> AN CR -.->|"revise ≤2"| AN end API --> SUP subgraph DATA["🗄️ Datastores"] QD[("Qdrant
vectors · per-topic")] PG[("Postgres
relational + checkpointer")] RD[("Redis
cache · pubsub · queue")] end subgraph EXT["🧰 Tools & services"] MCP["🔌 MCP server :8001
web_search · fetch_url
company_financials · calculator"] CL["☁️ Cloudinary
raw files"] LS["📈 LangSmith
tracing & eval"] end RET --> QD MR -->|"MCP client"| MCP API --> PG API --> RD API --> WK["⏳ ARQ worker
async ingestion"] WK --> CL WK --> QD WK -.->|"progress · pubsub"| RD API -.->|"trace"| LS ``` **Request flow.** The UI calls FastAPI over REST; chat answers stream back over **SSE** (tokens, thinking, citations, charts, tool names) and ingestion progress over **WebSocket**. FastAPI invokes the **LangGraph** graph, whose Supervisor routes to the right agents; the Retrieval agent hits **Qdrant**, the Market Research agent calls the **MCP server** as a client. Uploads are handled out-of-band by an **ARQ worker** that parses, chunks, embeds and indexes into Qdrant while the user keeps chatting. Design principles: **SOLID** (thin controllers, business logic in services, data access and tools behind `Protocol` interfaces, dependency injection), a **RESTful** versioned API, `ruff` + `pytest`, and a clean separation between relational state (Postgres + LangGraph checkpointer) and vectors (Qdrant). Full design: [`ARCHITECTURE.md`](ARCHITECTURE.md). ## The Multi-Agent System (LangGraph) Six agents, supervisor-coordinated: | Agent | Role | |-------|------| | **Supervisor** | Triage — decide whether the question needs live external web data; route the flow. | | **Retrieval** | Hybrid search over the user's documents in Qdrant; returns cited evidence. | | **Market Research** | Live web/financial research via the **MCP** `web_search` tool. | | **Analyst** | Synthesize evidence; compute ratios, comparisons, trends. | | **Writer** | Compose the final answer with inline `[n]` citations. | | **Critic** | Verify every claim is grounded and cited; bounce back for a bounded revision loop. | ``` START → supervisor → retrieval → [market_research if needed] → analyst → writer → critic → analyst (revise, ≤2) | END ``` State is persisted per conversation thread with LangGraph's **AsyncPostgresSaver**, so threads are durable and resumable. ## Human-in-the-Loop Integration FinSight is designed so that the human remains in control at every step. The agents are tools the user wields — not autonomous actors that fetch and conclude without oversight. ### What users directly control | Control point | How it works | |---------------|-------------| | **Knowledge base curation** | Users create named *topics* and upload their own documents (PDF, DOCX, TXT). The Retrieval agent only searches collections the user has explicitly created and pinned to the conversation. The human decides what private data the agents can see. | | **Query formulation & redirection** | Users phrase every question. If an answer is off-target they can rephrase, add constraints ("only use my uploaded documents, ignore web results"), or redirect to a different aspect — the Supervisor re-routes accordingly. | | **Source verification** | Every factual claim carries an inline `[n]` citation. Clicking a citation opens the exact source page (deep-linked on Cloudinary for uploaded documents, or the original URL for web results). Users can accept or reject the agent's interpretation by checking the primary source. | | **Thinking transparency** | A **Thinking toggle** streams the Supervisor's internal reasoning chain live to the UI — users can watch which agents were invoked, in what order, and why. This makes it easy to spot a reasoning path that seems incorrect before acting on the answer. | | **Topic scoping** | Users pin one or more topics to a conversation. This bounds the Retrieval agent's search space, letting users isolate research to a single company or reporting period. | | **Async task monitoring** | Long-running jobs (document ingestion, deep research) run in a background task panel with live WebSocket progress. Users can keep chatting, start other tasks, and cancel or ignore jobs independently. | ### The bounded revision loop After the Writer produces an answer, the **Critic** agent independently checks that every claim is grounded in the retrieved evidence and carries a citation. If the check fails, the Critic returns the answer to the Analyst with specific instructions — this loop runs **at most twice** to prevent infinite correction cycles. A user who finds the answer still unsatisfactory can follow up with a new question or rephrase, triggering a fresh graph run. ### Design intent The citation-first design means users are never asked to trust the system blindly. Every answer is a *hypothesis with evidence*: the human validates the sources, not the system's word. Topic management keeps users in control of the knowledge domain, and the thinking view keeps the agent workflow auditable. ## Retrieval-Augmented Generation - **Multi-format ingestion**: PDF (PyMuPDF + table extraction via pdfplumber), DOCX, and TXT. A parser registry makes new formats additive (Open/Closed). - **Advanced chunking**: structure-aware + recursive splitting, **parent–child (small-to-big)**, **Anthropic-style contextual retrieval**, and table-aware handling for financial statements. - **Hybrid retrieval**: dense vectors (Gemini `gemini-embedding-2`, 3072-d, cosine) fused with a keyword (full-text) leg via **Reciprocal Rank Fusion**, then small-to-big context expansion. - **Citations**: each chunk carries document, page, and source URL; the Writer emits `[n]` markers the Critic validates against the evidence. ## Tools via MCP (≥ 3 tools, MCP communication) A dedicated **MCP server** (FastMCP, streamable-HTTP) exposes four tools; the Market Research agent is an **MCP client** that calls them over the protocol: - `web_search` — DuckDuckGo web search (no API key) - `company_financials` — focused search for a company's latest results - `fetch_url` — fetch and clean a web page's text - `financial_calculator` — safe arithmetic evaluation (AST-based) This satisfies both the **≥3 tools** requirement and the optional **MCP communication** enhancement. ## Skills Reusable, self-contained capabilities any agent or client can invoke (behind a `TextGenerator` port): `summarize`, `translate`, `fact_check` — exposed via `GET/POST /api/v1/skills`. ## Evaluation & Baseline Benchmarking `evals/run_eval.py` benchmarks FinSight against a **no-RAG baseline** on a labeled set of questions about the sample report, with **LangSmith** tracing enabled: - **Expected-answer recall** (RAG vs. baseline) — does RAG recover the ground-truth figures? - **Citation coverage** — fraction of answers carrying `[n]` citations. - **Groundedness** — an LLM-as-judge score that the answer is supported by the retrieved evidence. This demonstrates the optional *formal evaluation metrics and baseline benchmarking* enhancement. ## Tech Stack LangGraph · LangChain · Google Gemini · FastAPI · **Qdrant** · PostgreSQL · Redis · ARQ · Cloudinary · **MCP** · LangSmith · ruff · pytest · Docker Compose. ## Reproduce ```bash cp .env.example .env # set GOOGLE_API_KEY (free: aistudio.google.com/apikey) docker compose up -d --build # postgres, qdrant, redis, mcp, api, worker docker compose exec api alembic upgrade head cd frontend && npm install && npm run dev # → http://localhost:5173 ``` A ready-made report ships in the repo at `samples/sample_financial_report.docx` (*Nimbus Cloud Inc. FY2024*). Sign up (email verification auto-passes in dev mode), create a topic, upload the sample, then try: | Ask | What to expect | |-----|----------------| | `What was Q4 2024 revenue and net income?` | Grounded **$1,180M / $262M** with a `[1]` citation | | `Plot quarterly revenue for 2024 as a chart` | A line/bar chart (820 → 910 → 1,015 → 1,180) | | `Show revenue breakdown by segment as a pie chart` | A pie (Cloud 50% · Data 28% · AI 22%) | ```bash # benchmark RAG vs. a no-RAG baseline (LangSmith tracing on) docker compose exec api python -m evals.run_eval ``` The full reviewer walkthrough lives in the repo `README.md` → *Quick demo (for reviewers)*. ## Sample Interaction > **Q:** What does NVIDIA do and what is its most recent reported quarterly revenue? > > **A:** NVIDIA is a technology company focused on AI products and data centers [4, 5]. For Q2 > fiscal 2026, NVIDIA reported revenue of $46.7 billion, +56% year-over-year [3]. > > *Sources:* [3] investor.nvidia.com · [2] Wikipedia · [4] TradingView · [5] Yahoo Finance The Supervisor routed to Market Research (live web needed), which called the MCP `web_search` tool; the Writer cited the sources and the Critic approved. ## Limitations & Future Work - Keyword retrieval currently uses Qdrant full-text matching; a sparse-vector (BM25) leg would strengthen hybrid ranking. - A cross-encoder reranker is pluggable but disabled by default to avoid heavy model downloads. - Gemini's free tier is rate-limited; throttled replies are surfaced in the UI with a retry hint. - The whole stack runs locally via Docker Compose; cloud hosting is left as future work. ## Maintenance & Support ### Versioning FinSight uses milestone-based versioning aligned to the AAIDC course modules: | Version | Repository | Status | Notes | |---------|-----------|--------|-------| | **v1.0 — Module 2** | [finsight-multi-agent](https://github.com/phanminhtai23/finsight-multi-agent) | Stable | This submission — multi-agent RAG, MCP tools, React UI, Docker Compose. | | **v2.0 — Module 3** | [finsight-agentic-production](https://github.com/phanminhtai23/finsight-agentic-production) | Active | Production hardening: reliability, safety guardrails, observability, CI/CD (auto-test + auto-deploy), live at [finsightagent.tech](https://finsightagent.tech). | The Module 2 repository is the reference implementation; Module 3 is the maintained, deployed successor that builds directly on it. ### Update frequency - **Bug fixes** — addressed on an as-needed basis via pull request to the relevant branch. - **Feature additions** — follow course milestone cadence; each milestone closes an increment and tags a release. - **Dependency updates** — `ruff`, LangGraph, and LangChain receive periodic upgrades; changes are validated by the `pytest` suite before merging. ### Support channels | Channel | Purpose | |---------|---------| | **GitHub Issues** — [finsight-multi-agent/issues](https://github.com/phanminhtai23/finsight-multi-agent/issues) | Bug reports, feature requests, setup questions for the Module 2 codebase. | | **GitHub Issues** — [finsight-agentic-production/issues](https://github.com/phanminhtai23/finsight-agentic-production/issues) | Issues related to the production deployment (Module 3). | | **Live demo** — [finsightagent.tech](https://finsightagent.tech) | Try the production version without installing anything — useful for verifying behavior before filing a bug. | | **Swagger UI** — `/docs` (when running locally) | Interactive API documentation for all REST endpoints; available at `http://localhost:8000/docs` after `docker compose up`. | For general questions about the AAIDC programme contact the Ready Tensor team through the course platform. ## Repository & Quality - Code: https://github.com/phanminhtai23/finsight-multi-agent - `pytest` unit tests, `ruff`-clean, full SOLID layering, runs entirely via Docker Compose. --- **Tags:** `multi-agent` · `langgraph` · `rag` · `mcp` · `agentic-ai` · `financial-analysis` · `qdrant` · `fastapi` · `react` · `llm` · `google-gemini` · `hybrid-search` · `contextual-retrieval` · `aaidc` 48:T1d6e,# Multi-Agent System: AI Project Improver 🚀 ![single-vs-mas.png](single-vs-mas.png) ## Overview AI Project Improver is a multi-agent system built using LangGraph that analyzes GitHub project descriptions and generates improved titles, summaries, tags, and feedback. The goal of this system is to simulate a real-world AI pipeline where different agents collaborate to produce structured and meaningful outputs. ## Architecture The system consists of four main agents: * **Analyzer Agent**: Understands the project description * **Generator Agent**: Creates a refined title and summary * **Tag Agent**: Generates relevant tags using keyword extraction and LLM refinement * **Critic Agent**: Reviews the output and provides improvement feedback These agents are orchestrated using LangGraph, enabling parallel execution and structured state management. ## Tools Integration To improve reliability, the system integrates tools: * Text Cleaner → preprocesses noisy input * Keyword Extractor → improves tag generation This combination of tools and LLM reduces hallucination and improves output quality. ## Key Features * Multi-agent architecture * Tool + LLM integration * Structured outputs * Parallel processing with LangGraph * Feedback loop using critic agent ![1_3ja8oBP8ZRwEoC46_kXNAg.png](1_3ja8oBP8ZRwEoC46_kXNAg.png) ## Sample input 1 # GitHub MCP Server The GitHub MCP Server connects AI tools directly to GitHub's platform. This gives AI agents, assistants, and chatbots the ability to read repositories and code files, manage issues and PRs, analyze code, and automate workflows. All through natural language interactions. # Use Cases Repository Management: Browse and query code, search files, analyze commits, and understand project structure across any repository you have access to. Issue & PR Automation: Create, update, and manage issues and pull requests. Let AI help triage bugs, review code changes, and maintain project boards. CI/CD & Workflow Intelligence: Monitor GitHub Actions workflow runs, analyze build failures, manage releases, and get insights into your development pipeline. Code Analysis: Examine security findings, review Dependabot alerts, understand code patterns, and get comprehensive insights into your codebase. Team Collaboration: Access discussions, manage notifications, analyze team activity, and streamline processes for your team. Built for developers who want to connect their AI tools to GitHub context and capabilities, from simple natural language queries to complex multi-step agent workflows. ## Sample Output 1 === FINAL OUTPUT === Title: GitHub MCP Server: AI-Powered GitHub Interaction Bridge Summary: The GitHub MCP Server acts as a bridge connecting AI tools (agents, assistants, chatbots) to the GitHub platform, enabling natural language interaction with repositories, issues, pull requests, CI/CD, and code analysis features. It allows AI to manage GitHub resources, automate workflows, analyze code, and enhance team collaboration through plain language commands. The specific technologies used to build the server are not mentioned, but it integrates with GitHub's platform and facilitates natural language interactions for AI clients. Tags: ['Open Source Projects', 'Server Administration', 'GitHub Collaboration', 'DevOps Tools', 'Python DevOps'] Feedback: Here's short feedback to improve quality: 1. **Clarify "MCP":** The acronym "MCP" in the title and summary is undefined. Either spell it out (e.g., "Master Control Program," "Microsoft Certified Professional" - though unlikely here, it highlights the ambiguity) or remove it if it's not a critical, widely recognized identifier for the project. 2. **Integrate Tech Stack:** The summary explicitly states "The specific technologies used to build the server are not mentioned." This is a missed opportunity. Briefly mentioning the core language (e.g., Python, Node.js) or key frameworks (e.g., FastAPI, Flask, Express) would significantly enhance understanding and appeal, especially since "Python DevOps" is a tag. 3. **Refine Summary's Last Sentence:** Remove the self-referential sentence "The specific technologies used to build the server are not mentioned..." as it points out a gap rather than describing the project. Instead, fill that gap with actual tech details. 4. **Enhance Tags:** * Add more specific AI/NLP tags (e.g., `AI Agents`, `Natural Language Processing`, `LLM Integration`). * Consider if `Server Administration` is the most precise tag; `API Server` or `Backend Service` might be more accurate depending on its primary function. ## Sample Input 2 ## 🤖 Awesome GitHub Copilot Powered by Awesome Copilot GitHub contributors from allcontributors.org A community-created collection of custom agents, instructions, skills, hooks, workflows, and plugins to supercharge your GitHub Copilot experience. ## Tip Explore the full collection on the website → awesome-copilot.github.com The website offers full-text search and filtering across hundreds of resources, plus the Tools section for MCP servers and developer tooling, and the Learning Hub for guides and tutorials. Using this collection in an AI agent? A machine-readable llms.txt is available with structured listings of all agents, instructions, and skills. ## 📖 Learning Hub New to GitHub Copilot customization? The Learning Hub on the website offers curated articles, walkthroughs, and reference material — covering everything from core concepts like agents, skills, and instructions to hands-on guides for hooks, agentic workflows, MCP servers, and the Copilot coding agent. ## Sample Output 2 === FINAL OUTPUT === Title: Awesome GitHub Copilot Project Analysis Summary: The "Awesome GitHub Copilot" project is a community-driven, open-source collection of resources designed to enhance GitHub Copilot. It offers a wide array of custom agents, instructions, skills, hooks, workflows, and plugins, accessible via a dedicated website with search and filtering. The project also provides a learning hub with articles and guides, and its resources are available in a machine-readable `llms.txt` format for AI agent integration. It leverages GitHub Copilot, various AI components, and supports MCP servers and general developer tooling. Tags: ['Python Mini-Projects', 'Open Source Projects', 'Beginner Skill Building', 'Web Development Tutorials', 'Learning Resources'] Feedback: Here's short feedback to improve quality: 1. **Title:** The title "Awesome GitHub Copilot Project Analysis" sounds like an analysis *of* the project, not the project's own title. Consider simply "Awesome GitHub Copilot" or "Awesome GitHub Copilot Project" if this is meant to be the project's public-facing name. 2. **Summary:** Clarify or expand on "MCP servers" in the summary, as the acronym might not be universally understood. 3. **Tags:** The tags are a bit generic. Make them more specific to the project's core focus (e.g., 'GitHub Copilot Resources', 'AI Agent Development', 'Copilot Customization', 'Developer Tools'). 'Python Mini-Projects', 'Beginner Skill Building', and 'Web Development Tutorials' aren't explicitly supported by the summary and might be misleading. ## Conclusion This project demonstrates how modern AI systems are built using multiple agents, tools, and orchestration frameworks. Instead of relying on a single LLM, the system distributes tasks across specialized agents, making it more scalable, modular, and closer to real-world AI applications. 49:T4b92,![banner.png](banner.png) # Abstract This project presents Bus Driver Assistant, a modular multi-agent AI system developed for real-time safety monitoring in public transportation. The system leverages computer vision and intelligent agents to detect driver fatigue, monitor passengers, and deliver timely voice alerts. The system utilizes MediaPipe Face Mesh for Eye Aspect Ratio (EAR)-based fatigue detection and YOLOv8 for real-time passenger counting and object detection (such as red hats). A LangGraph-based 5-agent architecture (Supervisor, Driver, Passenger, Operations, and Query Agents) coordinates decision-making and task routing. Offline voice alerts are generated using pyttsx3, while ChromaDB enables semantic memory and natural language querying over logged events. This work demonstrates a complete integration of multi-agent systems, computer vision, voice interaction, and memory management. By combining these technologies, the Bus Driver Assistant provides a practical, affordable, and scalable solution to combat driver fatigue — one of the leading causes of road accidents in public transport. # Introduction Road safety remains a critical global challenge, with driver fatigue being one of the leading causes of accidents in public transportation. According to various studies, fatigue-related incidents account for a significant percentage of road crashes, particularly among commercial and long-distance bus drivers. Traditional monitoring methods are often manual, inconsistent, and lack real-time intervention capabilities. The Bus Driver Assistant was developed to address this pressing issue by creating an intelligent, affordable, and proactive AI-powered safety system. This project explores the application of multi-agent AI architectures in real-world scenarios, combining advanced computer vision, voice interaction, and memory systems to assist bus drivers and enhance passenger safety. This system goes beyond simple detection — it actively monitors the driver’s alertness using Eye Aspect Ratio analysis, tracks passengers in real-time, delivers timely voice alerts, logs important events, and allows natural language interaction through a multi-agent framework powered by LangGraph and Gemini 3 Flash. The primary goal of this project is to demonstrate how modern AI technologies can be practically integrated into a cohesive, modular system that can potentially save lives by preventing fatigue-related accidents in public transport. # Related work Driver fatigue detection and passenger monitoring have been extensively studied in the field of Intelligent Transportation Systems (ITS). Early approaches relied on physiological sensors such as EEG and ECG [1], or vehicle telemetry (steering wheel movement, lane deviation) [2]. However, these methods are often intrusive and difficult to deploy at scale. Vision-based methods have become dominant due to their non-intrusive nature. Works by Ji et al. (2004) pioneered the use of eye tracking for fatigue detection. More recent studies have leveraged deep learning: Deng et al. (2020) proposed a CNN-based fatigue detection system achieving high accuracy using facial landmarks. Systems using OpenFace and DLib have been widely adopted for real-time facial analysis [3]. YOLO-based object detection has been successfully applied for passenger counting and occupancy detection in public transport [4]. In the multi-agent domain, frameworks such as AutoGen (Microsoft, 2023), CrewAI, and LangGraph (LangChain) have enabled sophisticated agent collaboration. However, most implementations focus on software engineering, research assistance, or general chat agents rather than safety-critical, real-time applications. Voice-enabled systems in vehicles are typically limited to infotainment (e.g., Android Auto, Apple CarPlay). Very few projects integrate real-time computer vision, multi-agent orchestration, offline voice synthesis, and semantic memory into one unified system for public transportation. This project, Bus Driver Assistant, differentiates itself by combining: MediaPipe Face Mesh for lightweight, real-time Eye Aspect Ratio (EAR) calculation Ultralytics YOLOv8 for efficient passenger and object detection LangGraph for structured multi-agent workflow ChromaDB for vector-based event memory and semantic search pyttsx3 for reliable offline Text-to-Speech alerts By integrating these modern open-source tools, this work bridges the gap between academic research and practical, deployable AI safety solutions. # Methodology The Bus Driver Assistant was built using a modular multi-agent architecture orchestrated with LangGraph. The system processes live video input, analyzes it through specialized tools, and coordinates responses via intelligent agents. 1. Computer Vision Pipeline Fatigue Detection (using Eye Aspect Ratio): **Vision Tool - Fatigue Detection** (`tools/vision_tool.py`) ```python @tool def computer_vision_tool(task: str = "analyze") -> str: """Analyze current camera frame for driver fatigue.""" cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) ret, frame = cap.read() cap.release() # Fatigue Detection using MediaPipe rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) results = face_mesh.process(rgb) if results.multi_face_landmarks: for lm in results.multi_face_landmarks: left = lm.landmark[159].y - lm.landmark[145].y right = lm.landmark[386].y - lm.landmark[374].y ear = (left + right) / 2 if ear < 0.018: return "Driver is DROWSY" return "Driver is alert" ``` Passenger & Red Hat Detection uses YOLOv8 + HSV color filtering. 2. Multi-Agent Architecture The system uses LangGraph to create a graph of 5 agents coordinated by a Supervisor: ```Python# core/graph.py (Simplified) workflow.add_node("supervisor", supervisor_agent) workflow.add_node("driver_agent", driver_agent) workflow.add_node("passenger_agent", passenger_agent) workflow.add_node("query_agent", query_agent) workflow.add_conditional_edges("supervisor", routing_function) ``` 3. Event Memory & Querying ```Python# tools/event_search_tool.py @tool def event_search_tool(query: str) -> str: results = collection.query(query_texts=[query], n_results=10) if not results['documents'][0]: return "No matching events found." return "\n".join(results['documents'][0]) ``` 4. Voice Agent ```Python# utils/voice.py class VoiceAgent: def speak_drowsy_alert(self): self.speak("Driver, you appear drowsy. Please pull over and take a break.") ``` 5. Tool Integration Four custom LangChain tools were developed: ``` computer_vision_tool() — Real-time vision analysis event_search_tool() — Semantic search over logs web_search_tool() — External information retrieval math_calculation_tool() — Basic calculations ``` To evaluate the effectiveness and robustness of the Bus Driver Assistant, a series of real-time experiments were conducted in a controlled indoor environment simulating a bus setting. 1. Experimental Setup Hardware: Standard webcam (720p), Windows 10 laptop LLM: Google Gemini 3 Flash Preview Environment: Well-lit room with single subject acting as driver Duration: Multiple 30–60 minute continuous monitoring sessions Testing Scenarios: Normal driving (alert state) Simulated fatigue (eye closure, yawning) Different passenger counts (0 to 5 people) Red hat/object detection tests Natural language queries 2. Evaluation Metrics ### Performance Evaluation | Component | Metric | Result | Notes | |-----------------------------|-------------------------------|-----------------|------------------------------------| | Fatigue Detection | Accuracy | 91.5% | Based on 200 manual eye closure tests | | Passenger Counting | Accuracy | 87.3% | Improved with spatial zoning | | Red Hat Detection | Precision | 94.0% | HSV color filtering | | Query Response Time | Average | 1.8 seconds | Using Gemini 3 Flash | | Voice Alert Success Rate | Reliability | 98% | pyttsx3 offline TTS | | System Stability | Uptime (2-hour test) | 99.2% | Continuous monitoring | ### 🎥 Live Demo Video [![Watch Demo Video](https://github.com/pascalizu/bus-driver-assistant/raw/main/screenshots/camera_feed.png)](https://youtu.be/ZX-ffm6phC4) *Click the image to watch the full demonstration showing real-time fatigue detection, voice alerts, and query mode.* **Additional Screenshots:** **Terminal Output with Voice and Query Mode** [![Terminal Output](terminal_output.png)](https://github.com/pascalizu/bus-driver-assistant/raw/main/screenshots/terminal_output.png) 3. Qualitative Observations The system responded well to natural language queries such as “Was the driver drowsy?” and “How many passengers are there?” Voice alerts were clear and timely with appropriate cooldowns to avoid spamming. The Supervisor Agent demonstrated reasonable routing decisions in most cases. Real-time performance was smooth on standard hardware (no GPU required). 4. Limitations Current fatigue detection relies solely on eye openness (can be affected by lighting and head angle) Passenger counting accuracy drops in crowded or low-light conditions No formal dataset was used for training (real-time inference only) ### Testing & Evaluation **Test Cases Performed:** - 200+ manual fatigue tests (eye closure) - Multiple passenger count scenarios (0–5 people) - Red hat detection tests - Natural language queries (20+ different questions) - Voice alert reliability (manual + automatic) **Evaluation Method:** - Real-time testing with live webcam - Manual verification of agent routing accuracy - Response time measurement - System stability over 2-hour runs # Results The Bus Driver Assistant was successfully implemented and tested under real-time conditions. The system demonstrated reliable performance across its core functionalities. 1. System Performance Summary Real-time camera feed and vision processing worked smoothly. Fatigue detection triggered correctly during eye closure tests. Passenger counting and red hat detection functioned as expected. Voice alerts (automatic and manual) were clear and timely. Multi-agent routing and query mode responded well to natural language inputs. 2. Key Achievements Successfully built a 5-agent system using LangGraph. Integrated 4 functional tools with real computer vision. Achieved working offline voice alerts. Implemented semantic memory with ChromaDB. Completed a clean, modular project structure. 3. Challenges Faced During development, several technical challenges were encountered and resolved: MediaPipe Installation Issues: The solutions module error on Windows was resolved by downgrading to mediapipe==0.10.14. Gemini API Compatibility: LangGraph tool calling had compatibility issues with Gemini 3 Flash. Solved by implementing a manual ReAct loop in query mode. Import Path Problems: Modular structure caused frequent ModuleNotFoundError. Fixed by adding proper sys.path handling and __init__.py files. Routing Inconsistencies: The Supervisor Agent sometimes routed queries incorrectly. Improved by refining keyword-based routing logic. Real-time Performance: Initial versions had lag and hallucinated responses. Addressed by optimizing vision tool calls and strengthening system prompts. API Key Exposure: Accidental commit of Gemini API key was resolved by switching to .env file and cleaning Git history. These challenges provided valuable learning in debugging, modular design, and production-ready AI development. # Discussion The development of the Bus Driver Assistant has been a comprehensive journey in building a practical, real-world AI safety system. What began as a simple fatigue detection script evolved into a fully modular multi-agent architecture capable of monitoring, reasoning, and interacting with its environment in real time. One of the most rewarding aspects of this project was witnessing the Supervisor Agent successfully coordinate different specialized agents. When asked about driver fatigue, the system correctly routed the query to the Driver Agent. Similarly, passenger-related questions were appropriately directed to the Passenger Agent. This dynamic routing demonstrates the power and flexibility of LangGraph in orchestrating intelligent behavior. The integration of multiple technologies worked remarkably well together. MediaPipe provided lightweight and efficient facial landmark detection, while YOLOv8 delivered fast passenger detection. Combining these with offline voice alerts through pyttsx3 created a truly interactive experience. The addition of ChromaDB for semantic memory also allowed the system to remember and retrieve past events through natural conversation. However, the journey was not without challenges. Early versions suffered from inconsistent agent routing, slow response times, and occasional hallucinations. Debugging import issues in the modular structure and resolving MediaPipe compatibility problems on Windows taught valuable lessons in software engineering and persistence. Switching to a .env file for API key management was also a critical improvement for security. Overall, this project successfully demonstrated that a cohesive, multi-agent AI system can be built using accessible modern tools. It stands as a solid proof-of-concept for how AI can be applied to solve meaningful problems in transportation safety — moving beyond theoretical models to a working, interactive prototype. # Conclusion The Bus Driver Assistant successfully demonstrates how modern AI technologies can be integrated into a practical, real-time safety system for public transportation. Through this project, a fully functional multi-agent architecture was developed that combines computer vision, intelligent decision-making, voice interaction, and semantic memory. Key accomplishments include: Real-time driver fatigue detection using Eye Aspect Ratio analysis Passenger monitoring and object detection with YOLOv8 A working 5-agent system orchestrated by LangGraph Seamless integration of voice alerts and natural language querying A clean, modular, and maintainable codebase This project has shown that accessible open-source tools — such as MediaPipe, YOLOv8, LangGraph, ChromaDB, and Gemini — can be combined to create meaningful solutions for real-world problems. More importantly, it highlights the potential of AI in addressing critical safety challenges like driver fatigue, which continues to claim lives on our roads. While the current version serves as a solid proof-of-concept, the modular design provides a strong foundation for future enhancements such as improved fatigue models, edge deployment, and fleet-wide monitoring. In conclusion, the Bus Driver Assistant stands as a testament to the power of multi-agent AI systems in creating impactful, human-centered technology. It represents not just a technical achievement, but a step toward safer roads and smarter transportation system # Maintenance & Support **Ongoing Maintenance** - Actively maintained by the author. - Bug reports via GitHub Issues. - Modular structure for easy extension. **Support Channels** - GitHub Issues - Comprehensive README.md # References References [1] Ji, Q., & Yang, X. (2002). Real-time eye, gaze, and face pose tracking for monitoring driver vigilance. IEEE Transactions on Intelligent Transportation Systems, 3(1), 63-77. [2] Bergasa, L. M., et al. (2006). Real-time system for monitoring driver vigilance. IEEE Transactions on Intelligent Transportation Systems, 7(1), 63-77. [3] Baltrusaitis, T., Zadeh, A., Lim, Y. C., & Morency, L. P. (2018). OpenFace 2.0: Facial behavior analysis toolkit. IEEE Winter Conference on Applications of Computer Vision (WACV). [4] Jocher, G., et al. (2023). Ultralytics YOLOv8. Available at: https://github.com/ultralytics/ultralytics [5] LangChain Documentation. (2024). LangGraph - Build Reliable Multi-Agent AI Systems. Retrieved from https://python.langchain.com/docs/langgraph [6] Google AI. (2025). Gemini 3 Flash Preview Model Card. Google AI Studio. [7] MediaPipe Team. (2023). MediaPipe Face Mesh. Google Research. https://developers.google.com/mediapipe/solutions/face_mesh [8] ChromaDB Documentation. (2024). Chroma Vector Database. https://docs.trychroma.com/ # Acknowledgements I would like to express my deepest gratitude to the people who supported me throughout this journey. First and foremost, I thank Grok by xAI for its invaluable guidance, patience, and technical support from the initial idea through to the final modular implementation. I am also grateful to the Ready Tensor platform for providing the structure and opportunity to build this comprehensive multi-agent system as part of Module 2. Special thanks to the open-source community behind the powerful tools used in this project: MediaPipe, YOLOv8, LangGraph, ChromaDB, and pyttsx3. Most importantly, I want to thank my loving wife, Peace Nwokike, and our daughter, Miracle Nwokike, for their unwavering support, understanding, and encouragement during the many late nights and long hours dedicated to this project. This work is as much theirs as it is mine. # Appendix Appendix A. Project Structure (Full) ``` bus-driver-assistant/ ├── main.py # Entry point ├── requirements.txt ├── README.md ├── .env # (Git ignored) ├── .gitignore │ ├── core/ │ └── graph.py # LangGraph orchestration ├── agents/ │ ├── supervisor.py │ ├── driver_agent.py │ ├── passenger_agent.py │ ├── operations_agent.py │ └── query_agent.py ├── tools/ │ ├── vision_tool.py │ ├── event_search_tool.py │ ├── web_search_tool.py │ └── math_tool.py ├── vision/ │ └── detector.py └── utils/ └── voice.py ``` B. Key Code Snippets 1. Vision Tool (Fatigue Detection) ```@tool def computer_vision_tool(task: str = "analyze") -> str: # ... (MediaPipe EAR calculation) if ear < 0.018: return "Driver is DROWSY" return "Driver is alert" ``` 2. Voice Agent ```class VoiceAgent: def speak_drowsy_alert(self): self.speak("Driver, you appear drowsy. Please pull over and take a short break.") ``` C. Installation Commands ```pip install opencv-python mediapipe ultralytics chromadb pyttsx3 pip install langchain-google-genai langgraph duckduckgo-search ddgs ``` D. Controls Summary ``` q → Switch to Query Mode v → Trigger manual voice announcement Close eyes → Automatic drowsy voice alert ``` This Appendix provides useful technical reference material for reviewers.4a:T4a50,![touri_thumbnaile.png](touri_thumbnaile.png) # TL; DR Touri is an AI-powered multi-agent travel planner built with CrewAI and Groq LLMs. It uses specialized agents for flights, accommodations, and itinerary generation, integrating real-time APIs like FlightAPI.io, Booking.com, OpenWeatherMap, and currency exchange services. Given user travel preferences, Touri automatically creates a complete trip plan with live flight and hotel options, weather-aware itineraries, budget summaries, and PDF export through an interactive Streamlit interface. # Introduction Travel planning often requires users to search across multiple platforms for flights, hotels, weather forecasts, currency exchange rates and local activities. This process is time-consuming, fragmented and difficult to optimize, especially when balancing budget, convenience and personal preferences. Traditional travel applications typically provide isolated services rather than an intelligent end-to-end planning experience. Recent advances in Large Language Models (LLMs) and Agentic AI systems have enabled the development of autonomous agents capable of reasoning, tool usage and collaborative decision-making. Multi-agent architectures are particularly effective for complex tasks because they divide responsibilities among specialized agents that work together toward a common objective. Touri is an AI-powered multi-agent travel planning system designed to automate the entire trip planning workflow. Built using CrewAI and powered by Groq LLM inference, the platform coordinates specialized agents for flight search, accommodation discovery and itinerary generation. Each agent interacts with real-world APIs to retrieve live travel data, ensuring accurate and up-to-date recommendations. The system combines these outputs into a structured travel plan that includes transportation, lodging, weather-aware itineraries, budget summaries and PDF export functionality through an interactive Streamlit interface. # Problem of Statement Planning a complete trip manually is inefficient because travel information is distributed across multiple disconnected services. Users must repeatedly compare flight prices, hotel availability, weather conditions, transportation options and activity schedules while also managing budget constraints and personal travel preferences. This leads to: - High planning time and cognitive overload - Difficulty optimizing travel decisions across multiple factors - Inconsistent or outdated information between platforms - Limited personalization in traditional travel systems - Lack of intelligent coordination between travel components Existing travel platforms primarily focus on individual tasks such as booking flights or hotels, rather than providing an autonomous, integrated planning experience. Furthermore, many AI-based systems rely heavily on static datasets or generated responses without grounding their outputs in real-time external data. # Solution: AI-Powered Digital Travel Agency Touri functions as an AI-powered digital travel agency that automates the complete travel planning process through a collaborative multi-agent architecture. Instead of requiring users to manually search across multiple platforms, the system intelligently coordinates specialized AI agents to handle different travel-related tasks in parallel. The platform integrates real-time APIs for flights, accommodations, weather forecasting, and currency conversion, enabling the system to generate accurate and data-driven travel recommendations. Each agent is responsible for a specific domain: - Flight Specialist Agent → Finds optimal flight options based on price, duration, and convenience. - Accommodation Specialist Agent → Searches for hotels and stays aligned with user preferences and budget. - Itinerary Planner Agent → Creates realistic day-by-day travel schedules using destination insights and weather conditions. These agents collaborate under a central orchestration layer powered by CrewAI, producing a unified travel plan tailored to the user’s preferences, budget and travel dates. By combining Agentic AI, Large Language Models and real-time tool integration, Touri transforms traditional travel planning into an intelligent, automated and personalized digital travel agency experience. # Methodology ## System Architecture The system is designed as a sequential multi-agent pipeline where specialized AI agents collaborate to automate the entire travel planning workflow. Instead of relying on a single monolithic model, the architecture decomposes the planning process into smaller domain-specific tasks handled independently by dedicated agents. The workflow begins with user input containing travel preferences such as destination, dates, budget, and travel style. The request is then processed through three autonomous agents in sequence: 1. FlightAgent — retrieves real-time flight options. 2. AccommodationAgent — searches for suitable hotels and stays. 3. ItineraryAgent — generates a weather-aware daily travel itinerary. Finally, the outputs are merged into a structured travel plan and presented through an interactive Streamlit user interface. User Input ↓ FlightAgent ↓ AccommodationAgent ↓ ItineraryAgent ↓ Travel Plan Assembly ↓ Streamlit UI + PDF Export ## Multi-Agent Design All agents inherit from a shared BaseTravelAgent class responsible for LLM initialization, retry handling, tool registration, shared CrewAI configuration. This abstraction enables consistent behavior across all agents while simplifying scalability and maintenance. ```python class BaseTravelAgent: GROQ_MODELS = { "llama-70b": "llama-3.3-70b-versatile", "llama-8b": "llama-3.1-8b-instant", "gpt-oss-20b": "openai/gpt-oss-20b", "gpt-oss-120b": "openai/gpt-oss-120b", } def __init__(self, model: str = "llama-70b", temperature: float = 0.3): self.llm = LLM( model=f"groq/{self.GROQ_MODELS[model]}", temperature=temperature, max_retries=6, ) ``` The modular design allows new agents or tools to be integrated into the system without modifying the orchestration logic. ## Flight Agent The FlightAgent is responsible for retrieving real-time flight information using FlightAPI.io. The agent receives the user’s origin, destination, travel date, passenger count, and travel class, then invokes the API through a structured CrewAI tool. The system uses the official FlightAPI.io path-parameter format: GET https://api.flightapi.io/onewaytrip/{api_key}/{origin}/{dest}/{date}/{adults}/0/0/{class}/USD The API response contains multiple cross-referenced collections such as itineraries, legs, segments, carriers, places. The agent resolves these references into clean structured flight objects that include airline name, price, departure time, arrival time, duration, layovers, and booking links. ## Accommodation Agent The AccommodationAgent handles hotel and accommodation discovery through the Booking.com RapidAPI integration. The workflow follows a two-stage retrieval process. First, the destination city is converted into a Booking.com destination identifier using the locations endpoint: /v1/hotels/locations. After retrieving the dest_id, the system performs a hotel availability search using: /v1/hotels/search. The agent filters and structures accommodation results based on pricing, amenities, review score, hotel type and location relevance. This enables the planner to provide realistic lodging recommendations aligned with the user’s budget and travel preferences. ## Itinerary Agent The ItineraryAgent generates personalized day-by-day travel schedules using destination context, user interests and weather conditions. The agent integrates the OpenWeatherMap API to retrieve weather forecasts for the travel period. This allows the itinerary generation process to account for environmental conditions when selecting activities. The generated itineraries include: - morning, afternoon, and evening activities - sightseeing recommendations - meal suggestions - estimated costs - realistic scheduling between locations This approach creates itineraries that are both practical and context-aware rather than purely generative. ## Tool Schema Design One of the key technical challenges when integrating Groq with CrewAI tools is ensuring compatibility with function-calling schemas. Groq’s API requires every tool to expose an explicit Pydantic schema containing clearly defined properties. Without a valid schema definition, the API raises a BadRequestError indicating that the required field exists without corresponding properties. To address this, each tool defines an explicit args_schema using Pydantic models. ```python class FlightSearchInput(BaseModel): origin: str = Field(..., description="Departure airport IATA code") destination: str = Field(..., description="Arrival airport IATA code") departure_date: str = Field(..., description="Date in YYYY-MM-DD format") return_date: Optional[str] = Field(default=None) adults: int = Field(default=1) travel_class: str = Field(default="ECONOMY") ``` This design ensures reliable function calling, input validation, predictable tool execution and improved interoperability with Groq LLMs. ## Output Parsing and Validation Large language models frequently generate responses wrapped in markdown code blocks or mixed with explanatory text. To guarantee reliable parsing, the project implements a custom JSON extraction mechanism based on balanced brace tracking. The parser scans character-by-character while tracking nested braces and quoted strings to safely identify the first complete JSON object. ```python def safe_parse_json(text: str): # Strip markdown code blocks if text.startswith("```"): text = text.split("```")[1] # Balanced brace parsing logic ``` This significantly improves robustness when handling imperfect LLM outputs. ### Post-Processing Pipeline After all agents complete execution, the system applies a deterministic post-processing stage to ensure consistency and correctness. The _create_travel_plan() pipeline performs several corrections: ### Date Normalization LLM-generated dates are overridden using the actual trip start date and itinerary day number. ### Currency Conversion A single exchange rate is fetched and consistently applied across all travel costs. ### Weather Attachment The weather forecast is appended directly to the final travel plan. ### Budget Aggregation Flight, accommodation, and activity costs are summed to generate a complete budget breakdown. This hybrid approach combines LLM reasoning with deterministic validation for greater reliability. ## Target Audience Touri is designed for both technical and non-technical users interested in intelligent travel automation and AI-driven planning systems. ### Travelers Individuals looking for an automated and personalized way to plan trips without manually browsing multiple platforms for flights, hotels, weather and activities. ### Travel Agencies and Startups Companies seeking to modernize travel planning workflows using AI agents and real-time API integrations. ### AI and Software Engineers Developers interested in multi-agent systems, CrewAI orchestration, LLM tool calling, real-world API integration and Agentic AI applications. ### Researchers and Students Learners exploring practical applications of autonomous AI agents, travel recommendation systems, LLMs and AI workflow orchestration. ## Sample Vacation Plan ### Input ```json { "departure_city": "Addis Ababa", "destination_city": "Paris", "start_date": "2026-07-10", "end_date": "2026-07-15", "budget": 2500, "currency": "USD", "preferences": { "travel_style": "comfort", "accommodation_preference": "hotel", "flight_class": "economy", "interests": [ "culture", "museums", "food", "architecture" ] } } ``` ### Output ```json { "flights": [ { "airline": "Air France", "departure_time": "2026-07-10 08:15", "arrival_time": "2026-07-10 15:45", "duration": "7h 30m", "price": 780 } ], "accommodations": [ { "name": "Paris Central Hotel", "price_per_night": 160, "total_price": 800, "amenities": [ "Free WiFi", "Breakfast", "Airport Shuttle" ] } ], "daily_itinerary": [ { "day": 1, "activities": [ "Eiffel Tower Visit", "Seine River Cruise", "French Dinner Experience" ] }, { "day": 2, "activities": [ "Louvre Museum", "Notre-Dame Cathedral", "Montmartre Walking Tour" ] } ], "weather_forecast": { "average_temperature": "24°C", "condition": "Partly Cloudy" }, "budget_summary": { "flights": 780, "accommodation": 800, "activities": 450, "total": 2030 } } ``` # Demo Video A demonstration video showcasing the end-to-end workflow of Touri. ::youtube[touri video]{#0gjwJ4k-BtE} ## Project Metadata ### Project Name Touri — AI Multi-Agent Travel Planner ### Architecture The project follows a modular multi-agent architecture powered by CrewAI. Frontend (Streamlit UI) ↓ TravelCrew Orchestrator ↓ ┌───────────────────────┐ │ Flight Agent │ ├───────────────────────┤ │ Accommodation Agent │ ├───────────────────────┤ │ Itinerary Agent │ └───────────────────────┘ ↓ External APIs + LLM Tools ### Core Technologies CrewAI Groq LLMs Python Streamlit Pydantic LiteLLM ### APIs Integrated | API |Purpose | | --- | --- | | FlightAPI.io | Real-time flight search | | Booking.com RapidAPI | Hotel and accommodation search | | OpenWeatherMapI | Weather forecasts | | ExchangeRate API | Currency conversion | | Groq API | LLM inference | ### Configuration The application requires the following environment variables: GROQ_API_KEY=your_groq_key FLIGHT_API_KEY=your_flightapi_key RAPIDAPI_KEY=your_rapidapi_key OPENWEATHER_API_KEY=your_weather_key EXCHANGE_RATE_API_KEY=your_exchange_key ### License MIT License This project is open-source and available for educational, research, and commercial usage under the MIT License. ### Documentation The project documentation (README.md) includes: Installation guide Environment setup API configuration Agent workflow explanation Tool integration details ### Code Repository URL GitHub Repository: https://github.com/endx-star/Touri # Experiments ### Experiment 1 — Tool Schema Validation **Problem:** Groq rejected tool calls with invalid JSON schema ('required' present but 'properties' missing). **Cause:** CrewAI's BaseTool subclasses without args_schema generate schemas with required fields but no properties, which Groq's strict validation rejects. **Fix:** Added explicit Pydantic args_schema to all four tools. Resolved completely. ### Experiment 2 — FlightAPI.io Response Parsing **Problem:** Flight tool returned {"success": true, "data": {"flights": [ ] } } despite a valid API key. **Cause:** The original implementation used query parameters and expected data.status == 'success'. The actual API uses path parameters and returns flat cross-referenced arrays. **Fix:** Rewrote URL construction and response parser to match the actual API contract. Flight results populated correctly after fix. ## Experiment 3 — JSON Output Reliability **Problem:** safe_parse_json failed on outputs like 'Here it is: \n{"flights": [ ] }' and {"accommodations": [...]} \n\nGo ahead: \n{"accommo... (two JSON objects). **Cause:** Regex-based extraction with re.DOTALL greedily matched from first { to last }, spanning multiple JSON objects. **Fix:** Replaced regex with balanced brace parser. Correctly extracts the first complete JSON object regardless of surrounding text. ### Experiment 4 — Rate Limit Handling **Problem:** RateLimitError on llama-3.3-70b-versatile (12k TPM) and llama-3.1-8b-instant (6k TPM) during multi-agent execution. **Cause:** Three agents executing back-to-back consumed the full TPM budget within one minute. **Fix:** Split crew into three sequential mini-crews with 12-second pauses. Combined with exponential backoff retry, the system completes successfully on the free tier. # Results The system successfully produces complete travel plans end-to-end with the following components and data sources: | Component | Data Source | | --- | --- | | Flight search |FlightAPI.io | | Hotel search | Booking.com (RapidAPI) | | Itinerary generation | Groq LLM + OpenWeatherMap | | Currency conversion | ExchangeRate API | ### Key findings: Explicit args_schema on all tools is mandatory for Groq function calling without it, 100% of tool calls fail. LLM output is unreliable for structured data without deterministic post-processing. Dates, in particular, must be corrected server-side regardless of prompt instructions. Sequential execution with inter-task pauses is sufficient to stay within free-tier TPM limits for a 3-agent system. Balanced brace parsing is significantly more robust than regex for extracting JSON from LLM output that may contain prose, multiple JSON objects, or markdown formatting. # Conclusion Touri demonstrates that a multi-agent LLM system can reliably orchestrate real-world API calls to produce actionable, structured travel plans. The key engineering insights from this project are: **1.Tool schema correctness is non-negotiable** when using strict function-calling APIs like Groq , Pydantic args_schema must be explicitly defined on every tool. **2. LLM output should be treated as unreliable structured data:** deterministic post-processing (date correction, price conversion, JSON extraction) is essential for production reliability. **3. Rate limit management requires architectural decisions, not just retry logic:** splitting tasks into separate crews with deliberate pauses is more effective than relying solely on backoff. **4. Agent autonomy should be bounded** : max_iter=1 with clear, concise task prompts produces more consistent results than allowing agents to iterate freely, especially under token constraints. Future work could explore parallel agent execution using async CrewAI flows, integration with booking APIs for direct reservation, and a conversational adjustment interface for iterative plan refinement. *Built by Endale Tegegnework powered by Ready Tensor AI course making intelligent travel plannning accessible to everyone*4b:T4eeb,![Banner](_psaImage.jpg) # Automating Enterprise Procurement with a Multi-Agent AI System ## How four specialized AI agents work together to streamline supplier search, cost analysis, and purchasing decisions — built with LangGraph and Claude --- ## TL;DR Procurement teams in mid-to-large enterprises spend significant time manually researching suppliers, validating purchase requests, and preparing recommendations — often repeating the same structured process for every new requisition. **Procurement Assistant** is an early-stage, multi-agent AI system designed to automate this cycle. Built with LangGraph and the Anthropic Claude API, it chains four specialized agents — Intake, Procurement, Analyst, and Orchestrator — each with a clearly defined role and a strict output contract. The result is a fully traceable, policy-driven procurement workflow that goes from a free-text purchase request to a structured final report with a supplier recommendation, cost analysis, and a plain-language decision summary. --- ## 1. Problem Context Enterprise procurement is one of those domains where the process is well-understood, highly structured, and yet still largely manual. In most companies, a purchase request follows a predictable path: 1. Someone submits a request (often informally — email, chat, a form). 2. A procurement specialist validates it against company policy. 3. They research potential suppliers, compare pricing, and assess risk. 4. A decision is made: approve, escalate, or reject. 5. A report or summary is sent back to the requester. The challenge is not that this process is complex — it is actually very structured. The challenge is that it is **time-consuming, repetitive, and heavily dependent on institutional knowledge**: knowing the buying rules, knowing the thresholds, knowing which supplier categories apply to which product types. This is precisely where AI agents can add value. Not by replacing procurement specialists, but by automating the structured, rule-driven parts of the workflow — so that human attention is focused where it genuinely matters: exceptions, strategic decisions, and supplier relationships. **Procurement Assistant** is an attempt to build exactly that. It is a first-version system targeting the core intake-to-decision cycle for procurement requests involving machinery, equipment, vehicles, professional services, and other categories defined in a company's purchasing policy. --- ## 2. Technical Requirements and Design Principles Before diving into the architecture, it is worth stating the design principles that shaped the system — because they explain many of the implementation choices. **Auditability above all.** Every decision made by every agent must reference the specific rule that drove it. A compliance officer must be able to read the decision log and understand the full reasoning chain without external context. **Strict output contracts.** Agents do not produce free-form text. Every agent output is a structured Pydantic model, validated at runtime. If an agent cannot produce valid structured output, the system raises a typed exception (`StructuredOutputError`) rather than passing malformed data downstream. **Separation of concerns.** Each agent does exactly one thing. The Intake Agent does not search for suppliers. The Procurement Agent does not make final decisions. The Orchestrator does not override upstream decisions. This makes the system easier to test, debug, and improve incrementally. **Configuration over hardcoding.** Buying rules, decision thresholds, model selection, and prompt versions are all managed through YAML configuration files. Changing a threshold does not require touching agent code. **Prompt versioning.** System prompts are versioned, checksummed, and changelog-tracked — the same discipline applied to code. --- ## 3. System Architecture The system is built as a **directed agent graph using LangGraph**. Each agent is a separate node in the graph. Nodes communicate exclusively through a shared state object (`SharedState`) — no agent calls another directly. ``` User Input (CLI) │ ▼ ┌──────────────┐ │ Intake │ Validates & classifies the request. │ Agent │ Triggers clarification rounds if required fields are missing. └──────┬───────┘ │ validated_request, category_id, process_type ▼ ┌──────────────┐ │ Procurement │ Searches for suppliers using web search, PDF parsing, │ Agent │ and currency conversion tools. └──────┬───────┘ │ supplier_recommendations, procurement_strategy, negotiation_points ▼ ┌──────────────┐ │ Analyst │ Performs TCO analysis and risk assessment. │ Agent │ Issues final decision based on configurable thresholds. └──────┬───────┘ │ cost_analysis, risk_analysis, final_decision ▼ ┌──────────────┐ ┌──────────────┐ │ Orchestrator │────►│ Human Review │ Activated when decision = ESCALATE │ Agent │ │ Node │ └──────┬───────┘ └──────────────┘ ▼ Final Report + Plain-Language Summary (CLI) ``` The graph is defined in `procurement_system/graph/procurement_graph.py`. The shared state flows through each node, accumulating outputs and a running decision log that is included in the final report. The communication semantics and state ownership model are described later in the Inter-Agent Communication Protocol section. --- ## 4. The Four Agents ### Intake Agent — The Gatekeeper The Intake Agent is the entry point of the system. It receives a raw, free-text purchase request and is responsible for transforming it into a validated, classified, and routed procurement record. Its core tasks are: - **Validate** required fields: `description`, `quantity`, `unit`. If any are missing, it does not guess or infer — it triggers a clarification round. - **Classify** the request into a procurement category (e.g., `MACHINERY`, `IT_SOFTWARE`, `PROFESSIONAL_SERVICES`) based on the enterprise buying rules. - **Determine the process type**: `catalog_purchase`, `rfq`, `formal_rfq`, or `strategic_sourcing` — driven entirely by the rules defined in `enterprise_buying_rules.yaml`. - **Route** the request with a justification that cites the specific rule applied. #### Interactive Clarification via GraphInterrupt One of the more interesting implementation details here is how clarification is handled. When required fields are missing, the Intake Agent does not just flag an error — the graph raises a `GraphInterrupt`, which pauses execution and surfaces a structured question to the CLI. The user answers, and the graph resumes via `Command(resume=answer)`. Python controls the clarification loop — how many rounds are allowed, and when to proceed with flags if the user does not respond. The agent only formulates the question; it does not track rounds or decide when to stop. ```python except GraphInterrupt as e: interrupt_obj = e.args[0][0] payload = interrupt_obj.value question = payload.get("question", "Please provide the missing information") answer = input("> ").strip() final_state = graph.invoke(Command(resume=answer), config=config) ``` The tone of the clarification question adapts based on the round number — polite and open-ended in round 1, specific and urgent in the final round. This is controlled by a parameter injected at runtime, not hardcoded in the prompt. --- ### Procurement Agent — The Sourcing Specialist The Procurement Agent receives the validated request from the Intake Agent and is responsible for market research and sourcing strategy. It produces: - **1–5 supplier options** from genuinely different market segments (local, national, international). The number of options reflects market structure — single-source markets get one option; high-value strategic sourcing requests get up to five. - A **purchasing strategy narrative** that references the process type and explains why specific segments were chosen. - A **recommended order type** strictly aligned with the process type received from intake. - **3–5 specific, actionable negotiation points** — vague points like "negotiate a better price" are explicitly rejected by the prompt. Each supplier recommendation includes: name, type, estimated price range (total, not per-unit), lead time, reliability score, pros, cons, and contact priority. #### Tools The Procurement Agent has access to three tools: | Tool | Purpose | |---|---| | **Supplier Web Search** | Searches the web for suppliers matching the request category, powered by Tavily | | **PDF Reader** | Extracts and parses supplier catalogues, offers, and technical documents in PDF format | | **Currency Converter** | Converts supplier price quotes to a common currency for fair comparison | The tool layer is structured in three tiers: `tools/` (agent-facing interface), `services/` (business logic), and `repositories/` (external API calls). This separation makes each layer independently testable. --- ### Analyst Agent — The Decision Maker The Analyst Agent performs the financial and risk analysis, and issues the final procurement decision. Its output includes: **Total Cost of Ownership (TCO) analysis:** - Estimated unit cost and total estimated cost - Three cost scenarios: optimistic, realistic, pessimistic - Budget adequacy assessment and potential savings **Risk assessment:** - 3–5 identified risks across categories: financial, operational, supplier, quality, delivery, compliance - A composite `risk_score` calculated as the weighted average of `probability × impact` for each risk, clamped to a 1.0–10.0 scale **Final decision**, determined by configurable thresholds: ```yaml # config/config_analyst_agent.yaml decision_thresholds: auto_proceed: 3.0 # risk_score ≤ 3.0 → PROCEED auto_escalate: 7.5 # risk_score ≥ 7.5 → ESCALATE ``` The four possible decisions are: | Decision | Meaning | |---|---| | `PROCEED` | Risk and budget within thresholds — approved | | `PROCEED_WITH_CONDITIONS` | Approved, with specific conditions to satisfy before signing | | `ESCALATE` | Requires human review — risk or value exceeds thresholds | | `REJECT` | Request is fundamentally unfeasible | The risk score formula is deterministic — given the same inputs, the same score is always produced. This is intentional: auditability requires reproducibility. --- ### Orchestrator Agent — The Communicator The Orchestrator is the final node in the graph. It makes no new decisions — it synthesises and communicates everything the upstream agents have produced. It generates two outputs: 1. A **structured final report** (`LLMFinalReport`) containing the full TCO analysis, risk assessment, supplier recommendation, conditions, next steps, and the complete decision log from all agents. 2. A **plain-language message for the requester** (maximum 150 words, zero technical jargon). Terms like "TCO", "risk_score", or "rfq" are explicitly prohibited in this output. The message tells the requester: what was decided, who the recommended supplier is, what the cost looks like, and what the next concrete steps are. If the Analyst Agent has issued an `ESCALATE` decision, the graph routes through the **Human Review Node** before producing the final report — a deliberate circuit breaker to ensure high-risk purchases always involve a human. --- ## 5. Key Implementation Details ### Shared State as the Single Source of Truth All agents read from and write to a single `SharedState` TypedDict. This means there is no message-passing between agents — only state transitions. The decision log is an append-only list that every agent writes to, producing a complete audit trail by the time the Orchestrator runs. ### Inter-Agent Communication Protocol The system uses a **state-centric communication model** in which agents never communicate directly with one another. Instead, all coordination occurs through a shared `SharedState` object propagated across the LangGraph execution pipeline. This approach provides deterministic execution, loose coupling between agents, and a complete audit trail of all state transitions. The graph executes sequentially. Each node receives the fully merged state snapshot produced by upstream nodes and returns a partial state update. LangGraph deterministically merges these updates before invoking the next node. The communication protocol follows four core principles: | Principle | Implementation | |---|---| | **No direct agent-to-agent calls** | Agents read from and write to `SharedState` only. | | **Write-once, read-many ownership** | Each domain section of the state is owned by exactly one agent, but readable by all downstream agents. | | **Decision-driven routing** | Agents set routing fields (`routing_decision`, `final_decision`) that drive conditional graph edges. | | **Append-only auditability** | `decision_log` and `errors` are accumulated using `Annotated[list[str], operator.add]`, preventing overwrites. | The shared state structure is organised into domain-specific sections: ```python class SharedState(TypedDict, total=False): raw_request: str routing_decision: Literal["proceed", "escalate"] final_decision: Literal[ "PROCEED", "PROCEED_WITH_CONDITIONS", "ESCALATE", "REJECT" ] decision_log: Annotated[list[str], operator.add] errors: Annotated[list[str], operator.add] intake: IntakeState procurement: ProcurementState analyst: AnalystState orchestrator: OrchestratorState ``` All agent outputs are validated through Pydantic schemas before being committed to shared state. Invalid structured outputs raise typed exceptions and terminate execution safely rather than propagating malformed data downstream. Interactive clarification is implemented through LangGraph GraphInterrupt events, allowing execution to pause and resume without losing state consistency. High-risk procurement flows are additionally protected by a conditional Human Review node activated when the Analyst Agent issues an ESCALATE decision. ### Prompt Architecture Each agent has two prompts: a `system` prompt (defining the agent's role, reasoning approach, and output rules) and a `user` prompt (injected at runtime with the current state fields the agent needs). The user prompt is assembled programmatically by `utils/prompt_assembler.py`, which injects structured data from `SharedState` into a template. This separation means the system prompt defines *behaviour* and the user prompt delivers *data* — a clean contract that makes prompts easier to test and version independently. ### Output Schema Enforcement Agent outputs are enforced via Pydantic using LangGraph's `.with_structured_output()`. If the LLM produces output that does not match the schema, the system raises `StructuredOutputError` — a typed exception that is caught at the top level in `main.py` and handled gracefully, returning control to the user for a new request without crashing the graph. ### Model Registry The model used by each agent is configured independently in `config/model_registry.yaml`. This means different agents can run on different Claude models — for example, a lighter model for the Orchestrator (which mostly reformats existing data) and a more capable model for the Analyst (which requires deeper reasoning). --- ## 6. Project Structure The codebase follows a layered architecture: ``` procurement_system/ ├── agents/ ← Agent logic (one subdirectory per agent) ├── config/ ← All YAML configuration (buying rules, thresholds, models) ├── graph/ ← LangGraph graph definition ├── nodes/ ← Graph nodes (one per agent + human_review) ├── prompts/ ← System and user prompts (versioned, checksummed) ├── repositories/ ← External API calls (Tavily, currency, PDF) ├── schemas/ ← Pydantic models for all agent inputs and outputs ├── services/ ← Business logic layer ├── tools/ ← Agent-facing tool interfaces └── utils/ ← Shared utilities (prompt loading, LLM setup, logging) tests/ ├── agents/ ← Agent-level tests ├── nodes/ ← Node-level tests ├── repositories/ ← Repository-level tests └── services/ ← Service-level tests ``` The test suite mirrors the source structure exactly, with coverage at every layer. --- ## 7. Running the System The system runs as a command-line application: ```bash python main.py ``` A sample session: ``` Provide purchase requisition (or exit): > 2 units CNC milling machine 3-axis, budget ~90000 USD, delivery by September 2026 📄 RAPORT ============================================================ Decision: PROCEED_WITH_CONDITIONS Message: Your request for 2 CNC milling machines has been reviewed. We recommend TechMachinery GmbH as the primary supplier, with a total estimated cost of $82,000–$94,000. Before signing, please confirm their delivery guarantee in writing. Next step: contact TechMachinery GmbH to confirm pricing and lead time. --- Decision log --- • [intake] Classified as MACHINERY / formal_rfq — rule: threshold_50k_usd • [procurement] 3 supplier options identified • [analyst] risk_score: 3.8 — PROCEED_WITH_CONDITIONS • [orchestrator] Final report compiled ``` --- ## 8. Limitations and Honest Scope This is a v0.1 system. It is important to be clear about what it does *not* yet do: - **No web interface** — interaction is CLI only. - **No persistent storage** — each session is stateless; there is no database of past requests or decisions. - **No ERP or procurement system integration** — the system is standalone. - **Supplier recommendations are AI-generated** — the web search tool finds real results, but supplier data should be verified before acting on it. - **Buying rules are static** — they must be manually updated in `enterprise_buying_rules.yaml`; there is no self-learning from past decisions. These are known limitations, not oversights. The goal of this version was to validate the multi-agent workflow and the agent contracts — not to build a production-ready procurement platform. --- ## 9. What Comes Next The natural next steps for this system, in rough priority order: 1. **Persistent session storage** — saving requests, decisions, and reports to a database for reporting and audit purposes. 2. **Web UI** — replacing the CLI with a proper interface for procurement teams. 3. **ERP integration** — connecting to systems like SAP or Odoo to pull existing supplier data and push approved requests. 4. **Feedback loop** — allowing procurement specialists to rate recommendations, so the system can improve buying rule suggestions over time. 5. **Multi-language support** — the agents currently operate in English; supporting additional languages would expand the system's applicability. --- ## 10. Tech Stack Summary | Component | Technology | |---|---| | Agent framework | LangGraph | | LLM provider | Anthropic Claude (via API) | | Output validation | Pydantic | | Supplier web search | Tavily | | PDF parsing | Custom service layer | | Currency conversion | Custom service layer | | Configuration | YAML | | Language | Python 3.10+ | --- ## References - [LangGraph documentation](https://langchain-ai.github.io/langgraph/) - [Anthropic Claude API](https://docs.anthropic.com/) - [Tavily Search API](https://tavily.com/) - [Pydantic documentation](https://docs.pydantic.dev/) - [LangGraph — Human-in-the-loop patterns](https://langchain-ai.github.io/langgraph/concepts/human_in_the_loop/) 4c:T2b3d,![ig_0bd4f6fc9fe063f30169ea8054df4c8191a1de707953b0f381.png](ig_0bd4f6fc9fe063f30169ea8054df4c8191a1de707953b0f381.png) ## Overview Personal Identity OS is a local-first multi-agent system built with LangGraph. It helps a user turn raw personal inputs such as notes, public URLs, and PDFs into a structured `Fact Dossier.md` that can be reviewed before it is written to disk. The project was built as a capstone submission for the Ready Tensor **Multi-Agent System** program. Its goal is to demonstrate practical multi-agent collaboration, tool integration, orchestration with LangGraph, and human-in-the-loop review in a workflow that solves a real documentation problem: turning scattered professional information into a grounded and reusable profile. GitHub repository: https://github.com/Zegor88/identity-os ## Why This Project Matters Professionals often have their career facts spread across CVs, PDFs, websites, notes, and memory. Turning that material into a clean and trustworthy profile is harder than it looks. A single prompt is usually not enough for this task because the workflow requires several different behaviors: - ingesting different source types - extracting only grounded facts - checking new facts against what is already known - presenting pending updates in a human-readable way - letting the user approve, cancel, or correct the result before it is written This is exactly the kind of problem that benefits from a modular multi-agent design rather than a one-shot generation flow. ## Problem Statement The system addresses a practical problem: > How can we convert unstructured personal and professional source material into a reusable, source-grounded fact dossier without blindly trusting a single LLM pass? The project focuses on three requirements: 1. support multiple input formats 2. separate responsibilities across specialized agents 3. keep the human in control before the final write ## What the System Does Personal Identity OS supports two working modes: - **Interview mode**: the system asks the user a structured 32-question interview across seven sections, summarizes each section, asks for anything missing, and then processes the section through the same extraction and review pipeline - **Direct mode**: the user provides raw text, a public URL, or a local PDF path and the system processes that input directly In both modes, the workflow ends with a preview and a human approval gate before the dossier is updated. Generated artifacts: - `output/Fact Dossier.md` - `output/change_log.md` ## Multi-Agent Architecture The system is orchestrated with **LangGraph**. Each node has a distinct responsibility and collaborates through shared graph state. ### High-Level Architecture ```mermaid graph TD User[User] CLI[CLI] Graph[LangGraph Orchestrator] Sources[Text / URL / PDF] Interview[Interview Flow] Direct[Direct Update Flow] Extract[Fact Extraction] Check[Conflict Checking] Preview[Preview + Approval] Dossier[(Fact Dossier.md)] subgraph Tools[Custom Tools] PDF[pdf_reader] WEB[web_search] MD[md_manager] end User --> CLI CLI --> Graph User --> Sources Graph -->|interview mode| Interview Graph -->|direct mode| Direct Sources --> Direct Interview --> Extract Direct --> Extract Extract --> Check Check --> Preview Preview --> Dossier Sources -.-> PDF Sources -.-> WEB Preview -. read/write .-> MD ``` ### Execution Graph ```mermaid flowchart TD Entry[entry] Entry -->|mode=direct| Ingestion[ingestion] Entry -->|mode=interview| IQ[interview_question] IQ --> IP[interview_progress] IP -->|more questions| IQ IP -->|section complete| ISR[interview_section_review] ISR --> IA[interview_apply] IA --> Ingestion Ingestion --> FE[fact_extractor] FE --> CC[conflict_checker] CC --> PP[prepare_preview] PP --> AP[approval] AP -->|approve| WR[write] AP -->|edit| FE AP -->|cancel| End1((END)) WR -->|direct| End2((END)) WR -->|interview| ADV[interview_advance] ADV -->|next section| IQ ADV -->|complete| End3((END)) ``` ## Agent Roles This project satisfies the capstone requirement of using at least three agents with distinct responsibilities. In practice, it uses several specialized graph nodes: | Agent / Node | Responsibility | |---|---| | `Router / Ingestion` | Normalizes raw text, URL, or PDF input into graph-ready text | | `Fact Extractor` | Extracts grounded professional facts into structured state | | `Conflict Checker` | Compares new facts to the current dossier and classifies them | | `Prepare Preview` | Builds the human-readable preview shown before writing | | `Markdown Writer` | Rewrites the dossier using approved updates | | `Interview Question` | Asks the next question during interview mode | | `Section Review` | Summarizes a completed interview section and asks for missing details | | `Interview Apply / Advance` | Converts interview answers into graph input and moves to the next section | The key point is not just the number of nodes, but the separation of concerns: extraction, checking, summarization, approval, and writing are handled independently rather than collapsed into one model invocation. ## Tool Integration The project also satisfies the capstone requirement of integrating at least three tools beyond basic LLM responses. | Tool | Purpose | Why it matters | |---|---|---| | `tools/pdf_reader.py` | Extracts text from local PDF files using PyMuPDF | Extends the system to work with document inputs rather than plain prompts | | `tools/web_search.py` | Fetches public web page content through Firecrawl | Allows ingestion of external web sources | | `tools/md_manager.py` | Handles markdown reads, writes, template lookup, and output paths | Separates file lifecycle management from agent logic | These tools give the system real I/O behavior and make the pipeline useful beyond pure text completion. ## Human-in-the-Loop Design One of the most important design choices in this project is the explicit approval gate before writing to disk. After extraction and conflict checking, the system shows the user a preview of the pending facts. At that point, the user can: - approve the write - cancel the write - provide an edit instruction or correction This keeps the workflow grounded and reduces the risk of silently writing incorrect facts into the dossier. ## How the Workflow Operates ### Direct Mode The user provides: - raw text - a public URL - or a local PDF path The graph then runs: `entry -> ingestion -> fact_extractor -> conflict_checker -> prepare_preview -> approval -> write` ### Interview Mode The user launches the CLI with no argument. The graph then runs a 32-question interview across these seven sections: - Core Identity - Career Timeline - Business Facts - Personal Story - Positioning - Hard Boundaries - Content Assets Each completed section is summarized, optionally extended by the user, and then processed through the same extraction and approval pipeline before the interview advances. ## Data Structures and Review Logic The structured graph state includes: - router decisions (`has_facts`, `is_ambiguous`, `justification`) - extracted facts with `section`, `label`, `value`, and `source_excerpt` - fact classifications with one of four labels: - `Duplicate` - `Contradiction` - `Enrichment` - `Novel` - preview payloads for the approval screen This design gives the workflow a clear internal contract and makes it easier to reason about how information moves through the system. ## Example Usage ### Setup ```bash git clone https://github.com/Zegor88/identity-os.git cd identity-os python3.10 -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp .env_example .env ``` Required environment variables: - `GOOGLE_API_KEY` - `FIRECRAWL_API_KEY` for URL ingestion ### Run in Interview Mode ```bash python run_graph.py ``` ### Run in Direct Mode ```bash python run_graph.py "From 2022 to 2024 I led analytics automation for 14 markets." python run_graph.py "https://example.com/about-me" python run_graph.py "/absolute/path/to/profile.pdf" ``` ## Design Choices Several practical design choices shaped the final system: - **LangGraph over a linear script**: useful because the workflow has branching, interruptions, and section-by-section progression - **Specialized nodes instead of one agent**: useful because extraction, checking, writing, and interviewing have different objectives - **Markdown output**: useful because the result remains inspectable, portable, and easy to version - **Human approval before write**: useful because the workflow deals with personal facts, where silent mistakes are costly ## Current Limitations This is a working capstone project, not a polished production platform. Current limitations include: - URL ingestion depends on Firecrawl availability and API access - the project does not yet include an automated test suite - evaluation is qualitative rather than benchmark-driven - the system currently focuses on writing a fact dossier, not a broader identity platform I state these limits explicitly because Ready Tensor evaluation emphasizes technical honesty and verifiable claims. ## What This Project Demonstrates From a capstone perspective, the project demonstrates: - a working **multi-agent system** - distinct agent roles with shared orchestration - **LangGraph** as the orchestration framework - at least **three integrated tools** - a meaningful **human-in-the-loop** step - runnable local setup and example usage ## Why I Think This Is a Good Fit for the Capstone This project is a good fit for the Mastering AI Agents capstone because it solves a real workflow problem that is hard to address with a single prompt. It requires routing, structured extraction, consistency checking, staged review, and controlled writing. Those responsibilities are distributed across multiple cooperating agents and tools, with LangGraph coordinating the overall flow. In other words, the system is not “multi-agent” in name only. The decomposition is central to how the project works. ## Repository - GitHub: https://github.com/Zegor88/identity-os ## Future Improvements If I continue this project, the next improvements would be: - add automated tests for graph behavior and tool paths - add evaluation datasets for extraction and conflict classification quality - improve conflict resolution UX - support richer output artifacts beyond a single dossier file - add demo screenshots or a short walkthrough video ## Conclusion Personal Identity OS is a practical example of a local-first multi-agent pipeline that turns scattered professional inputs into a reviewed fact dossier. The project combines orchestration, tool use, human review, and structured writing into one coherent LangGraph workflow. It is designed to be understandable, runnable, and evaluable as a Ready Tensor capstone submission. 4d:T2821,![Multi_agent_AI_system.webp](Multi_agent_AI_system.webp) This project presents a multi-agent system built with LangGraph for automated analysis of GitHub repositories. The system breaks down repository evaluation into smaller tasks handled by specialized agents, such as content extraction, metadata analysis, structure checking, and quality scoring. These agents work together in a structured workflow to process a repository’s README file and generate clear, structured feedback. The final output includes a summary of the project, extracted metadata, a quality score, and a pass/retry decision based on predefined rules. The goal is to show how agent-based systems can be used to improve clarity, structure, and consistency in automated codebase analysis. # 🏷️ **Tags:** ![agent](https://img.shields.io/badge/agent-AI-blue) ![github](https://img.shields.io/badge/github-api-black) ![readme](https://img.shields.io/badge/readme-analysis-green) ![system](https://img.shields.io/badge/system-multi--agent-orange) ![quality](https://img.shields.io/badge/quality-scoring-purple) # 📘 Introduction README files are one of the most important parts of any GitHub repository, but their quality varies a lot across projects. Some are well structured and informative, while others are incomplete or unclear. This makes it difficult to quickly understand what a project does or how usable it is. This project explores a multi-agent approach to solving that problem. Instead of using a single model to handle everything, the system splits the task into smaller responsibilities handled by different agents. Each agent focuses on one aspect of the repository, such as extracting information, analyzing structure, or evaluating quality. LangGraph is used to coordinate these agents into a workflow where each step builds on the previous one. This makes the system easier to extend, debug, and reason about compared to a single monolithic model. # ⚙️ Methodology The system takes a GitHub repository URL as input and processes it through a series of agents. Each agent has a specific role and contributes to a shared state that is passed through the workflow. First, the Analyzer Agent fetches the repository data using the GitHub API, including the README file and basic metadata like stars, forks, and programming language. This forms the base input for the rest of the system. The workflow then splits into multiple parallel agents. The Content Agent extracts the project title and generates a short summary of the README. The Metadata Agent identifies keywords and generates relevant tags. The Structure Agent checks whether key sections like installation, usage, and license are present. After that, the Quality Agent evaluates the README based on simple rules such as length, formatting, and the presence of code blocks. All these outputs are then passed to the Reviewer Agent. The Reviewer Agent combines everything and produces the final decision. If the quality score is too low or important sections are missing, the system can trigger a retry loop for re-evaluation. The LLM agent helps in ensuring the user can interact with the system and get more clarification about the repository. ## 🏗️ Architecture ```text GitHub Repo URL ↓ ┌─────────────────────┐ │ Analyzer Agent │ → Fetch README + Repo metadata (API tool) └─────────────────────┘ ↓ ──────────────────────────────────────────────────────── ↓ ↓ ↓ ↓ Content Metadata Structure quality Agent Agent Agent Agent ↓ ↓ ↓ ──────────────────────────────────────────────── ↓ ↓ Reviewer Agent ↓ output ↓ Human feedback ↓ LLM agent ``` ## 🤖 Agents Description ### 🧠 1. Analyzer Agent The Analyzer Agent is responsible for fetching the README content directly from the GitHub API. It also retrieves important repository metadata such as the number of stars, forks, and the primary programming language. This agent serves as the entry point for all repository-level understanding. --- ### ✍️ 2. Content Agent The Content Agent focuses on extracting meaningful textual information from the README. It identifies the project title and generates a concise summary that captures the core purpose of the repository in natural language. --- ### 🏷️ 3. Metadata Agent The Metadata Agent is responsible for analyzing the README content to extract relevant keywords. These keywords are then transformed into meaningful tags that represent the core themes and functionality of the repository. --- ### 🧱 4. Structure Agent The Structure Agent evaluates the documentation quality of the repository by checking for essential sections such as Installation, Usage, and License. It also identifies any missing or incomplete documentation sections that may affect usability. --- ### 📊 5. Quality Agent The Quality Agent computes a quality score for the README based on multiple factors including overall length, formatting consistency, and the presence of structured code blocks. This helps in assessing how well-documented the repository is. ### 🧑‍⚖️ 6. Reviewer Agent The Reviewer Agent aggregates outputs from all previous agents and evaluates the overall system output. It generates final feedback and determines whether the repository analysis passes quality standards or requires a retry based on defined evaluation rules. ### 🧑‍⚖️ 7. LLM Agent The LLM Agent enables natural language interaction with the system. It can answer user questions about the repository and also improve or refine the generated summary when additional clarity or enhancement is requested. ## 🛠️ Tool Integration This system integrates multiple tools to enable intelligent agent behavior: ### 1. GitHub API / Repository Parser This tool fetches repository metadata and README content using GitHub’s REST API. It enables the system to extract structured information such as stars, forks, and primary programming language. ### 2. Ollama ( LLM inference) The system integrates Ollama as a local large language model inference engine. It is responsible for enhancing and rewriting repository summaries, improving readability, and generating higher-quality descriptions based on structured repository data. This enables offline, privacy-preserving LLM execution without relying on external APIs. ### 3. Python AST / Text Processing Tools This tool processes raw README content into structured outputs. It performs tasks such as summary generation, keyword extraction (tags), and readability scoring. ## ⚙️ Installation 1. Clone the repository ```bash git clone https://github.com/Electrobello1/LangGraph-Multi-Agent-Intelligence-Orchestration-System.git cd LangGraph-Multi-Agent-Intelligence-Orchestration-System ``` 2. Install dependencies ```bash pip install requirements.txt ``` 3. install ollama ```bash irm https://ollama.com/install.ps1 | iex ``` 4. Run the system ```bash python main.py ``` # 🧪 Experiments The system was evaluated using a set of GitHub repositories with varying levels of documentation quality. The objective was to assess how well the multi-agent pipeline handles differences in structure, completeness, and clarity of README files. The test set included: - Well-documented repositories with clearly defined sections - Moderately documented repositories with partial structure - Poorly documented repositories with minimal or unstructured content # 📊 Results The system returns a structured breakdown of a GitHub repository after processing its README and metadata. Each output includes: - Basic repository details (stars, forks, language) - Extracted title and short summary - Generated tags - Missing sections (if any) - A quality score - Final status (pass or retry) ## 🔹What the outputs show Repositories with clear and complete READMEs usually return: - Better summaries - No missing sections - Higher quality scores - A pass result Repositories with partial documentation: - Have some missing sections - Get moderate scores - Include feedback in the output - Poorly documented repositories: - Produce weaker summaries - Miss multiple key sections - Get lower scores - Often return a retry status ## 🔹 Consistency The outputs are consistent across runs because the evaluation is rule-based. The same input produces the same result, which makes the system predictable and easier to debug. ## 🔹 Traceability Each part of the result comes from a specific agent: - Missing sections → Structure Agent - Score → Quality Agent - Summary → Content Agent ![github report 1.png](github%20report%201.png) ![github report2.png](github%20report2.png) # 🏁 Conclusion This project shows how a GitHub repository can be broken down and understood using a simple multi-agent setup instead of a single model doing everything at once. Each agent handles a specific part of the job, reading the README, pulling metadata, checking structure, and scoring quality; then everything is combined into one final result. The main benefit of this approach is clarity. It’s easy to see what each part of the system is doing and why a repository gets a certain score or status. It also makes the system easier to adjust or improve without breaking everything. From the results, well-documented repositories are handled smoothly, while weaker ones are clearly flagged for missing information or poor structure. The final output stays consistent and easy to interpret across different cases. Overall, the system works well as a lightweight way to evaluate repository quality and shows how splitting a task into smaller agents can make the process more organised and practical.4e:T4745,# 🫀 CardioSentinel MAS > Extending the evidence–practice gap solution from RAG retrieval into **coordinated clinical reasoning** — using specialized AI agents to handle drug safety, risk stratification, and patient communication in parallel. --- ![cardiosentinel_mas.gif](cardiosentinel_mas.gif) --- ## 📌 Background Phase I of this project — [**CardioSentinel_RAG**](https://app.readytensor.ai/publications/cardiorag-lT6kxW5im1ys) — established a RAG-based guideline retrieval engine that transforms static cardiovascular guidelines into a queryable clinical knowledge system. It solved the first barrier of **evidence-practice gap**: *getting the right evidence in front of the right person at the right time.* But retrieval alone is not enough. A clinician querying a guideline engine still has to: - Manually cross-check the patient's current medications for interactions - Mentally calculate cardiovascular risk from scattered lab values - Translate clinical recommendations into language the patient can act on - Do all of this in under 10 minutes per consultation These are not retrieval problems. They are **reasoning and coordination problems** — and they call for a different architecture. --- ## 🎯 The Core Problem This Phase Addresses Phase I retrieved the evidence. Phase II coordinates evidence-informed workflows. The three persistent barriers that motivated this phase: **Time pressure.** A clinician must synthesize guideline recommendations, check drug safety, and assess risk simultaneously. **Medication safety at scale.** A guideline recommendation is only safe in the context of what the patient is already taking. **Patient compliance.** Evidence-based recommendations written in clinical language do not improve outcomes if patients cannot understand or act on them. --- ## 💡 Proposed Solution **CardioSentinel MAS** is a graph-orchestrated multi-agent clinical decision support system for cardiovascular disease management. Where Phase I answers: *"What does the guideline say?"* Phase II answers: *"Given this specific patient, what is the safe, risk-stratified, actionable plan — explained at two levels: for the clinician, and for the patient?"* --- ## 🎯 Purpose The purpose of **CardioSentinel MAS** is to demonstrate how a multi-agent clinical decision support architecture can coordinate evidence retrieval, risk assessment, medication safety checks, and patient communication into a single agentic system. The project explores how modern orchestration frameworks, agentic state management, and human review systems can improve explainability, modularity, auditability, and safety in clinical decision support environments. --- ### Expected Outcomes By the end of this phase, the system should be able to: 1. Retrieve guideline-grounded recommendations from the RAG layer 2. Quantify cardiovascular risk using structured patient factors 3. Detect major medication interactions and contraindications 4. Trigger clinician review for high-risk or unsafe workflows 5. Generate patient-friendly summaries of validated clinical plans 6. Maintain immutable workflow state and audit history 7. Combine all outputs into a unified structured report through graph-based orchestration 8. Continue functioning safely even when individual tools or agents fail --- ## 🧠 High-Level Solution Architecture This is Phase II in the three-layer CardioSentinel ecosystem: ```text ┌─────────────────────────┐ │ Guideline RAG Engine │ │ Evidence Retrieval │ └────────────┬────────────┘ │ ┌────────────▼────────────┐ │ LangGraph Orchestrator │ │ Multi-Agent Coordination│ └────────────┬────────────┘ │ ┌─────────────────────┼─────────────────────┐ │ │ │ ▼ ▼ ▼ Guideline Agent Risk Agent Medication Agent │ │ │ └──────────────┬──────┴──────────────┬─────┘ │ │ ▼ ▼ Human Review Layer (HITL) │ ▼ Patient Communication Agent │ ▼ Streamlit Clinical Interface ``` --- ## 🧭 End-to-End Workflow Execution ```text START ↓ INPUT VALIDATION ↓ GUIDELINE AGENT ↓ RISK AGENT ↓ [Risk ≥ Threshold?] ├── YES → HUMAN REVIEW └── NO ↓ MEDICATION AGENT ↓ [Safety Issues Detected?] ├── YES → HUMAN REVIEW └── NO ↓ PATIENT AGENT ↓ FINALIZE REPORT ↓ END ``` --- ## 🤖 Agent Responsibilities ![cardiosentinel_mas2.png](cardiosentinel_mas2.png) --- ### 🧠 Guideline Specialist Agent - Sends a structured patient summary + clinical question to `GuidelineRetrieverTool` - Extracts recommendations and their source citations - If the RAG tool returns no evidence → agent returns `insufficient_evidence`, never fabricates --- ### 📊 Risk Stratification Agent - Runs `RiskScoreCalculator` against the patient's age, blood pressure, LDL, and conditions - Classifies risk: **Low / Moderate / High / Very High** - Returns contributing factors so the output is explainable, not just a number --- ### 💊 Medication Safety Agent **DrugInteractionTool:** Checks every pair of inferred medications for known interactions. Severity-filtered — only `major` and `contraindicated` pairs block the pipeline. **ContraindicationChecker:** Cross-references patient conditions against proposed medications. --- ### 🤝 Patient Communication Agent - Uses the Groq API (Mixtral) to generate a 2–3 sentence plain-language summary - Produces 3–4 specific lifestyle tips tailored to the patient's risk profile and conditions --- ## 🛠 Tools Layer All clinical knowledge lives in tools, not in agents. Agents are logic — tools are data. This separation means tools can be replaced with real data sources without touching agent code. ### ⚠️ Current Implementation (Mocked) | Tool | What It Does Now | |---|---| | `GuidelineRetrieverTool` | Returns hardcoded strings from a Python dict keyed by condition | | `DrugInteractionTool` | Checks a hardcoded dict of ~6 drug pairs | | `ContraindicationChecker` | Checks a hardcoded dict of ~8 condition–drug mappings | | `RiskScoreCalculator` | Additive point formula (not clinically validated) | --- ### 🔁 What Real Implementations Would Replace These With | Tool | Real Replacement | |---|---| | `GuidelineRetrieverTool` | Phase I CardioCDSS RAG engine (ChromaDB + Neo4j + Cohere reranker) | | `DrugInteractionTool` | Lexicomp, DrFirst, or First Databank API (licensed) | | `ContraindicationChecker` | Same licensed API + RxNorm drug normalization layer | | `RiskScoreCalculator` | ACC/AHA Pooled Cohort Equations (Goff et al., JACC 2014) | The tool interface contract (input/output schema) remains identical in both cases. Agents do not need to change. --- # 🤝 Human-in-the-Loop Clinical Review CardioSentinel MAS incorporates structured clinician approval checkpoints before clinically significant recommendations proceed downstream. ![cardiosentinel_hitl](cardiosentinel_hitl.png) ## Approval Checkpoints #### Medication Safety Review Triggered when: - Major drug interactions are detected - Contraindications are identified - Medication safety confidence is low #### High-Risk Cardiovascular Review Triggered when: - Cardiovascular risk exceeds predefined thresholds - The patient is classified as “Very High Risk” #### Guideline Validation Review Triggered when: - Evidence confidence is insufficient - Manual review is requested |Decision|Action| |---|---| |Approve|Continue workflow execution| |Modify|Edit intermediate state and re-run downstream agents| |Reject|Halt workflow and return audit record| All review decisions are recorded in an immutable audit trail with timestamps and rationale. --- ## ⚖️ Design Decisions & Tradeoffs | Decision | Choice | Reason | | --------------------------- | ----------------------------------- | ----------------------------------------------------------------------------- | | **Orchestration Framework** | LangGraph | Enables conditional routing, workflow state tracking, and resumable execution | | **Human Oversight** | Mandatory HITL checkpoints | Prevents unsupervised high-risk recommendations | | **Workflow State** | Centralized immutable state | Ensures traceability and reproducibility | | **Failure Handling** | Retry + graceful degradation | Maintains workflow continuity under partial failure | | **Auditability** | Immutable audit trail | Supports explainability and reviewability | | **LLM Usage** | Restricted to patient communication | Keeps clinical reasoning deterministic and tool-grounded | | | | | --- ## 📂 Project Structure ```text cardiosentinel_mas/ │ ├── app.py ├── main_new.py ├── config.py │ ├── core/ │ ├── base.py │ ├── graph.py │ ├── node_definitions.py │ └── edge_routing.py │ ├── agents/ │ ├── guideline_agent.py │ ├── risk_agent.py │ ├── medication_agent.py │ └── patient_agent.py │ ├── tools/ │ ├── rag_tool.py │ ├── risk_tool.py │ ├── interaction_tool.py │ └── contraindication_tool.py │ ├── schemas/ │ ├── outputs.py │ └── state.py │ ├── hitl/ │ └── approval_manager.py │ ├── ui/ │ ├── app.py │ ├── components/ │ └── styles/ ├── pages/ │ ├── home.py │ ├── new_analysis.py │ ├── workflow.py │ ├── review.py │ ├── results.py │ └── history.py │ ├── tests/ │ ├── test_agents.py │ ├── test_tools.py │ ├── test_pipeline.py │ └── conftest.py │ ├── requirements.txt ├── .env.example └── .streamlit/config.toml ``` --- ## 📥 Installation & Setup ### 1. Clone and Install ```bash git clone https://github.com/anaboset/cardiosentinel-mas cd cardiosentinel-mas python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install -r requirements.txt ``` ### 2. Configure Environment ```bash cp .env.example .env # Set GROQ_API_KEY for PatientAgent # Set RAG_API_URL and RAG_API_KEY to connect Phase I ``` ### 3. Run the appication ```bash streamlit run app.py ``` ### 4. Run Tests ```bash pytest tests/ -v ``` --- ## 📖 Example Run ```python patient = { "age": 65, "bp": "150/95", "ldl": 160, "conditions": ["hypertension", "smoker"], } query = "What is first-line therapy?" ``` **Output:** ``` ============================================================ CLINICAL DECISION SUPPORT REPORT ============================================================ 📋 QUERY: What is first-line therapy? 👤 PATIENT: Age 65, BP 150/95, LDL 160 mg/dL Conditions: hypertension, smoker ⚠️ RISK STRATIFICATION Classification: Very High (Score: 72/100) • Age 65 (≥65 years) • Stage 2 hypertension (SBP 150) • High LDL (160 mg/dL) • Active smoker 📚 GUIDELINE RECOMMENDATIONS (Confidence: high) • Thiazide diuretics are recommended as first-line for uncomplicated hypertension. • Target BP < 130/80 mmHg for high-risk patients (ACC/AHA 2023). • Smoking cessation counseling is mandatory for all smokers. • High-intensity statin therapy for LDL > 190 mg/dL or ASCVD risk > 20%. Sources: [ACC/AHA 2023 Hypertension Guidelines] [USPSTF Tobacco Cessation Guidelines 2021] 💊 MEDICATION SAFETY: ✅ Safe to proceed No interactions or contraindications flagged. 🤝 PATIENT COMMUNICATION Your blood pressure and cholesterol are both elevated, which puts you at high risk for a heart attack or stroke — but both are manageable with medication and lifestyle changes. Lifestyle Advice: → Quit smoking — this is the single highest-impact action you can take → Reduce salt intake to under 2g/day to help lower blood pressure → Walk 30 minutes daily, 5 days a week → Follow up in 4 weeks to check BP response to medication ``` --- ## 🧪 Testing Strategy Testing focused on validating both normal execution and failure handling across tools, agents, and the full workflow pipeline. ### Tool Testing (`test_tools.py`) Each tool was tested independently for expected outputs, edge cases, and safe handling of invalid or missing inputs. ### Agent Testing (`test_agents.py`) Agents were tested with mocked tools to isolate agent logic, validate structured outputs, and ensure graceful fallback behavior during failures. ### Pipeline Testing (`test_pipeline.py`) End-to-end workflow tests verified correct report generation, preservation of patient context, graceful degradation under tool/API failures, and accurate detection of unsafe clinical scenarios. --- ## 📈 Evaluation Plan Evaluation focuses on clinically meaningful system behavior rather than chatbot-style metrics. ### Agent Coordination Assesses whether the orchestration layer triggers the correct agents and routing paths for different patient scenarios. ### Safety Validation Measures the system’s ability to detect dangerous drug interactions and contraindications while minimizing missed safety risks. ### Abstention Reliability Verifies that the system safely returns `insufficient_evidence` when evidence is unavailable instead of generating unsupported recommendations. ### Failure Resistance Evaluates whether workflow execution continues safely when individual tools or agents fail. ### Latency Targets end-to-end workflow execution under 5 seconds (excluding LLM calls), with minimal orchestration overhead. --- ## 🚀 How CardioSentinel Differs From Typical Healthcare AI Systems Most healthcare AI systems focus on isolated capabilities such as chatbot question answering, guideline retrieval, or standalone risk prediction. CardioSentinel MAS instead explores how these capabilities can be safely coordinated within a structured, graph-orchestrated clinical workflow under human supervision. | Typical Healthcare AI | CardioSentinel MAS | | --------------------------- | ------------------------------------ | | Single general-purpose LLM | Multiple specialized agents | | End-to-end text generation | Tool-grounded workflow pipeline | | Implicit reasoning | Explicit graph orchestration | | Limited oversight | Human-in-the-loop review checkpoints | | Hallucination-prone outputs | Evidence-linked recommendations | | Minimal failure handling | Graceful degradation architecture | | Monolithic system design | Modular interchangeable components | | Stateless responses | Centralized workflow state tracking | | Safety checks optional | Mandatory medication safety layer | | Minimal traceability | Immutable audit trail | --- ## ⚠️ Known Limitations **Several tools remain mocked.** The drug interaction database, contraindication mappings, and risk scoring logic are simplified and not clinically validated. **The workflow has simulated HITL review.** Although approval checkpoints exist architecturally, they are not integrated into real clinical governance systems or institutional workflows. **The Streamlit UI is a prototype interface.** It demonstrates workflow interaction patterns but is not designed for production clinical deployment. **No real EHR integration exists.** Patient data is still manually entered and not connected to FHIR-compliant systems. **Drug normalization is incomplete.** Medication inference still relies on simplified mappings rather than production-grade RxNorm normalization pipelines. **LLM-generated patient communication remains unvalidated.** Although clinician review checkpoints exist, generated summaries have not undergone formal readability or safety evaluation. **Security and compliance controls are incomplete.** The system does not yet implement production-grade authentication, authorization, encryption, or regulatory compliance infrastructure. --- ## ⚠️ Medical Disclaimer This software is intended for **research and architectural demonstration purposes only**. It is **not a medical device** and **not intended for diagnosis, treatment, or clinical decision-making without qualified human oversight**. The tools are mocked. The drug interaction database is incomplete. The risk scoring is not clinically validated. No clinical expert was involved in the design of this system. All clinical decisions must be made by licensed healthcare professionals. The author assumes no liability for clinical use of this system. 4f:T4778,![ResumeLens.png](ResumeLens.png) # Abstract ResumeLens is an AI-powered resume analysis system designed to help candidates understand how well their resume aligns with a target role and what they should improve next. The platform accepts resume content as raw text or uploaded files, optionally accepts a job description as text or URL, and generates a structured candidate profile, gap analysis, rewritten resume bullets, ATS keyword recommendations, interview questions, and an action plan. The system is built with a **FastAPI backend**, **LangGraph-based multi-step orchestration**, **PostgreSQL persistence**, and a **Streamlit interface** for interactive usage. Rather than behaving like a one-shot prompt wrapper, ResumeLens is designed as a practical AI application with authentication, report history, preference memory, structured outputs, and production-oriented backend patterns. Its main value is not simply producing AI-generated text, but turning resume improvement into a repeatable, explainable workflow. ResumeLens gives users both diagnosis and action: what is strong, what is missing, what should be rewritten, and how to become a better fit for a given role. ## Dataset ResumeLens is not trained on a custom large-scale labeled dataset in the traditional machine learning sense. Instead, it operates on **user-provided runtime inputs** plus structured intermediate artifacts generated during analysis. ### Primary input data sources - Resume text pasted directly into the interface - Uploaded resume files: - `.txt` - `.pdf` - `.docx` - Optional job description input: - pasted text - public job posting URL ### Derived internal artifacts From the input data, the system generates: - normalized resume text - normalized job description text - structured candidate profile - gap analysis report - final improvement report - stored user preferences - analysis history for historical comparison ### Data characteristics The data is semi-structured and user-specific. Typical resume content includes: - candidate name - education - skills - projects - experience summary - contact links - certifications Typical job description content includes: - role title - required skills - preferred technologies - domain expectations - hiring signals and ATS-style keywords ### Data quality considerations The quality of system output depends heavily on: - resume completeness - document formatting quality - text extraction quality for PDF/DOCX files - clarity and relevance of the job description - whether the resume contains quantified achievements or only generic statements ### Privacy note User resumes and reports can contain personal and sensitive career information. In production use, privacy, access control, retention policy, and deployment security should be treated as high-priority concerns. --- ## Why ResumeLens Exists Most resume feedback tools fail in one of two ways: they are either too generic to be useful, or they produce polished text without clearly explaining what is actually wrong with the original resume. ResumeLens was created to solve a more practical problem: **How can we turn resume review into a structured, repeatable, AI-assisted workflow that gives both explanation and improvement?** The motivation behind ResumeLens includes: - helping users tailor resumes to specific roles instead of relying on general advice - showing users **why** they are a weak or strong fit, not just assigning a score - identifying ATS keyword gaps in a transparent way - converting vague resume weaknesses into concrete rewritten bullets and action items - preserving historical results so improvement can be tracked over time - demonstrating a realistic AI backend architecture with orchestration, persistence, and typed outputs ResumeLens exists because most job seekers do not only need better wording. They need: - stronger alignment to role requirements - better visibility into missing skills - more effective project and experience framing - a structured way to improve over multiple iterations ## Live Demo https://youtu.be/7OtrqrkBK4s ## GitHub repo https://github.com/SimbaMunatsi/resume-lens # Methodology ResumeLens uses a multi-stage AI workflow rather than a single prompt. ## High-level methodology 1. Accept resume input as text or file 2. Optionally accept a job description as text or URL 3. Normalize and clean all textual inputs 4. Extract a structured candidate profile 5. Compare the profile against the target job 6. Generate a structured gap analysis 7. Produce rewritten bullets, ATS keywords, and action steps 8. Persist the results for later access and historical comparison ## Design principles - Separation of concerns: tools, agents, services, routes, and persistence are distinct - Structured outputs: Pydantic schemas reduce ambiguity and stabilize downstream processing - Deterministic + LLM hybrid logic: scoring and normalization are partially rule-based for more explainable behavior - Persistence-first design: analysis history and user preferences make the system reusable over time - Backend-first architecture: Streamlit consumes the API, but the backend remains the source of truth ## Main analytical stages - Resume extraction - Job description acquisition - Candidate profile generation - Gap analysis and scoring - Resume improvement generation - Report assembly and persistence ## System Architecture ResumeLens is designed as a layered AI application. ### Main layers - Streamlit UI for user interaction - FastAPI backend for validation, auth, orchestration, and API responses - Tool layer for resume extraction, text cleaning, job fetching, and skill normalization - Agent workflow for profile extraction, gap analysis, and improvement generation - Service layer for assembling and persisting outputs - PostgreSQL database for users, analyses, reports, and preferences ![resume-lens flow.png](resume-lens%20flow.png) ## The 3-agent design ### Agent 1: Resume Parsing & Profiling Agent #### Responsibility Convert raw resume text into a structured candidate profile. Inputs - raw resume text Outputs - candidate name - email / links if present - experience summary - education - skills - projects - certifications - inferred seniority - missing sections - structured JSON profile #### Why it exists This agent creates the normalized state the rest of the workflow needs. ### Agent 2: Job Match & Gap Analysis Agent #### Responsibility Compare the structured resume against the target job description. Inputs - candidate profile - job description text Outputs - match score - matched skills - missing skills - weak alignment areas - high-priority gaps - strengths relevant to the role - ATS keyword gaps #### Why it exists This is the decision engine of the project. ### Agent 3: Resume Improvement Agent #### Responsibility Turn analysis into practical resume improvements. Inputs - candidate profile - job match report - user preferences from memory Outputs - rewritten bullets - missing keyword suggestions - section-level recommendations - final action plan - tailored interview questions #### Why it exists This makes the system actually useful, not just analytical. ## Tools ### 1. resume_extractor Purpose: Extracts usable text from the resume input. What it does: - handles uploaded resume files - supports formats like TXT, PDF, and DOCX - converts file content into plain text for downstream analysis #### Why it matters: The rest of the pipeline cannot work on raw files. This tool is what turns a resume document into analysis-ready text. ### 2. job_fetcher Purpose: Retrieves job description text from a public job URL. What it does: - sends a request to a provided job posting URL - parses the page content - extracts the relevant visible job description text - raises a controlled error if fetching fails #### Why it matters: It allows the user to analyze their resume against a live job posting instead of manually copying the description. ### 3. text_cleaner Purpose: Cleans and normalizes raw text before analysis. What it does: - removes unnecessary whitespace and formatting noise - standardizes extracted resume text - standardizes fetched or pasted job description text - helps ensure empty or low-quality text is detected early #### Why it matters: Even good extraction can leave messy text behind. This tool improves consistency before the candidate profile and gap analysis stages. ### 4. skill_normalizer Purpose: Standardizes skill names into a consistent format. What it does: - maps skill aliases to one canonical form - examples: - Postgres → PostgreSQL - fast api → FastAPI - js → JavaScript #### Why it matters: Without normalization, the system may treat equivalent skills as different. This tool improves match accuracy during gap analysis and scoring. ### Flow overview Resume Input -> Resume Extraction Tool -> Text Cleaning -> Candidate Profile Agent -> Job Description Input / Job Fetch Tool -> Gap Analysis Agent -> Improvement Agent -> Final Report Assembly -> Save Analysis + Report + Preferences ### Step-by-step explanation 1. Resume input The user either: pastes resume text or uploads a TXT, PDF, or DOCX file 2. Resume extraction The extraction layer converts uploaded documents into normalized text. 3. Text cleaning The text cleaner removes noise and standardizes formatting. 4. Candidate profile extraction The first agent converts the cleaned resume into a structured profile. 5. Job description acquisition The system either: uses pasted job description text or fetches and parses a public job URL 6. Gap analysis The second agent compares the candidate profile with job expectations, calculates match signals, and identifies missing or weak areas. 7. Improvement generation The third agent produces resume rewrites, ATS keyword guidance, role-fit feedback, interview questions, and an action plan. 8. Report assembly and storage The final response is returned to the user and persisted for history, review, and future comparison. ## Code snippet Below is a representative example of the analysis endpoint pattern used in ResumeLens. It shows validation, extraction, and structured response assembly: ```python @router.post("/run", response_model=ResumeExtractionResponse) async def run_analysis( current_user: User = Depends(get_current_user), resume_file: UploadFile | None = File(default=None), resume_text: str | None = Form(default=None), job_description_text: str | None = Form(default=None), job_url: str | None = Form(default=None), ) -> ResumeExtractionResponse: if resume_file is None and not resume_text: raise HTTPException(status_code=400, detail="Provide either resume_file or resume_text.") if resume_file is not None and resume_text: raise HTTPException(status_code=400, detail="Provide only one of resume_file or resume_text.") if job_description_text and job_url: raise HTTPException(status_code=400, detail="Provide only one of job_description_text or job_url.") # Resume extraction and cleaning happen here # Job description fetch/cleaning happens here # Candidate profile, gap analysis, and final report generation follow return ResumeExtractionResponse(...) ``` This code reflects important engineering decisions: - input validation at the API layer - support for multiple input modes - protected user workflow - structured response modeling - clean separation between endpoint logic and deeper analysis workflow ## Getting Started ### 1. Clone the Repository ```bash git clone https://github.com/SimbaMunatsi/resume-lens.git cd resume-lens ``` ### 2. Create and activate virtual environment #### Windows ```bash python -m venv venv venv\Scripts\activate ``` #### Linux ``` python -m venv venv source venv/bin/activate ``` ### 3. Install Dependencies ``` pip install -r requirements.txt ``` ### 4. Configure Environment Variables Create a .env file and populate the required values. Example: ``` APP_NAME=resume-lens APP_VERSION=0.1.0 API_V1_PREFIX=/api/v1 DEBUG=True POSTGRES_USER=postgres POSTGRES_PASSWORD=postgres POSTGRES_SERVER=localhost POSTGRES_PORT=5432 POSTGRES_DB=resume_lens DATABASE_URL=postgresql://postgres:your_password@localhost:5432/resume_lens LOG_LEVEL=INFO SECRET_KEY=your secret key here ALGORITHM=HS256 ACCESS_TOKEN_EXPIRE_MINUTES=60 MAX_UPLOAD_SIZE_BYTES=2097152 ALLOWED_RESUME_EXTENSIONS=.pdf,.docx,.txt JOB_FETCH_TIMEOUT_SECONDS=10 MAX_JOB_DESCRIPTION_CHARS=12000 OPENAI_API_KEY=your key here OPENAI_MODEL=gpt-4.1-mini ``` ### 5. Run database migration ``` alembic upgrade head ``` ### 6. Start the FastAPI Backend ``` uvicorn app.main:app --reload ``` ### 7. Start the Streamlit Frontend ``` streamlit run streamlit_app.py ``` ### Example resume + JD use case Resume includes Python, FastAPI, PostgreSQL Job requires Python, FastAPI, PostgreSQL, Docker ResumeLens detects: - strong backend alignment - missing Docker evidence - ATS keyword gap for Docker - opportunities to strengthen project impact language ## Observability and Monitoring ResumeLens includes basic production-oriented observability patterns. ### Current monitoring-related features - structured request logging - centralized exception handling - explicit validation errors for malformed inputs - controlled failure handling for job fetch failures - graph / workflow stage visibility through modular services and agents - analysis history persistence for traceability of past runs ### Recommended future observability additions - LangSmith tracing for agent and graph execution - per-stage latency monitoring - prompt + output trace inspection - structured metrics for success/failure by tool and endpoint - dashboarding for request volume, response times, and failure classes # Results ## Main result categories - structured candidate profile - gap analysis score and findings - rewritten resume bullets - ATS keyword suggestions - role-fit feedback - interview questions - action plan - historical improvement comparison ![profile.PNG](profile.PNG) ResumeLens produces outputs that are both diagnostic and actionable. ![gap_analysis.PNG](gap_analysis.PNG) ## Practical value of results The strongest result is not just the match score. It is the combination of: - score - explanation - weaknesses - rewritten output - next steps ![improvement.PNG](improvement.PNG) This makes the system useful for iterative resume improvement instead of one-time analysis. ## Evaluation ![tests.PNG](tests.PNG) ResumeLens currently relies on a combination of: - unit tests - integration tests - deterministic validation logic - schema-constrained outputs - manual qualitative inspection of generated reports ## Evaluation challenge Because resume quality is partially subjective, evaluation must balance: - structural correctness - role alignment - usefulness - factuality - actionability ## Limitations and Industry Insights ### Limitations 1. Output quality depends on input quality Weak or incomplete resumes will limit profile accuracy and downstream recommendations. 2. Public job URL parsing is imperfect Some job sites have noisy HTML, dynamic rendering, or anti-scraping behavior. 3. Resume truthfulness is assumed The system can improve how a candidate presents experience, but it cannot verify whether claims are true. 4. Match scoring is useful but not absolute A resume score is a decision aid, not a hiring prediction model. 5. Industry/domain nuance is limited Specialized sectors may require stronger domain-aware heuristics or role-specific prompts. 6. LLM output variability still exists Even with structured schemas, some variation in phrasing and recommendation style is expected. ### Industry Insights - Recruiter-facing value often comes from clarity and alignment, not only from grammatical polishing. - ATS optimization matters, but keyword stuffing without evidence is weak. Systems like ResumeLens work best when they encourage evidence-backed alignment. - Candidates increasingly want role-specific feedback rather than generic resume advice. - AI systems in career tooling are more useful when they combine: - structure - diagnostics - persistence - explainability This is where ResumeLens is strongest. ## Performance Characteristics and Requirements ### Runtime characteristics ResumeLens is designed for interactive local usage, not batch-scale processing. #### Performance depends on: - file size and quality of uploaded resume - PDF/DOCX parsing speed - network latency for public job URL fetching - LLM response latency - local machine resources - database responsiveness ### Typical resource requirements #### For local development: - Python virtual environment - PostgreSQL instance - internet access for external model/API calls - moderate CPU and RAM for backend + Streamlit + database ## Access and Availability ### Current availability ResumeLens is currently designed for: - local development - portfolio demonstration - technical publication and code review ## Contact information Creator: Victor Simbarashe Munatsi [Github](https://github.com/SimbaMunatsi) [LinkedIn](https://linkedin.com/in/victor-simbarashe-munatsi) vsmunatsi@gmail.com ## License and Usage Rights ResumeLens is released under the MIT License.50:T7ff7, # AI-OS Framework: A Multi-Agent Stability Governance Framework for Enterprise AI Systems ![hero.png](hero.png) ``` Enterprise AI systems do not fail instantly. They degrade gradually. AI-OS was built to detect that degradation before operational failure occurs. ``` ::: ##### Nur Amirah Mohd Kamil AI Engineer • Multi-Agent Systems • Production Reliability Engineering --- # Executive Summary Artificial intelligence is rapidly evolving from an experimental capability into core enterprise infrastructure. Organizations now depend on AI systems for customer support, workflow automation, knowledge retrieval, decision assistance, and internal productivity. As this transition accelerates, reliability becomes just as important as model quality. However, production AI systems often fail differently from traditional software. Instead of crashing immediately, they tend to degrade gradually through slower responses, weaker retrieval quality, increasing hallucination risk, KPI misalignment, and infrastructure instability. These problems may remain hidden until they begin to affect users or business outcomes. AI-OS Framework was created to address this gap. It introduces a structured operational model that converts fragmented observability signals into a bounded deployment health score called the AI Deployment Stability Index (ADSI). This enables teams to detect degradation earlier, classify operational risk, and respond with clearer governance controls. The framework combines multi-agent orchestration, mathematical stability scoring, governance tiers, anomaly visibility, and human oversight principles. Together, these components provide a blueprint for managing enterprise AI systems more safely and effectively. # Problem Statement Most organizations already monitor their AI systems using dashboards and telemetry platforms. They often collect metrics such as latency, throughput, cost, uptime, token usage, and error rates. While useful, these measurements are typically isolated indicators rather than a unified picture of system health. In practice, enterprise teams need higher-level answers. They need to know whether a deployment remains stable, whether risk is increasing, whether rollback decisions should be considered, and whether human intervention is required. Traditional monitoring tools are not always designed to answer these governance-oriented questions. They describe symptoms, but they may not clearly communicate survivability. # Why Existing Monitoring Falls Short Many AI incidents are not caused by a single failure. They emerge through combinations of smaller degradations that interact over time. For example, an organization may experience rising latency while retrieval quality simultaneously declines. Another system may show increasing hallucination rates at the same time business KPIs weaken. In some cases, infrastructure instability can combine with data drift to create inconsistent outputs. When these signals are viewed separately, teams may underestimate the seriousness of the situation. AI-OS Framework was designed to transform scattered metrics into a more actionable operational view. This represents a shift in mindset: Observability measures components. Stability governance protects outcomes. # AI-OS Framework Overview AI-OS acts as a supervisory layer for enterprise AI deployments. Its primary objective is to identify instability before it becomes a business incident. The framework provides five practical benefits: It measures deployment health using a bounded score. It classifies risk into understandable operational tiers. It supports earlier detection of degradation trends. It introduces governance pathways for response decisions. It preserves human oversight for critical interventions. Rather than replacing existing monitoring tools, AI-OS complements them by adding decision intelligence on top of raw telemetry. ![bac3f29b-c93f-41b4-9cc8-541a07bd57e7.png](bac3f29b-c93f-41b4-9cc8-541a07bd57e7.png) # Multi-Agent Architecture AI-OS is structured as a multi-agent system in which specialized agents perform focused operational responsibilities. ### The Monitoring Agent ingests telemetry streams, watches trends, and identifies unusual movement across metrics. ### The Stability Agent computes subsystem health indicators and calculates the ADSI score. It also monitors whether performance is improving or deteriorating over time. ### The Governance Agent interprets the score against defined thresholds. It determines whether the system should remain in normal operation, move into warning mode, escalate for review, or trigger mitigation workflows. ### The Response Agent handles operational actions such as retries, fallbacks, alerting, and incident coordination. ### The Human Oversight Agent ensures that high-impact decisions such as rollback approval or policy changes remain accountable and reviewable. This modular structure supports safer autonomy because responsibilities are clearly separated. ## Coordination Workflow 1. Monitoring Agent detects instability signals 2. Stability Agent recalculates ADSI 3. Governance Agent classifies tier risk 4. Response Agent executes mitigation 5. Human Oversight Agent reviews critical actions This enables autonomous yet governed production operations. # AI Deployment Stability Index (ADSI) The central metric of the framework is the AI Deployment Stability Index. Three subsystem indices define deployment health. Alignment Health Index ```math AHI = 1 - KPI_error ``` Infrastructure Health Index ```math IHI = RetrievalScore ``` Drift Health Index ```math DHI = 1 - (LatencyDeviation + EmbeddingShift)/2 ``` ## Composite Stability Score ```math ADSI = (AHI + IHI + DHI)/3 ``` Where: ```math ADSI ∈ [0,1] ``` A score near 1.0 indicates a healthy and stable deployment. A score near 0.0 indicates severe instability. The three indices capture complementary dimensions of performance. The Alignment Health Index measures whether the AI system continues to meet intended business outcomes such as task quality, user satisfaction, and KPI alignment. The Infrastructure Health Index measures technical reliability such as latency performance, service availability, and retrieval responsiveness. The Drift Health Index measures whether the system is changing away from expected behavior over time due to evolving inputs, embeddings, usage patterns, or environmental conditions. By averaging these signals, the framework avoids over-reliance on any single metric. ## Governance Tiers To make the score operationally useful, ADSI maps into four decision tiers. A score above 0.85 is considered **Stable**, meaning the deployment is healthy and normal operations may continue. A score between 0.75 and 0.85 is **Warning**, suggesting closer monitoring and investigation. A score between 0.65 and 0.75 is **Degrading**, indicating that intervention should be considered soon. A score below 0.65 is **Critical**, meaning immediate mitigation, rollback, or escalation may be required. These thresholds are configurable to suit organizational tolerance and business context. # Methodology The framework was evaluated using synthetic telemetry simulations that emulate common production AI operating conditions. This approach allows controlled benchmarking without exposing proprietary enterprise data. The simulation modeled multiple phases of deployment behavior. Stable periods represented healthy low-variance operation. Warning phases introduced early degradation signals. Critical phases simulated compound failures across several metrics simultaneously. Signals used in the experiments included KPI error, retrieval quality, latency deviation, and embedding shift. Performance was measured using practical operational metrics such as detection speed, false negatives, classification accuracy, and area under curve (AUC). # Experimental Setup Across benchmark scenarios, AI-OS consistently identified instability earlier than baseline approaches focused on single metrics. Latency-only monitoring often reacted late because it missed quality deterioration. Drift-only approaches sometimes detected movement without understanding business impact. Generic dashboards exposed metrics but lacked unified escalation logic. The ADSI framework demonstrated faster degradation recognition, lower false negative rates, and stronger overall classification performance. Illustrative benchmark results included: * 15–32% faster degradation detection * Significant reduction in false negatives * 95%+ classification accuracy * Strong AUC performance These outcomes suggest that bounded composite scoring can improve production awareness in enterprise AI environments. ## Dataset The evaluation used the **AI-OS Enterprise Stability Telemetry Dataset v1.0,** a synthetic benchmark dataset designed to simulate realistic operational decline, anomaly transitions, and governance tier movement. Dataset Link: https://github.com/strdst7/ai-os-framework/tree/main/data # Implementation Walkthrough A simplified implementation of the ADSI score is shown below. AI-OS detected degradation 15–32% earlier. ```python def compute_adsi(ahi, ihi, dhi): score = (ahi + ihi + dhi) / 3 return round(max(0.0, min(score, 1.0)), 3) ``` This implementation enforces bounded outputs between zero and one, ensuring consistent dashboards and threshold logic. Tier classification can then be applied: ```python def classify_tier(score): if score >= 0.85: return "Stable" elif score >= 0.75: return "Warning" elif score >= 0.65: return "Degrading" return "Critical" ``` This makes the framework interpretable and deployable in real operational systems. ### Technical Assumptions The current version assumes that subsystem signals can be normalized into a common range between zero and one. It also uses equal weighting across indices as a transparent baseline. The synthetic benchmark is intended to approximate realistic degradation patterns, although live enterprise environments may exhibit more complex dependencies. Thresholds should therefore be calibrated for each organization rather than treated as universal constants. These assumptions are explicit so they can be improved in future releases. # Security, Governance & Safety Security controls: * environment variable secrets * no hardcoded credentials * dependency management * validated APIs * bounded outputs Governance controls: * interpretable scoring logic * tier-based escalation * auditable decisions * human override pathways Safety controls: * false positive threshold tuning * controlled mitigation triggers * transparent incident review ## Code Explanation To improve reproducibility and practical usability, this section explains the core implementation snippets used in AI-OS and connects each example directly to the system concepts introduced earlier. Rather than presenting code in isolation, each snippet below demonstrates how theoretical stability modeling becomes deployable production software. ### ADSI Stability Score Computation Reference Implementation def compute_adsi(ahi: float, ihi: float, dhi: float) -> float: """ Compute bounded AI Deployment Stability Index. """ score = (ahi + ihi + dhi) / 3 return round(max(0.0, min(score, 1.0)), 3) ## What This Code Does This function calculates the core AI-OS metric: ADSI = (AHI + IHI + DHI) / 3 Where: * ahi = Alignment Health Index * ihi = Infrastructure / Retrieval Health * dhi = Drift Health Index ## Key Implementation Choices Averaging Three Signals score = (ahi + ihi + dhi) / 3 This reflects the baseline equal-weight model discussed in the paper. It ensures: * simplicity * interpretability * transparent governance ## Bounded Output Protection max(0.0, min(score, 1.0)) This guarantees ADSI always remains in: [0,1] This prevents invalid operational scores due to noisy inputs or future weighting changes. ## Why Rounding Matters round(..., 3) Three-decimal precision is operationally readable while still numerically useful. Example: * 0.87341 → 0.873 ## Why It Matters This small function operationalizes the entire paper’s theoretical contribution. ## Stability Tier Classification Reference Implementation def classify_tier(score: float) -> str: if score >= 0.85: return "Stable" elif score >= 0.75: return "Warning" elif score >= 0.65: return "Degrading" return "Critical" ### What This Code Does Converts a numeric score into an actionable governance state. Instead of asking operators to interpret decimals, AI-OS translates metrics into clear operational language. ### Why These Thresholds Exist Thresholds were chosen to create progressive risk zones: Score Tier Action ≥ 0.85 Stable Continue normal ops 0.75–0.85 Warning Monitor closely 0.65–0.75 Degrading Investigate < 0.65 Critical Immediate mitigation ### Why This Matters Executives and operators act faster on labels than raw numbers. ### Retry Logic for Resilience Reference Implementation import time def retry_call(fn, retries=3): for attempt in range(retries): try: return fn() except Exception: time.sleep(2 ** attempt) return None ### What This Code Does This function retries transient failures such as: * temporary API outages * network jitter * short-lived database errors * service warmup delays ### Key Line Explained time.sleep(2 ** attempt) This is exponential backoff. Wait schedule: * Attempt 1 → 1 sec * Attempt 2 → 2 sec * Attempt 3 → 4 sec This avoids aggressive retry storms that can worsen outages. ### Why This Matters AI systems often depend on external services. Reliability requires graceful recovery, not immediate failure. ### Monitoring Health Check Endpoint Reference Implementation def healthcheck(): return { "status": "ok", "service": "AI-OS" } ### What This Code Does Provides a minimal heartbeat endpoint for orchestration platforms. Used by: * Kubernetes probes * load balancers * uptime monitors * deployment automation ### Why This Matters Production AI systems must be observable themselves, not only monitor others. ## Multi-Agent Coordination Example Reference Implementation def run_cycle(telemetry): obs = monitoring_agent.observe(telemetry) score = stability_agent.evaluate(obs) tier = governance_agent.decide(score) action = response_agent.act(tier) return { "score": score, "tier": tier, "action": action } ### What This Code Does This snippet demonstrates AI-OS as a cooperative multi-agent workflow. Step-by-step 1. Monitoring Agent observe(telemetry) Reads incoming production signals. 2. Stability Agent evaluate(obs) Computes ADSI. 3. Governance Agent decide(score) Maps score to risk tier. 4. Response Agent act(tier) Triggers mitigation. ### Why This Matters This directly implements the paper’s claim that AI operations should move from passive monitoring to coordinated autonomous governance. ## Testing Example Reference Implementation def test_adsi_range(): score = compute_adsi(0.9, 0.8, 0.7) assert 0 <= score <= 1 ## What This Code Validates Ensures ADSI never leaves bounded range. Without this test, future code changes could accidentally create invalid scores such as: * 1.12 * -0.08 ### Why This Matters Testing mathematical invariants is essential for trustworthy production systems. ### Why These Snippets Were Chosen The included code focuses on high-value production concerns: * scoring correctness * interpretability * resilience * orchestration * maintainability * testing discipline These examples were selected because they represent real enterprise engineering priorities rather than toy demonstrations. ## Summary The code snippets in AI-OS are not decorative examples. They are minimal reference implementations of the framework’s central claims: * bounded stability modelling * actionable governance tiers * resilient failure handling * cooperative multi-agent operations * testable production engineering This bridges research concepts with deployable software practice. ::: # Testing & Validation Testing suite includes: * unit tests for ADSI logic * boundary range tests * anomaly detection tests * API endpoint tests * inter-agent handoff tests * governance escalation tests * CI/CD automation workflows Example: ``` def test_adsi_range(): score = compute_adsi(...) assert 0 <= score <= 1 ``` # Installation Guide Run Locally ```bash git clone https://github.com/strdst7/ai-os-framework cd ai-os-framework pip install -r requirements.txt streamlit run app.py ``` # API Mode ```bash uvicorn src.main:app --reload ``` ## Usage Guide 1. Launch dashboard 2. View live ADSI score 3. Simulate degradation 4. Observe tier changes 5. Review anomaly alerts 6. Apply mitigation workflows ### Metric Normalization Assumption All subsystem signals are assumed to be transformable into bounded comparable scales within: [0,1] Examples: * KPI error → normalized inverse health score * retrieval quality → bounded relevance score * latency deviation → scaled performance penalty * embedding drift → normalized semantic shift metric Reasoning A bounded common scale enables interpretable aggregation across heterogeneous signals. Potential Impact If normalization functions are poorly calibrated, subsystem importance may be distorted. ### Monotonic Degradation Assumption The experimental simulations assume that compound failures generally worsen over time unless mitigation occurs. Examples: * latency gradually rises * retrieval quality declines * drift accumulates * KPI alignment weakens Reasoning This reflects many real production incidents where unresolved degradation compounds progressively. Potential Impact Some real systems exhibit oscillatory or bursty failures, which may require adaptive temporal modeling. ### Equal Weighting Assumption The baseline ADSI model uses equal contribution from subsystem indices: ADSI = (AHI + IHI + DHI) / 3 Reasoning Equal weighting provides transparency, interpretability, and a neutral starting point for benchmarking. Potential Impact In domain-specific deployments, certain signals may deserve higher weighting (e.g., latency in real-time systems, alignment in regulated systems). ### Independent Signal Contribution Assumption Subsystem metrics are combined additively and are assumed to contribute independently in the baseline model. Reasoning This simplifies first-generation deployment stability scoring. Potential Impact Real systems may contain nonlinear dependencies such as: * latency causing KPI loss * retrieval decay increasing hallucination rate * infrastructure faults amplifying drift impact Future versions may model interaction effects explicitly. ### Synthetic Telemetry Representativeness Assumption The evaluation uses synthetic telemetry designed to approximate enterprise AI operational patterns. Reasoning Synthetic data enables: * controlled degradation injection * reproducibility * safe experimentation * benchmark consistency Potential Impact Live enterprise environments may contain noisier, nonstationary, and domain-specific behavior not fully captured in simulation. ### Threshold Governance Assumption Operational tiers were defined as: * Stable ≥ 0.85 * Warning 0.75–0.85 * Degrading 0.65–0.75 * Critical < 0.65 Reasoning Tier thresholds create actionable governance states for operators. Potential Impact Thresholds should be calibrated per organization, workload criticality, and SLA tolerance. ### Human-in-the-Loop Assumption Critical actions are assumed to require operator review or approval in enterprise settings. Reasoning Many organizations require human oversight for rollback, escalation, and compliance-sensitive actions. Potential Impact Highly autonomous systems may choose automated mitigation pathways instead. ### Infrastructure Reliability Assumption The supervisory control plane is assumed to remain available during monitored incidents. Reasoning AI-OS evaluates target systems and depends on telemetry availability. Potential Impact If observability pipelines fail simultaneously, external redundancy or fallback monitoring may be required. ### Security Boundary Assumption Telemetry inputs and API interfaces are assumed to operate within trusted enterprise network controls. Reasoning The framework focuses on operational stability rather than adversarial cybersecurity defense. Potential Impact Hostile environments may require additional controls such as: * signed telemetry * zero-trust authentication * anomaly spoof detection * secure agent identity layers ### Summary These assumptions do not weaken the framework; they clarify its baseline operating model. AI-OS is intentionally modular, allowing future deployments to replace assumptions with: * adaptive weighting * nonlinear interactions * live telemetry calibration * autonomous remediation policies * industry-specific thresholds Explicit assumptions strengthen scientific validity, reproducibility, and deployment trustworthiness. ::: # Technical Assumptions and Design Constraints To ensure transparency, reproducibility, and proper interpretation of results, the following technical assumptions were made during the design and evaluation of the AI-OS framework. These assumptions are explicit, parameterizable, and intended to simplify controlled experimentation while preserving real-world relevance. # Limitations Current limitations: * synthetic telemetry rather than live enterprise data * static weighting model * simplified subsystem dependencies * limited multi-agent production pilots * no industry-specific calibration yet # Future Work Future versions of AI-OS may include predictive failure forecasting, autonomous remediation agents, distributed control planes, richer enterprise integrations, and policy-aware governance workflows. As AI systems become increasingly mission-critical, survivability engineering is likely to become an essential operational discipline. # Reader Next Steps Readers interested in extending this work may explore adjacent fields such as multi-agent systems, anomaly detection, MLOps, reliability engineering, and AI governance. Practical next projects could include building a live ADSI dashboard, connecting streaming telemetry, integrating Slack or Teams alerts, or experimenting with adaptive weighting strategies. The framework is intentionally designed as a foundation for further development. ## What to Learn Next To extend the ideas introduced in AI-OS, the most valuable next topics are: A. Multi-Agent Systems Study how specialized agents coordinate, communicate, and divide responsibilities. Recommended topics: * agent orchestration * planning systems * memory architectures * tool-using agents * human-in-the-loop systems Why it matters: AI-OS can evolve from supervisory automation into full cooperative agent ecosystems. B. MLOps and AI Reliability Engineering Learn how production AI systems are deployed, monitored, and governed. Recommended topics: * CI/CD for ML * model monitoring * drift detection * observability pipelines * rollback strategies * incident response systems Why it matters: AI-OS is fundamentally an AI reliability platform. C. Control Systems and Feedback Loops Study how engineering systems maintain stability under disturbance. Recommended topics: * PID control * state estimation * signal smoothing * closed-loop systems * bounded stability theory Why it matters: ADSI is conceptually a control-system stability signal for AI deployments. D. Statistics for Operations Learn how to evaluate uncertainty and incidents quantitatively. Recommended topics: * anomaly detection * confidence intervals * Monte Carlo simulation * hypothesis testing * ROC curves Why it matters: The AI-OS evaluation layer depends on statistical rigor. E. Security and Governance Study how enterprise systems remain safe and auditable. Recommended topics: * secrets management * RBAC / IAM * audit trails * policy enforcement * zero-trust design Why it matters: Production AI without governance becomes enterprise risk. ## Suggested Portfolio Projects Readers looking to strengthen their careers can build: Beginner * AI health dashboard * drift alert service * KPI anomaly detector Intermediate * enterprise model risk scoring system * self-healing inference router * cost-aware model switcher Advanced * autonomous AI incident commander * multi-agent governance platform * predictive survivability engine ## Helpful Resources Engineering * FastAPI documentation * Streamlit documentation * Docker documentation * GitHub Actions CI/CD docs Machine Learning Operations * MLflow * Weights & Biases * Evidently AI * Prometheus + Grafana Multi-Agent Systems * LangGraph * CrewAI * AutoGen * semantic memory systems Statistics * scikit-learn * SciPy * pandas * NumPy ## Questions to Explore Next Readers should ask: * Can AI deployments self-detect failure before humans notice? * Should governance agents control model routing? * How should enterprises certify AI stability? * Can survivability become an industry benchmark? * What metrics truly predict business failure? These questions can become future research papers or startups. Enterprise AI is still early. The builders who learn reliability, governance, and agentic operations now will shape the next generation of AI infrastructure. AI-OS is one blueprint. Your next version can be better. ::: # # Maintenance and Support Status Current Version: v1.0.0 The project is maintained as an active open-source framework with planned iterative improvements. Expected updates include documentation refinement, telemetry connectors, dashboard tooling, anomaly modules, and predictive survivability features. Support and issue reporting are available through the project repository. Repository: https://github.com/strdst7/ai-os-framework ## Current Release Status Stable Public Version Current Version: v1.0.0 Release classification: * Production-ready reference implementation * Research-backed prototype with deployable architecture * Open-source educational and enterprise experimentation use Version v1.0.0 includes: * ADSI bounded stability scoring * multi-agent supervisory architecture * Streamlit dashboard * FastAPI interface * anomaly detection layer * governance tier logic * documentation and tests ## Support Channels Users and reviewers can engage through the following channels. Primary Repository Support GitHub Issues: * bug reports * feature requests * installation problems * documentation improvements Community Support Discussion boards / GitHub Discussions for: * implementation questions * deployment advice * architecture ideas Professional Contact For enterprise collaboration or technical inquiries: Maintainer: Nur Amirah Mohd Kamil ai@nuramirahmohdkamil.com ## Dependency Maintenance Strategy AI-OS dependencies are periodically reviewed for: * security vulnerabilities * compatibility changes * deprecated libraries * performance regressions Recommended tooling: * Dependabot * pip-audit * pinned requirements * CI regression tests ## Documentation Maintenance Documentation is treated as a first-class asset. Maintained artifacts include: * README * installation guide * architecture notes * troubleshooting docs * change log * API examples All major releases should update documentation simultaneously. ## Backward Compatibility Policy Where possible: * public APIs remain stable across minor versions * dashboards preserve user workflows * scoring logic changes are documented clearly Breaking changes trigger a MAJOR version release. ## Security Support Status Security issues should be reported privately before public disclosure when possible. Maintenance priorities include: * dependency patching * secret management guidance * API validation hardening * infrastructure best practices ## Roadmap for Future Maintenance Planned future releases include: v1.1 * configurable subsystem weights * expanded metrics ingestion * improved dashboard UX v1.2 * live telemetry connectors * Slack / Teams alert integrations * richer anomaly analytics v2.0 * predictive failure forecasting * autonomous remediation agents * distributed enterprise control plane ## Sustainability Statement AI-OS is designed to remain maintainable through: * modular architecture * separated services * automated testing * documented interfaces * semantic versioning discipline This reduces technical debt and enables future contributors. ### Reader Guidance If using AI-OS today: 1. Start with the current stable release 2. Monitor changelog updates 3. Pin dependencies for production use 4. Report issues through repository channels 5. Contribute improvements where relevant ## Summary AI-OS is not a static publication artifact. It is an evolving operational framework with: * active roadmap direction * versioned releases * defined maintenance practices * support pathways * future enterprise scalability plans Clear maintenance status strengthens trust, adoption readiness, and long-term technical credibility. ::: # Contact Information of Asset Creators To improve accessibility, supportability, and collaboration readiness, the following contact and support channels are provided for the AI-OS framework. AI-OS is maintained as an open technical asset intended for learning, experimentation, and future enterprise expansion. ## Primary Maintainer Nur Amirah Mohd Kamil Independent AI Systems Architect Focus Areas: * Agentic AI Systems * Multi-Agent Production Architecture * Enterprise Reliability Engineering * AI Governance and Stability Modeling ## Repository and Source Code GitHub Repository https://github.com/strdst7/ai-os-framework Recommended for: * source code access * release updates * documentation * contribution tracking * issue reporting ## Technical Support Channel GitHub Issues Recommended for: * bug reports * installation issues * unexpected behavior * feature requests * documentation corrections Suggested issue template: Title: Clear summary Environment: OS / Python version / Deployment platform Problem Description: Steps to Reproduce: Expected Result: Actual Result: ## Professional Contact For professional collaboration, technical discussions, partnerships, or enterprise inquiries: LinkedIn https://www.linkedin.com/in/nur-amirah-mohd-kamil-/ ### Community Support (Planned) Future community channels may include: * GitHub Discussions * Discord developer community * technical Q&A forum * contributor workspace These channels are planned as adoption grows. ## Documentation Resources Users seeking help should first review: * README.md * Installation Guide * Troubleshooting Guide * Architecture Notes * Changelog These materials resolve most common setup issues quickly. ## Summary AI-OS support channels are intentionally transparent and developer-friendly. Primary contact pathways include: * GitHub repository * GitHub Issues * Professional networking channels * Documentation resources Providing clear maintainer access improves trust, usability, and long-term adoption confidence. ::: # Conclusion Production AI systems require more than dashboards. They require systems that can observe changing conditions, quantify operational risk, classify instability, trigger intelligent escalation, and preserve human accountability. AI-OS Framework demonstrates that enterprise AI stability can be formally modeled, mathematically bounded, operationally governed, and continuously improved. This represents a broader shift in how organizations manage intelligent systems: This marks a shift: '''' From observability To survivability. '''' # Links ## Live Demo ```bash # https://ai-osdev.streamlit.app/ ``` ## Framework Repository ```bash https://github.com/strdst7/ai-os-framework ``` ## Production Repository ```bash https://github.com/strdst7/ai-os ``` ## Full Paper ``` See PAPER.md ``` ## Dataset ```bash https://github.com/strdst7/ai-os-framework/tree/main/data ``` ## License ## MIT License --- ## Author Independent AI Systems Architect ### © 2026 Nur Amirah Mohd Kamil :::51:T4d70,# Quake Knowledge Graph ![Quake Knowledge Graph mi fai un immagine che descr (1).png](Quake%20Knowledge%20Graph%20mi%20fai%20un%20immagine%20che%20descr%20(1).png) Built with LangGraph, integrated with **Cohere LLM**, **MiniLM**, and **Qdrant vector** database the system is designed to allow the intelligent, automated analysis of INGV seismic data. The goal is to enable agents to collaborate tra loro by analysing the datasets dei terremoti, processing, and enriching them to generate explanations, reports, and answers to questions about seismic phenomena. ## Project Objectives This system is based on advanced multi-agent architectures: 1. Agent Orchestration: Directed graph execution using LangGraph with persistent state management 2. Multi-Agent Architecture: Distributed agent design with task-level specialisation and coordination 3. Tool Integration: Custom toolchain augmenting LLM capabilities with deterministic operations 4. Semantic Search: Embedding-based similarity matching for contextual data access 5. LLM Integration: Cohere APIs for generative tasks, structured analysis, and recommendation pipelines ## Quick Start ### Prerequisites - Python 3.10+ - API Keys for: Cohere - LLM API ### Installation 1. Clone and setup environment: :::note cd quake-knowledge-graph python -m venv venv venv\Scripts\activate ::: 2. Install dependencies: :::note pip install -r requirements.txt ::: 3. Configure environment variables (.env file): :::note Qdrant Cloud DRANT_URL = http://localhost:6333 QDRANT_API_KEY = admin-key QDRANT_COLLECTION = earthquake_events EMBEDDING_DIM = 384 Cohere COHERE_API_KEY=your_api_key ::: ## Architecture Overview ### System Architecture Diagram ![architettura multi agente.png](architettura%20multi%20agente.png) #### Multi-Agent System 1. Repository Analyzer Agent - Extracts repository structure, files, metadata, and detects project type 2. Embedding Agent - Manages semantic embeddings via Jina and stores in Qdrant for intelligent retrieval 3. Metadata Recommender Agent - Suggests project metadata, titles, and relevant tags 4. Content Improver Agent - Enhances README and documentation using LLM-powered suggestions 5. Reviewer Agent - Validates completeness and identifies gaps in documentation 6. QA Agent - Answers questions about repositories using vector similarity search 7. Article Generator Agent - Creates publication-ready content with structured narratives #### Tools 1. File Loader Tool – Upload INGV seismic datasets in TXT, CSV, XML, JSON, or ZIP formats and perform structural parsing. 2. Text Splitter Tool – Splits technical texts into optimised chunks (800 tokens / 100 overlaps) for embedding or analysis. 3. Data Analyzer Tool – Analyse the structure of seismic datasets and detect fields, formats, anomalies, and patterns. 4. Web Search Tool – Local search tool for INGV earthquake datasets. Performs structured queries on magnitude, depth, geographical area, time ranges, and types of events. ## Agent Roles & Responsibilities ### Agent Interaction Pipeline ![Pipline.png](Pipline.png) #### Dataset Analyser Agent The Dataset Analyser Agent is the entry point of the entire seismological pipeline. It is responsible for examining an INGV dataset, managing both directories and ZIP archives, and automatically identifying the files in TXT format of the official seismic catalogues. Once the files have been extracted, the agent reads the contents line by line, recognises the standard INGV columns, and filters out invalid or incomplete rows. Transform each event into a structured record with geophysical fields, including magnitude, depth, coordinates, event type, and authorial metadata. During processing, it verifies data consistency and identifies anomalies. When finished, it produces a complete statistical summary, including the minimum, maximum, and average magnitude; min/max/avg depth; and the total number of valid events. It also returns the entire list of extracted events, the number of files processed, and the path of the normalised dataset. Its output becomes the solid foundation on which the other agents in the multi-agent pipeline are grafted. #### Embedding Agent The Embedding Agent is responsible for transforming each INGV seismic event into a semantic vector representation for intelligent search. Upon launch, the agent verifies that the Qdrant collection dedicated to events exists; if it does not, it automatically creates it with the correct carrier size. Each event is converted into short, informative text that summarises magnitude, location, depth, event type, and essential metadata. These texts are then processed locally through the MiniLM model of SentenceTransformers, a fast and effective solution even in an offline environment. The generated embeddings are grouped into small batches to avoid exceeding payload limits and optimise memory usage. Next, the agent constructs vector points complete with descriptive payloads and inserts them into Qdrant in controlled micro-batches. Once the collection is populated, the agent allows you to perform semantic searches of similar events, either based on another event or on a free-text query. This enables exploratory analysis, clustering, and intelligent queries on earthquake characteristics. #### Metadata Recommender Agent The Metadata Recommender Agent analyses the already processed seismic dataset and generates intelligent metadata that enriches the geophysical content provided by INGV. Starting from the list of events and the statistical values extracted from the Dataset Analyser, the agent builds a series of synthetic titles that best represent the extent and intensity of the seismic sequence. It then produces a one-sentence summary, useful for compact descriptions in reports or information systems. In parallel, it generates thematic tags based on magnitude, average depth, and characteristic locations such as Campi Flegrei, Etna, or the Apennines, allowing rapid classification of the dataset. The agent also elaborates reasoning, i.e., a textual explanation of the choices made and the seismological classification of the data. The goal is to provide a set of metadata that is clear, consistent, and immediately usable by Content Improver, Reviewer, and Article Generator in the multi-agent pipeline. In this way, the agent contributes to the scientific and narrative contextualization of seismic information. #### Content Improver Agent The Content Improver Agent intervenes after the seismic dataset has been analysed and enriched with metadata, aiming to transform raw numbers and values into clear, readable, and technically accurate text. Starting from the statistical summary (min/max/average magnitude, min/max/average depth, number of events) and the metadata suggested by the Metadata Recommender, the agent builds a concise description that presents the entire dataset in a fluid, understandable way. It integrates the main information into a coherent paragraph, explaining the variability in magnitude, the distribution of hypocentral depths, and the geographical spread of the INGV-recorded events. The result is improved text that is ready to be used in reports, UI panels, or as the basis for the introductory section of the final seismological article. The agent also returns a summary of metadata usage and the number of events processed, enabling subsequent steps in the pipeline to track context. #### Reviewer Agent The Reviewer Agent serves as the scientific validator for the entire INGV seismic dataset, assessing its quality, reliability, and completeness. After receiving the events processed by the Dataset Analyzer and any enhanced text from the Content Improver, it performs a series of structured checks to identify critical errors, missing fields, and inconsistencies in geophysical values. In particular, it analyses the presence of fundamental fields such as time of origin, coordinates, magnitude, and depth, verifying that they are always available and correctly formatted. It also identifies numerical anomalies such as out-of-range depth or unrealistic magnitude, and produces targeted alerts to be submitted to the user or to the next steps in the pipeline. In addition to checks, it calculates a dataset health score by penalising serious problems, warnings, and missing fields. The Reviewer also produces recommendations and potential improvement actions, ranks them by priority, and facilitates the dataset review. This assessment is the foundation for the QA Agent and for generating the final report. #### QA Agent The QA Agent is the agent dedicated to answering questions about INGV seismic data, integrating semantic search and LLM generation. When the agent receives a question from the user, it first performs a vector search in Qdrant using the Embedding Agent to identify the most relevant events based on the query's semantic content. Starting from the results, it builds a synthetic scientific context, reporting key information such as magnitude, depth, coordinates, location, and type of event for each event. This context is then transformed into a specialised geophysical prompt, designed to guide the LLM model towards precise answers consistent with real data. The agent then uses the Cohere model to generate a concise, scientific, evidence-based response from the dataset. The QA Agent thus allows you to query the entire seismic archive in natural language, obtaining explanations, summaries, and targeted information on the most significant events. It is a fundamental component to make the dataset searchable intelligently and immediately. #### Article Generator The Article Generator Agent is the component of the pipeline responsible for producing complete seismological articles, scientific reports, and other informative content based on INGV data. Use an advanced LLM model to transform the results generated by other agents — dataset analysis, metadata, reviews, and summaries — into structured, clear, publish-ready text. The agent receives context consisting of seismic statistics, magnitude ranges, spatial distributions, and any user inputs, such as requests for weekly reports or analysis of specific areas. Based on these elements, it builds a detailed prompt that guides the LLM model towards a formal and scientific style, dividing the content into coherent sections and subsections. ## Comparison with Existing Seismological Pipelines Unlike traditional monolithic seismic data pipelines, which combine parsing, analysis, and reporting in a single workflow, this system adopts a modular multi-agent design. Each agent is responsible for a specific cognitive task (analysis, validation, embedding, reasoning), allowing independent evolution and substitution. | Feature | Traditional Pipeline | This Multi-Agent System | | --- | --- | | Modular agents | ❌ | ✅ | | Semantic search | ❌ | ✅ (Qdrant + MiniLM) | | Human-in-the-loop Limited | ✅ | Explicit agents | | Avg. dataset parsing | ~100–300 ms | 22 ms| | Explainable reasoning | ❌ | ✅ Metadata + Reviewer | ## Performance and Scalability Analysis | Component / Operation | Measured Value | Interpretation | | --- | --- | | Dataset Analysis | ~22 ms (mean) | Confirms highly optimised I/O and parsing logic for INGV TXT catalogues, enabling fast ingestion and interactive usage. | | Embedding Generation | ~37 s (mean) | Expected computational cost due to MiniLM inference and batched Qdrant insertions executed in a virtualised Podman environment. | | Metadata Recommendation | ~0 ms | Lightweight statistical processing implemented as pure functional transformations without heavy inference. | | Content Improvement | ~0 ms |Text generation based on precomputed statistics and metadata, requiring negligible computation time. | | Dataset Review | ~6 ms (mean) |Fast validation and consistency checks performed through deterministic rule-based analysis. | | Vector Search (Qdrant) | ~3.3 s (mean) | Normal latency for semantic similarity search considering MiniLM inference and virtualised network overhead. | | Peak Memory Usage (Embeddings) | < 11 MB | Demonstrates efficient memory footprint of MiniLM in CPU-only configuration. | | Steady-State Memory Usage |~4 MB |Confirms low persistent RAM consumption once the pipeline is initialised. | | Hardware Requirements | CPU-only | Suitable for edge or constrained environments without GPU acceleration. | ## Performance Metrics ### Runtime Performance | Operation | Mean Time | Std Dev | P95 | | --- | --- | --- | --- | | Dataset Analysis | 0.0227 s | 0.0114 s | 0.0189 s | | Embedding Generation | 37.52 s | 40.55 s | 18.34 s | | Metadata Recommendation | 0.00028 s | 0.00015 s | 0.00024 s | | Content Improver | 0.00002 s | 0.00001 s | 0.000015 s | | Reviewer | 0.00615 s | 0.00138 s | 0.00616 s | | Vector Search (Qdrant) | 3.30 s | 0.27 s | 3.57 s | ### 💾 System Metrics | Metric | Value | Comment | | --- | --- | --- | | Dataset Memory (peak) | ~1.47 MB | Lightweight INGV TXT parsing | | Embedding Memory (peak) | ~10.33 MB | Expected footprint for MiniLM (sentence-transformers) | | Embedding Memory (current) | ~4.25 MB | Model in RAM without GPU overhead | The INGV multi‑agent seismic analysis pipeline demonstrates robust performance and stable execution across all stages. Dataset parsing is extremely fast (22 ms on average), confirming that the INGV TXT loader is well-optimised for structured seismic catalogues. The most computationally expensive operation is embedding generation, which takes approximately 37 seconds due to the combination of MiniLM inference and Qdrant insertions running inside a Podman virtualised environment. Metadata generation, content improvement, and dataset review modules are highly efficient, with execution times close to zero, as they rely on lightweight transformations and statistical summarisation. Vector search operations in Qdrant average around 3.3 seconds, which is normal considering the overhead of MiniLM inference and the network path between the host and the Podman VM. Memory usage is stable and predictable, with MiniLM consuming roughly 10 MB peak RAM — consistent with CPU‑only sentence-transformers models. ### Performance Testing :::note{title="Run the benchmark"} python tools/benchmark_performance.py ::: ## 🔧 Technology Architecture ### Core Libraries - Python 3.10+ - Programming language - LangGraph (0.0.x) - Multi-agent orchestration and workflow - LangChain (0.1.x) - Text processing, utilities, and tool integration ### AI/ML Services - Cohere API (5.20.0) - Large Language Models for generation and analysis - MiniLM - Text embeddings - Qdrant Cloud (1.6.0) - Vector database for semantic search ### Key Libraries - python-dotenv - Environment variable management - requests - HTTP client for API calls - streamlit - Web interface (optional) - sentence-transformers - Local embedding fallback - cohere - LLM SDK - qdrant-client - Vector database client ## Testing & Quality Assurance :::info{title="Testing Framework"} Test LLM and embeddings python tools/test_llm_embeddings.py Test Qdrant integration python tools/test_qdrant.py ::: ### Test Coverage 1. **Unit Testing** – Validation of individual agent behaviours and logic 2. **Integration Testing** – Verification of the complete end‑to‑end workflow 3. **Performance Testing** – Benchmarking, profiling, and latency analysis ## Example Outputs :::note{title="Suggested metadata"} { "title_alternatives":[ 0:"Seismic Activity Summary from INGV Records" 1:"INGV Earthquake Dataset Analysis" 2:"Seismic Events Report (M 0.3–1.7)" ] "one_line_summary":"Dataset containing 6 INGV-recorded earthquakes, with magnitudes ranging from 0.3 to 1.7 (average 1.05)." "tags":[ 0:"microseismicity" 1:"intermediate-depth" 2:"geophysics" 3:"campi-flegrei" 4:"INGV" 5:"earthquake" 6:"seismic" ] "reasoning":{ "magnitude_range":"Magnitude ranges from 0.3 to 1.7, avg 1.05." "depth_range":"Depth ranges from 1.9 km to 24.5 km." "classification_basis":"Tags and metadata are derived from earthquake intensity, depth category, and notable locations contained in the dataset." } } ::: :::note{title="Enhanced content"} { "improved_text":"The dataset contains 6 analyzed seismic events. Earthquake magnitudes range from 0.3 to 1.7, with an average value of 1.02. Hypocentral depths span from 1.9 to 24.5 km (average: 11.35 km). The recorded events are distributed across multiple areas, showing spatial patterns and parameter variability consistent with typical regional micro‑seismic activity." "metadata_used":{ "title_alternatives":[ 0:"Seismic Activity Summary from INGV Records" 1:"INGV Earthquake Dataset Analysis" 2:"Seismic Events Report (M 0.3–1.7)" ] "one_line_summary":"Dataset containing 6 INGV-recorded earthquakes, with magnitudes ranging from 0.3 to 1.7 (average 1.05)." "tags":[ 0:"microseismicity" 1:"intermediate-depth" 2:"geophysics" 3:"campi-flegrei" 4:"INGV" 5:"earthquake" 6:"seismic" ] "reasoning":{ "magnitude_range":"Magnitude ranges from 0.3 to 1.7, avg 1.05." "depth_range":"Depth ranges from 1.9 km to 24.5 km." "classification_basis":"Tags and metadata are derived from earthquake intensity, depth category, and notable locations contained in the dataset." } } "events_processed":6 } ::: :::note{title="Scientific review"} { "issues":[] "recommendations":[] "validation_results":{ "critical_issues":0 "warnings":0 "recommendations_count":0 "completeness":{ "EventID":true "Time":true "Latitude":true "Longitude":true "Magnitude":true "Depth_Km":true "Location":true } "overall_health":100 "numerical_anomalies":[] "total_events":6 } "action_items":[] "priority_fixes":[ 0:"Migliorare descrizioni località" 1:"Aggiungere metadati mancanti" ] } ::: ## Maintenance and Project Status The modular agent-based design allows long-term maintainability. Each agent encapsulates a specific responsibility and can be independently updated or replaced without impacting the overall pipeline. ## 🔐 Security & Best Practices - API Keys: Store in .env, never commit to repository - Environment Variables: Use python-dotenv for configuration - Error Handling: Graceful fallbacks for service failures - Rate Limiting: Respects API rate limits to avoid throttling - Logging: Detailed error messages for debugging - Data Privacy: Repositories stored locally, not sent to external services (except embeddings) ## License The text and images in this document were created with the support of Microsoft Copilot. The author, Rosaria Daniela Scattarella, transfers to Engineering Ingegneria Informatica S.p.A. all economic rights relating to such contents, including reproduction, modification, distribution, and commercial use. © 2026 Engineering Ingegneria Informatica S.p.A. – All rights reserved. ## Acknowledgments Built with: - Qdrant for vector database infrastructure - LangChain ecosystem for agent framework - Cohere for LLM capabilities 52:T6ac2,![writer.png](writer.png) # Abstract This is a Multi-Agents Agentic AI system that drafts a very simple research on a topic that the user provides based information from the internet with the ability to provide external resources (txt or pdf docs in the data folder) for the system to consider while conducting the research. The System follows a parallelized architecture with the topic split into smaller subtopics to be searched and summarized independently, then the summaries from all those subtopics are merged and summarized into a final research. The system uses a summarizer-critic loop for each summarization process. The system uses the LLM whose API is available for these three options : OpenAI, Google , and Groq (in that order). *** *** *** # Introduction ### The main purpose of the project: The purpose of this project is to code a multi-agents agentic AI system that helps drafting a research by just giving it the short main topic you want, that draft could be like a starting point for the user to improve and it can save a lot of time, it's also a way to showcase the skills learned in the *Mastering AI Agents* course. The project consists of two main folder, src/ and data/ The data folder contains the external resources given by the user (optional), and those can be either pdf or txt files. The *src* folder contains the source code for the project, which are main.py , tools.py, vectordb.py, prompts.py , nodes.py , build_graph.py and output_structures.py. main.py is the main file which takes an input and invokes the system. tools.py contains the tools used by the system, which are RAG retrieval, File Parsing, and Tavily web-search tool. vectordb.py contains the implementation of the vector database, which is used to chunk and store the external resources in the *data* folder for using RAG Retrieval later. *prompts.py* contains the prompt templates *output_structure* contains the pydantic scheme for the output of some LLMs in the system *nodes.py* contains the agents (nodes) of our system *build_graph.py* defines the graph and connects the agents (nodes) according to a parallelized architecture *** *** *** :::info{title="info"} The project's GitHub repo: https://github.com/Haydara-Othman/Mastering_AI_Agents_Project ::: # Setup Guide: The repository has a *.env.example* file with the names of the required environment variables ( like the APIs or the choices for models to use ). **A .env file with those environment variables names and their true values must be created.** The repository also has a *requirements.txt* file which contains the important dependencies. To install the required libraries and dependencies, run the following code: ```bash pip install -r requirements.txt ``` After creating the *.env* file and putting your APIs and Model choices in it, the project is ready to run. *** :::important{title="Important"} The code won't work without installing the dependencies and setting up the environment variables. It is crucial to run the command above to install all required libraries and dependencies, and to put your APIs in the .env file. ::: *** *** # Methodology ## *The Data Folder:* The data folder can be filled with external resources (pdf or txt files) if the user wants to add some files from his own for the system to consider and take information from. Those documents will be chunked, embedded and added to a vector database. The system will use RAG Retrieval later to retrieve the relevant information. ## How the system work : The graph follows a parallelized architecture, just like in the photo below : ![Multi-Agent System Architecture.png](Multi-Agent%20System%20Architecture.png) The system consists of three main agents: Searcher, Parallel Analyzer, and Final Summarizer The Searcher takes the topic and splits it into different subtopics regarding the different aspects and information about that topic, then uses the Tavily tool which searches the internet for information about each of those subtopics. If there exists external documents added by the user, then the vector database is searched too. The Parallel Analyzer takes the information about each subtopic and summarizes it into a summary, in a parallel branching way . Then, the summaries are revised by a critic which gives its approval and opinion of each one of those subtopics, if one of them wasn't approved, then the summarizer summarizes it again. The Final Summarizer takes those sub summaries and summarizes them once more into a final result, with a critic giving its opinion on what should change if the summary wasn't approved. As we said above, each summarizer agent (parallel or final summarizer) uses a summarizer-critic loop architecture, as in the following photo : ![Summarizer-Critic Loop.png](Summarizer-Critic%20Loop.png) This loop architecture makes sure to remove as many mistakes from the summarizations as possible. Now we explain each code file in the *src* folder : ## *main.py* : This is the main file that should be run using : ```bash python src/main.py ``` it defines an initial state for the system, and runs an infinite loop where it takes the topic from the user and runs the agent. The system can be shutdown by entering 'quit'. Notice the ```python result = asyncio.run(agent.ainvoke(init_state)) ``` instead of a simple *agent.invoke...* That is because we are using *asyncio* to parallelize the summarization process of the different subtopics in the *Parallel Summarizer* agent, we'll explain that later when we explain the *nodes.py* file. ## *nodes.py* : this one contains all the agents (nodes) of our system, The Searcher, The Parallel Summarizer, and The Final Summarizer. It first initiates an LLM ( OpenAI or Google or Groq ) based on available API keys in the .env file in that order and defines the state of the graph. Then it defines each of our agents: ```python def Searcher(state): print("[Searcher] starting") print(f"[Searcher] main_topic = {state['main_topic']!r}") response = searcher_chain.invoke( state['main_topic'] ) dc=state["search_results"] if getattr(response, "subtopics", None): subtopics=response.subtopics for topic in subtopics: print(f"[Searcher] querying Tavily for subtopic: {topic}") results = tavily_tool.invoke(topic) results_contents = [result['content'] for result in results.get('results', [])] print(f"[Searcher] got {len(results_contents)} web results for {topic}") dc[topic] = results_contents else: subtopics=[] print("[Searcher] WARNING: no subtopics were returned by the LLM") print(f"[Searcher] done. sub_topics = {list(response.subtopics) if getattr(response, 'subtopics', None) else []}") return { 'search_results' : dc, 'sub_topics': subtopics, 'summaries_approval' : {s :False for s in subtopics}, 'first_critic_opinions' : {s :'None' for s in subtopics} } ``` as we can see, the agent takes the wanted variables from the current state, does its job from calling the LLM and processing the results, then updates the state with the new results. That's the general method of most of the agents. But we have to take a special look at *Parallel_Analyzer*: ```python async def Parallel_Analyzer(state): print("Starting parallel analyzer") if state['num_external_resources'] > 0: sr = add_rag_to_tavily_results(state) else: sr = state['search_results'] ts = state["topics_summaries"] tkf= state["topics_kfacts"] tasks_data = [] for topic,results in sr.items(): skip = state["summaries_approval"][topic] if skip: continue opinion = state["first_critic_opinions"][topic] results_string = "\n\n\n\n\n".join(results) single_args = {'topic': topic, 'paragraphs_list': results_string, 'opinion': opinion} tasks_data.append((topic, single_args)) coroutines = [first_summarizer_chain.ainvoke(args) for _, args in tasks_data] responses = await asyncio.gather(*coroutines, return_exceptions=True) for (topic, _), response in zip(tasks_data, responses): if isinstance(response, Exception): raise response ts[topic] = getattr(response, "summary", 'None') tkf[topic] = getattr(response, "KeyFacts", []) return {'topics_summaries' : ts , 'topics_kfacts' : tkf} ``` from the beginning we see thee *"async"*, that's because we are using async to parallelize the summarization process of each subtopic independently. we define a list of tasks which is *tasks_data* and use *ainvoke* so that we can use *await asyncio.gather* to initiate all the summarizations at once. we don't use async.run here since we used it in the *main.py* fileto make the *temporal loop* created by the async.run universal and so it lasts until the agent finishes all its work. we can see the definition of both a summarizer and a critic for each summarizer to implement the summarizer-critic loop. in the state we define variables for the both the critics' approval and opinion. after the critic reviews the summarizations, it returns an approval Boolean and an opinion to the summarizer, if the approval is true, then we move forward. If not, then we retry the summarization process with passing the critic's opinion to the LLM this time. ## *build_graph.py* : This simply defines the system's graph, adding the nodes mentioned earlier and connecting them according to the architecture we discussed above. paying attention when to return the summary to the critic and when to move forward. ## *tools.py* : This file contains the tools that'll be used by the system, like Parsing *pdf* and *txt* files , and searching the vector database for relevant chunks of text. without forgetting to define the *Tavily* web search tool. ## *prompts.py* : This one contains the prompt templates for the different LLMs used. the prompts were chosen to explicitly tell the LLM what to do, defining the rules it must follow, the outputs it must generate, and the allowed responses. Here is an example of a prompt in the file: ```python Simplifier_Prompt_Template = """ You are an LLM which is provided a web searching tool , You take a topic from the user to make a research about it, your job is to break that input into smaller subtasks to search for each subtask alone. Ensure you follow these rules when finding your response: -You shouldn't break the topic onto many tiny tasks that can be done together, because that will cost a lot. -You also shouldn't combine two different tasks into one. -Your output must be in the structured format you are given -Your list of subtasks will be given to web searchers to get information, so keep its words as simple as possible. -Make sure that the subtopics are formulated nicely for web search, just like a human would search on the web about that topic . -Make sure that your to-search subtopic is clear and that it can't have two different meanings, if it has, then include an explanation for it or a hint of which meaning is the desired one . Make sure to follow these tips: -When generating the sub-questions, make sure to ask about things that enrich the meaning and make the reader understand more. For example, if the topic is scientificial like calculus, you'd want to search for the original rule that calculus is based on (which is the limits, why do we we need them, ...) make sure to search for definition, base rule or material that the topic is based on, some theory, examples, use cases, pros and cons about the topic and things like that... Also, calculus can have different unrelated meanings, so as you are instructed above, include that we mean the mathematical concept for example : "phases of calculus in math" or something like that. Given Topic : {topic} Task: Divide and simplify the given topic of the research into smaller subtasks to search for each subtask independently on the web. """ ``` This is the prompt for the LLM used by the *Searcher* agent, which divides the main topic into sub topics. ## *output_structures.py* This file contains some Pydantic structures that serve as a blueprint for the LLM output. ## *vectordb.py* : This one contains the definition of the *vectordb* class, which is the vector database for the RAG retrieval tool. :::tip{title="tip"} for more information, see the publication : https://app.readytensor.ai/publications/simple-rag-assistant-project-X4AhWzVWUPnu ::: *** *** *** # Experiments & Results We can ask the system to generate some researches about some topics and see how well it performs. For example, if we ask the system to give us a research about linear algebra ( *see this experiment's final research at the end of the publication* ), the system divided the topic into those sub-topics: ['What is linear algebra definition', 'Fundamental concepts of linear algebra', 'Applications of linear algebra in real world', 'Why is linear algebra important', 'Basic examples of linear algebra problems'], as instructed the subtopics cover different scientific aspects of the main topic, starting from the basic definition to the fundamentals to applications and so on... So the topic was broken successfully. ### Limitations : -The first limitation to notice is the cost of the system most free APIs reach the limit after only two usages of the system. -The system doesn't store previous messages, we can't tell the system to edit anything in the output, and we have to construct all over again, and even if we could, the cost is very high -Using the systems for a few times, we can found that almost always, the final research is from 12K to 13K characters. -The final research is only consists of text. ### Future Goals: -We need to work on finding away to massively reduce the high cost of the system. -We can add memory to store previous messages, and adding a shortcut to edit the system without beginning all over again and with much lower cost. -We should find a way to make the final output longer (or even shorter if the user wants to). -We might want to add the ability to add external photos, search for them, or let an AI model generate them *** *** *** Now to see the final result: # The Example's Result *** *** ## The Foundations and Far-Reaching Applications of Linear Algebra Linear algebra stands as a fundamental branch of mathematics, dedicated to the study of vectors, vector spaces, linear transformations, and systems of linear equations. At its core, it explores "line-like relationships," which are inherently predictable, distinguishing them from more complex non-linear interactions. This field is indispensable across nearly all areas of mathematics, including modern geometry and functional analysis, as well as in physics, engineering, and computer science, where it is employed to define basic objects like lines, planes, and rotations, model natural phenomena, and significantly enhance computational efficiency. ### Fundamental Concepts and Structures The bedrock of linear algebra is built upon the concepts of **vectors** and **vector spaces**. A vector space comprises a set of vectors along with all possible linear combinations of these vectors. The operations within a vector space, such as vector addition and scalar multiplication, must adhere to specific requirements known as vector axioms, ensuring the space forms an abelian group under addition. Subsets of vector spaces that maintain these properties under the induced operations are termed **linear subspaces**. The **span** of a set of vectors refers to the complete collection of all possible linear combinations that can be formed from those vectors. A crucial concept is **linear independence**, which defines a set of vectors where no vector can be expressed as a linear combination of the others. Conversely, a set is linearly dependent if one vector can be written as a combination of the others, or if the set contains the zero vector, or if the number of vectors `p` exceeds the dimension `n` of the space `Rn`. Linear independence is vital for establishing a **basis**, which is any set of linearly independent vectors that can serve as a coordinate system for a vector space. For an n-dimensional vector space, a basis is composed of exactly `n` linearly independent vectors from that space. The **Dimension Theorem** formalizes this, stating that if a vector space V has a basis of `n` vectors, then any set in V containing more than `n` vectors must be linearly dependent, and every basis of V must consist of exactly `n` vectors. Furthermore, for a subspace H of a finite-dimensional vector space V, any linearly independent set in H can be expanded to form a basis for H, implying that H is also finite-dimensional and its dimension is less than or equal to the dimension of V (dim H ≤ dim V). The **Basis Theorem** adds that for a p-dimensional vector space (p ≥ 1), any linearly independent set of p vectors in V is a basis for V. ### Matrices, Linear Equations, and Transformations **Linear equations**, typically represented as `a1x1 + a2x2 + ... + anxn = b`, where `a`'s are coefficients, `x`'s are unknowns, and `b` is a constant, form a cornerstone of the subject. Systems of such equations are efficiently solved using **matrices**, which are rectangular arrays of numbers. In a linear system `Ax = b`, `A` is the coefficient matrix, and `(A|b)` is the augmented coefficient matrix. While matrix theory over a ring shares similarities with that over a field, determinants exist only for commutative rings, and a square matrix is invertible only if its determinant possesses a multiplicative inverse within that ring. **Linear transformations** are mappings that preserve the fundamental operations of vector addition and scalar multiplication. If T is a linear transformation, it satisfies T(0) = 0 and T(cu + dv) = cT(u) + dT(v) for all vectors u, v and scalars c, d, thereby preserving linear combinations. For any linear transformation T: Rn -> Rm, there exists a unique m x n matrix A such that T(x) = Ax, where the jth column of A is the transformation of the jth column of the identity matrix in Rn, T(ej). The coordinate mapping, which transforms a vector x into its coordinate vector [x]B with respect to a basis B, is a one-to-one linear transformation from V onto Rn. The **First Isomorphism Theorem** further clarifies linear maps, stating that for a linear map α: U -> V, its kernel (ker α) and image (im α) are subspaces, and α induces an isomorphism ᾱ: U/ker α -> im α. A direct consequence is that if U and V are finite-dimensional vector spaces and α: U -> V iis an isomorphism, then dim U = dim V. ### Eigenvalues and Eigenvectors: Unveiling Intrinsic Properties A deep understanding of linear transformations is provided by **eigenvalues and eigenvectors**. An eigenvector of a square matrix is a non-zero vector that, when multiplied by the matrix, results in a scalar multiple of itself. This scalar is the associated eigenvalue. For a triangular matrix, its eigenvalues are simply the entries on its main diagonal. A significant theorem states that if v1, ..., vr are eigenvectors corresponding to distinct eigenvalues λ1, ..., λr of an n x n matrix A, then the set {v1, ..., vr} is linearly independent. Eigenvalues are determined by solving the characteristic equation, det(A - λI) = 0. Similar n x n matrices A and B share the same characteristic polynomial and, consequently, the same eigenvalues with the same multiplicities. The **Diagonalization Theorem** provides a condition for diagonalizability: an n x n matrix A is diagonalizable if and only if it possesses `n` linearly independent eigenvectors. Alternatively, an endomorphism α ∈ End(V) is diagonalizable if and only if there exists a non-zero polynomial p(t) ∈ F[t] such that p(α) = 0, and p(t) can be factored as a product of distinct linear factors. The **Spectral Theorem** specifies that if a matrix A is symmetric (AT = A), then there exist orthonormal eigenvectors q such that Aqi = λiqi, and A can be decomposed as A = QΛQT. Eigenvalues and eigenvectors are essential for applications such as stability analysis, quantum mechanics, and the study of dynamical systems. ### Cornerstone Theorems of Linear Algebra Several theorems form the bedrock of linear algebra, unifying various concepts: * **The Invertible Matrix Theorem:** This theorem is a cornerstone, unifying numerous concepts related to square matrices. For an n x n matrix A, the following statements are equivalent: A is invertible; the system of equations Ax=b has a unique solution x for every vector b; the columns of A are linearly independent; the rows of A are linearly independent; the columns of A form a basis for Rn; the rows of A form a basis for Rn; the determinant of A is non-zero; the image of A is Rn; the kernel of A is 0; and all eigenvalues of A are non-zero. This theorem highlights the deep interconnectedness of matrix properties, linear systems, bases, and eigenvalues. * **Gilbert Strang's Fundamental Theorem of Linear Algebra:** This theorem describes the action of an m x n matrix A in terms of four fundamental subspaces: the row space, column space, null space, and left null space. * **Part 1 (Dimensions):** Addresses the dimensions of these subspaces, stating that the dimension of the column space equals the dimension of the row space (known as the **Rank Theorem**). Furthermore, the sum of the dimension of the column space and the dimension of the null space equals the number of columns, `n` (the **Rank-Nullity Theorem**), where the rank of A is the dimension of the column space and also equals the number of pivot positions in A. * **Part 2 (Orthogonality):** Emphasizes the orthogonality of these subspaces, particularly that the row space and nullspace of A are orthogonal complements in Rn. Beyond these central ideas, other significant theorems include the **Fundamental Theorem of Algebra**, which asserts that every non-constant polynomial over the complex numbers C has at least one root in C. The **Normal Matrix Theorem** and the **Principal Axis Theorem** deal with specific types of matrices and their diagonalization properties, often related to self-adjoint operators. Concepts like direct sums and quotients of vector spaces also provide integral tools for constructing and analyzing vector spaces. ### Linear Computations and Numerical Methods **Linear computations** involve numerical methods for solving linear algebra problems, including systems of linear equations and the calculation of eigenvalues and eigenvectors. These computational techniques are indispensable in computer simulations, optimizations, and various modeling tasks. Key methods for solving linear systems include Gaussian Elimination, which transforms a matrix into row-echelon form; LU Decomposition, which efficiently solves systems by splitting a matrix into lower and upper triangular components; and QR Decomposition, particularly useful for least squares problems and eigenvalue computations. Furthermore, Eigen Decomposition, where a matrix is broken down into eigenvectors and eigenvalues, is crucial for applications like dimensionality reduction (e.g., Principal Component Analysis, PCA) and matrix factorization (e.g., Singular Value Decomposition, SVD, and Non-negative Matrix Factorization, NMF) for feature extraction. ### Pervasive Applications Across Disciplines Linear algebra is an indispensable mathematical discipline with pervasive applications across diverse scientific and technological fields, serving as a cornerstone for modern advancements. * **Data Science and Machine Learning:** Linear algebra is foundational, enabling the representation of datasets as matrices and vectors for analysis and manipulation. Optimization algorithms, such as gradient descent, extensively rely on linear algebraic operations to adjust model parameters and minimize cost functions; convex optimization problems are also solved using these techniques. Neural networks and deep learning models utilize linear algebra for fundamental processes like forward and backward propagation, where input features, weights, and activations are manipulated through matrix multiplications, and for convolutional operations in Convolutional Neural Networks (CNNs). Specific applications include the formulation of loss functions, regularization techniques, the computation of covariance matrices, and the operation of Support Vector Machine (SVM) classification. Overall, linear algebra enhances algorithm efficiency, aids in understanding data structures, optimizes algorithms, processes high-dimensional data, and powers critical fields such as Natural Language Processing (NLP) and Computer Vision. * **Computer Science:** Its principles are embedded in graphics rendering, signal processing, network analysis, the Google PageRank algorithm, and error correcting codes. * **Engineering:** Disciplines leverage linear algebra for modeling systems, solving differential equations, and in computational fluid dynamics (CFD) for solving equations like the Navier-Stokes equations. * **Natural Sciences:** It benefits from its application in modeling chemical reactions and population growth, and it is fundamental to quantum mechanics through functional analysis. * **Mathematics:** Within mathematics itself, linear algebra is central to modern geometry, defining basic objects such as lines, planes, and rotations, and forms the basis of functional analysis. * **Economic and Social Sciences:** It is applied in input-output economic models, Markov chains, and linear optimization for resource allocation and scheduling, saving significant resources annually. * **Physics:** Utilizes linear algebra for tasks such as finding the principal axes of inertia of solid objects and in the optimization of particle accelerators by correcting beam trajectories. Other diverse applications include network flow analysis, electrical networks, directed graphs, and constrained optimization. ### Conclusion: An Indispensable Framework In conclusion, linear algebra provides a comprehensive framework and powerful tools for efficiently handling large datasets, performing complex computations, deriving insights from data, designing algorithms, and solving a vast array of real-world problems. Its pervasive integration across scientific and technological advancements underscores its critical role as a cornerstone of modern innovation, making it an indispensable tool for understanding and shaping the contemporary world. *** *** The final research is coherent, and structured correctly without errors. That was a 12,349 characters, 1,843 words research. But we may encounter cases where the searcher would miss important aspects of the topic, like the intuition behind the formal definitions and some examples in our topic, and I believe that the very next step should be making sure that this problem doesn't happen. We could also connect the agent to a scientific articles and papers website in the future. But for now, it does its simple purpose 53:T6a49,![multi-agent-system-image.jpg](multi-agent-system-image.jpg) ## TL;DR ApplyAI is a production-deployed multi-agent AI system that automates the job application process. Given a resume (PDF) and any form of job input — a URL, company website, company name, or pasted description — the system orchestrates five specialized AI agents to parse the resume, research the role, match skills, generate a tailored cover letter, and critique and polish the output. Built with LangGraph for agent orchestration, LangChain for LLM abstraction, and FastAPI for the backend, it is deployed with a React/Vite frontend on Vercel and a Railway-hosted API. This publication documents the multi-agent architecture, implementation decisions, deployment strategy, and lessons learned. ## 1. Introduction ### 1.1 Problem Statement Writing a tailored cover letter for every job application is time-consuming and cognitively demanding. A good cover letter requires understanding the job requirements, identifying relevant skills from your background, framing your experience compellingly, and polishing the final output — four distinct tasks that most people do sequentially and imperfectly. General-purpose LLMs can help, but a single prompt asking an LLM to "write me a cover letter" produces generic, placeholder-filled output because the model lacks structured access to both the resume and the job details simultaneously. It also cannot route different types of job input (a LinkedIn URL vs. a company name vs. a pasted description) or perform web scraping to extract job details from live pages. ### 1.2 What This Project Builds ApplyAI is a complete agentic system that solves this problem end-to-end: - Accepts a PDF resume and any form of job input from the user - Routes the input to the appropriate processing pipeline - Analyzes the resume and researches the job in parallel - Matches skills using fuzzy matching to produce an accurate compatibility score - Generates a tailored, grounded cover letter using the full resume text and job context - Critiques and polishes the letter using a stronger LLM model - Delivers results through a clean React dashboard with match score visualization, skill breakdown, and an editable cover letter with copy/download ### 1.3 Why It Matters This project demonstrates several important capabilities in modern AI engineering: - **Multi-agent orchestration** using LangGraph's stateful graph execution - **Parallel agent execution** — resume analysis and job research run simultaneously, cutting latency in half - **Dynamic routing** — the input router makes a classification decision that changes the downstream pipeline behavior - **Tool use** — agents use dedicated tools (web scraper, resume parser, skill matcher) to interact with the real world - **Full-stack deployment** — the system goes from local development to a publicly accessible production application ## 2. System Architecture ### 2.1 Agent Pipeline Overview The system uses a LangGraph `StateGraph` to orchestrate five agents in a directed workflow with a parallel fan-out pattern: ``` ┌─────────────────┐ │ input_router │ │ Classifies job │ │ input type │ └────────┬────────┘ │ Fan-out (parallel) ┌──────────────┴──────────────┐ ▼ ▼ ┌──────────────────┐ ┌───────────────────┐ │ resume_analyzer │ │ job_researcher │ │ Extracts skills │ │ Scrapes/infers │ │ + personal info │ │ job description │ │ from PDF │ │ + extracts skills│ └──────────┬───────┘ └─────────┬─────────┘ │ │ └──────────────┬────────────┘ │ Fan-in ▼ ┌─────────────────────┐ │ application_generator│ │ Matches skills, │ │ generates cover │ │ letter │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ critic_agent │ │ Polishes letter, │ │ removes commentary │ └──────────┬──────────┘ │ ▼ END ``` ### 2.2 Shared State All agents communicate through a shared `AgentState` TypedDict. LangGraph requires every field to have a reducer function when parallel fan-out is used — without this, concurrent state writes from two nodes cause an `InvalidUpdateError`. The state uses two custom reducers: ```python def _keep_last(a, b): """Last non-empty value wins — for strings and dicts.""" return b if b else a def _merge_lists(a: list, b: list) -> list: """Keep whichever list is non-empty — for skill lists.""" return b if b else a class AgentState(TypedDict): resume_text: Annotated[str, _keep_last] user_input: Annotated[str, _keep_last] input_type: Annotated[str, _keep_last] job_description: Annotated[str, _keep_last] scraped_job_title: Annotated[str, _keep_last] personal_info: Annotated[Dict, _keep_last] resume_skills: Annotated[List[str], _merge_lists] job_skills: Annotated[List[str], _merge_lists] match_results: Annotated[Dict, _keep_last] cover_letter: Annotated[str, _keep_last] improved_cover_letter:Annotated[str, _keep_last] ``` ### 2.3 Technology Stack | Component | Technology | Role | |-----------|-----------|------| | Agent Orchestration | LangGraph | Stateful graph, parallel execution, routing | | LLM Framework | LangChain | Prompt templates, LLM abstraction, output parsers | | LLM Provider | Groq (Llama 3.1 8B / 3.3 70B) | Fast inference for generation and critique | | Resume Parsing | pdfplumber | PDF text extraction | | Web Scraping | requests + BeautifulSoup | Job posting and company website scraping | | Skill Matching | Python difflib (SequenceMatcher) | Fuzzy skill comparison | | Backend | FastAPI + Uvicorn | REST API, file upload handling | | Frontend | React 18 + Vite + CSS Modules | Chat-style results dashboard | | Backend Hosting | Railway | Persistent server, no serverless timeout | | Frontend Hosting | Vercel | Static site CDN | --- ## 3. Agent Implementation ### 3.1 Agent 1: Input Router The input router classifies the user's job input into one of four categories: `job_url`, `company_website`, `company_name`, or `job_description`. This classification determines how the `job_researcher` agent processes the input downstream. ```python JOB_URL_PATTERNS = re.compile( r"(jobs|careers|job|career|position|vacancy|opening|posting|apply)", re.IGNORECASE, ) def input_router(state: dict) -> dict: user_input = state["user_input"].strip() # URL detection via regex if re.match(r"https?://", user_input): if JOB_URL_PATTERNS.search(user_input): state["input_type"] = "job_url" else: state["input_type"] = "company_website" return state # LLM classification for plain text prompt = f"""Classify this input as exactly one of: - company_name - job_description Reply with only the label. Input: \"\"\"{user_input}\"\"\"""" response = llm.invoke(prompt) label = response.content.strip().lower() # Sanitize with heuristic fallback if label not in ("company_name", "job_description"): label = "job_description" if len(user_input.split()) > 20 else "company_name" state["input_type"] = label return state ``` **Design decision:** URL classification uses regex (fast, no LLM cost). Text classification uses an LLM with an explicit fallback heuristic — if the LLM returns an unexpected label, long inputs are treated as descriptions and short inputs as company names. ### 3.2 Agent 2: Resume Analyzer (Parallel) The resume analyzer runs in parallel with the job researcher. It performs two tasks: 1. **Personal info extraction** using regex — pulls name, email, and phone from the resume text to populate cover letter headers without placeholders 2. **Skill extraction** using an LLM with explicit JSON output format ```python prompt = f"""Extract ALL technical and professional skills from the resume. Normalize skill names (e.g. "MS Azure" → "Microsoft Azure"). Return ONLY a valid JSON array of strings. No explanation. Resume: {resume_text}""" ``` The LLM is instructed to normalize skill names (e.g., "AWS" → "Amazon Web Services (AWS)") so they align with how job postings phrase the same skills — a critical step for accurate matching. ### 3.3 Agent 3: Job Researcher (Parallel) The job researcher handles all four input types differently: | Input Type | Strategy | |-----------|----------| | `job_url` | Scrape the URL, extract job description text | | `company_website` | Scrape homepage, use LLM to infer a realistic job description | | `company_name` | Use LLM to generate a realistic job description for that company | | `job_description` | Use the text directly | The web scraper uses BeautifulSoup with a priority strategy — it first looks for job-specific CSS containers (classes matching `job`, `description`, `career`, etc.), then falls back to all meaningful tags (`p`, `li`, `h1`–`h4`, `span`, `div`). This extracts up to 8,000 characters of relevant content even from job sites that don't follow standard markup conventions. After resolving the description, the agent extracts required skills using the same JSON-format LLM prompt used by the resume analyzer, ensuring consistent normalization between the two skill lists. ### 3.4 Tool: Fuzzy Skill Matcher The naive approach — exact set intersection of skill lists — produces a 0% match score for obvious reasons: "Azure" never matches "Microsoft Azure", and "AWS" never matches "Amazon Web Services (AWS)". The fuzzy matcher uses Python's `SequenceMatcher` with substring containment: ```python def _fuzzy_match(a: str, b: str, threshold: float = 0.82) -> bool: a, b = a.lower().strip(), b.lower().strip() if a == b: return True if a in b or b in a: # handles abbreviations return True return SequenceMatcher(None, a, b).ratio() >= threshold ``` This correctly matches: - `"AWS"` ↔ `"Amazon Web Services (AWS)"` (substring containment) - `"scikit-learn"` ↔ `"sklearn"` (fuzzy ratio) - `"REST API"` ↔ `"REST APIs"` (fuzzy ratio) ### 3.5 Agent 4: Application Generator The application generator is where the cover letter is created. Earlier versions used only skill lists as input, producing generic output with placeholder text (`[Your Name]`, `[Company Name]`). The improved version passes: - Full resume text (not just skill list) - Job description - Matched and missing skills with the match score - Real personal info (name, email, phone) extracted by the resume analyzer ```python prompt = f"""You are a professional career coach writing a cover letter. APPLICANT: {candidate_name} | {candidate_email} | {candidate_phone} DATE: {today} FULL RESUME: {resume_text} JOB DESCRIPTION: {job_description} SKILL MATCH: {score}% — Matched: {matched} | To address: {missing[:6]} INSTRUCTIONS: - Use the applicant's REAL name and contact details — never use placeholders - Highlight 2–3 specific achievements from the resume most relevant to the role - For missing skills, briefly acknowledge eagerness to grow — do not dwell on gaps - Output ONLY the cover letter — no preamble or notes """ ``` ### 3.6 Agent 5: Critic Agent The critic agent uses a stronger model (`llama-3.3-70b-versatile`) to review and polish the generated letter. A persistent problem with LLM critics is that they append "Improvements made:" commentary after the polished letter. The critic agent addresses this with: 1. Explicit instructions in the prompt: "Output ONLY the final polished letter, nothing else" 2. A post-processing step that cuts off text after known commentary phrases: ```python cutoff_phrases = [ "improvements made", "changes made", "notes:", "here's what i changed", "explanation:", "i made the following", ] lower = letter_text.lower() for phrase in cutoff_phrases: idx = lower.find(phrase) if idx != -1: letter_text = letter_text[:idx].strip() ``` --- ## 4. Frontend ![Screenshot from 2026-04-13 16-42-35.png](Screenshot%20from%202026-04-13%2016-42-35.png) ### 4.1 Upload Page The upload page accepts a PDF resume via drag-and-drop (`react-dropzone`) and job input via four selectable modes: Job Posting URL, Company Website, Company Name, or Paste Job Description. While the agents are running, an animated progress bar cycles through human-readable status messages ("Parsing your resume…", "Researching the role…", "Matching your skills…") to communicate progress during the ~30–60 second pipeline execution. ![Screenshot from 2026-04-13 16-48-21.png](Screenshot%20from%202026-04-13%2016-48-21.png) ### 4.2 Results Dashboard The results page presents three panels: **Skill Match Score** — an animated SVG ring chart showing the fuzzy match percentage. The ring color is green (≥70%), yellow (≥40%), or red (<40%) with a verdict label ("Strong match", "Moderate match", "Low match"). **Matched / Missing Skills** — color-coded pill badges. Matched skills appear in green, missing skills in red. Lists longer than 8 items collapse with a "Show more" toggle. **Cover Letter Panel** — a full-height editable textarea pre-populated with the polished cover letter. Copy-to-clipboard and download-as-txt buttons are provided. Users can edit the letter directly in the browser before using it. --- ## 5. Deployment ### 5.1 Backend — Hugging Face Spaces The FastAPI backend is deployed on Hugging Face Spaces as a persistent Docker container. Serverless platforms (Vercel Functions) and Railway were ruled out because: The LangGraph pipeline can take 30–60 seconds to complete (scraping + 3 LLM calls) Vercel's free tier enforces a 10-second function timeout Railway's free tier expires after 30 days Hugging Face Spaces runs the application as a persistent Docker container with no execution time limit, no sleep on inactivity, and no free tier expiry: dockerfileFROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 7860 CMD ["python", "-m", "uvicorn", "api:app", "--host", "0.0.0.0", "--port", "7860"] Note: Hugging Face Spaces requires port 7860. Using python -m uvicorn instead of calling uvicorn directly avoids PATH resolution issues inside the container where pip-installed binaries may not be on $PATH. Key deployment challenges encountered: Missing README metadata — HF Spaces requires a README.md with a YAML front matter block (sdk: docker) at the repository root. Without it, the Space shows a "Configuration error" and refuses to build. Missing dependencies — requirements.txt was missing uvicorn and pdfplumber because they were installed in the local virtual environment but not captured in the freeze. Regenerating with pip freeze > requirements.txt from the active venv resolved this. Initial push rejection — HF auto-initializes Spaces with a commit, causing a non-fast-forward push error on first push. Fixed with git push hf main --force. ### 5.2 Frontend — Vercel The Vite React frontend is deployed as a static site: Root directory: frontend/ Build command: npm run build Output directory: dist The Vite dev proxy (/api → http://localhost:8000) handles local development. In production, axios.post('https://fahiye-applyai-backend.hf.space/analyze', ...) calls the HF Space backend directly with no proxy needed. Since the frontend and backend are on different domains, the FastAPI backend has allow_origins=["*"] set via CORSMiddleware. --- ## 6. Project Structure ``` job-application-agent/ ├── api.py # FastAPI entry point ├── main.py # CLI entry point ├── Procfile # Railway start command ├── requirements.txt ├── agents/ │ ├── input_router.py # Agent 1: classify input │ ├── resume_analyzer.py # Agent 2: extract resume skills │ ├── job_researcher.py # Agent 3: research job + skills │ ├── application_generator.py # Agent 4: generate cover letter │ └── critic_agent.py # Agent 5: polish cover letter ├── graph/ │ ├── agent_workflow.py # LangGraph StateGraph definition │ └── state.py # AgentState with Annotated reducers ├── tools/ │ ├── resume_parser.py # pdfplumber + personal info regex │ ├── job_scraper.py # BeautifulSoup web scraper │ └── skill_matcher.py # Fuzzy SequenceMatcher └── frontend/ ├── src/ │ ├── App.jsx # Router + state │ ├── pages/ │ │ ├── UploadPage.jsx # Drag-drop + input form │ │ └── ResultsPage.jsx # Match dashboard + letter editor │ └── components/ │ └── Navbar.jsx └── vite.config.js ``` --- ## 7. Key Design Decisions and Lessons Learned ### 7.1 LangGraph Parallel Fan-Out Requires Annotated State The most technically significant lesson was that LangGraph's parallel execution requires every state field to have an explicit reducer function — not just the fields written by parallel nodes. When `resume_analyzer` and `job_researcher` both return the full state dict, LangGraph tries to merge all fields simultaneously. Without reducers, this raises `InvalidUpdateError: Can receive only one value per step`. The fix — wrapping every field with `Annotated[type, reducer_fn]` — is not prominent in LangGraph's documentation for simple sequential graphs. It only becomes necessary when adding parallel edges. ### 7.2 Skill Normalization Is the Core of Matching Quality The original skill matcher used exact set intersection and produced a 0% match score. The root cause was not the matching algorithm — it was inconsistent normalization. "Azure" and "Microsoft Azure" are the same skill, but without normalization they are different strings. The solution has two parts: (1) prompt the LLM skill extractors to normalize to full canonical names, and (2) use fuzzy matching with substring containment as a safety net. Both are necessary — LLM normalization is imperfect, and fuzzy matching catches the cases the LLM misses. ### 7.3 Cover Letter Quality Requires Full Resume Context The first version of the application generator passed only skill lists to the LLM. The output was generic because the LLM had no knowledge of the candidate's actual experience, projects, or achievements. Passing the full resume text (even at 2,000+ tokens) dramatically improved specificity — the LLM could reference real projects, real employers, and real accomplishments. The practical concern about token costs is real but manageable: at Groq's free tier, even a 3,000-token resume adds negligible latency and zero cost. ### 7.4 LLM Critics Append Commentary by Default Instructing an LLM to "improve this cover letter" consistently produces the improved letter followed by "Improvements made: 1. Clarity..." commentary. This is the default behavior of instruction-tuned models, which are trained to explain their reasoning. Two countermeasures work together: (1) strong explicit prompt instructions to output only the letter, and (2) deterministic post-processing that truncates at known commentary phrases. The post-processing acts as a safety net for the cases where the LLM ignores the prompt instruction. ### 7.5 Web Scraping Is Unreliable — Design for Fallback Not all company websites are scrapable. Single-page React apps render content in the browser, not in the raw HTML. Some sites block scrapers via user-agent filtering. The scraper handles these cases with a cascade: 1. Try job-specific CSS containers (highest signal-to-noise) 2. Fall back to all meaningful tags 3. Fall back to full page text 4. If <100 chars extracted, use a hardcoded fallback description The job researcher also falls back gracefully: if the input type is `company_website` but the scraped content is empty, it prompts the LLM to generate a realistic job description based on the company name extracted from the URL. --- ## 8. Limitations and Future Directions ### 8.1 Current Limitations - **Scraping limitations:** Many modern job sites (LinkedIn, Greenhouse, Lever) render content via JavaScript and are not scrapable with `requests` + BeautifulSoup. A headless browser (Playwright, Selenium) would be required for these. - **Single LLM provider:** The system is hardcoded to Groq. A provider abstraction layer would enable model switching without code changes. - **No user accounts:** Resume and results are not persisted. Users cannot return to previous applications. - **Pipeline latency:** The full pipeline (scraping + 3 LLM calls) takes 30–60 seconds. There is no streaming — the user sees a loading spinner until the entire result is ready. - **English only:** All prompts and the skill matcher are tuned for English-language resumes and job descriptions. ### 8.2 Future Directions - **Playwright integration** for JavaScript-rendered job sites (LinkedIn, Indeed, Greenhouse) - **Streaming cover letter generation** using FastAPI `StreamingResponse` and server-sent events on the frontend — renders the letter token-by-token as it is generated - **Application history** — store past applications in SQLite or Supabase so users can revisit and compare cover letters - **Multi-language support** — detect resume language and adapt prompts accordingly - **Interview preparation agent** — a 6th agent that uses the job description and matched skills to generate likely interview questions and suggested answers - **Cover letter tone selector** — let users choose between formal, confident, or conversational tone before generation --- ## 9. Reproducing the Project ### 9.1 Prerequisites - Python 3.10+ - Node.js 18+ - A Groq API key (free at [console.groq.com](https://console.groq.com)) ### 9.2 Local Setup ```bash # Clone the repository git clone https://github.com/fahiyemuhammad/job-application-agent.git cd job-application-agent # Create and activate virtual environment python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # Install dependencies pip install -r requirements.txt # Set environment variables echo "GROQ_API_KEY=your_key_here" > .env # Run the CLI version python main.py # Or start the FastAPI backend uvicorn api:app --reload --port 8000 ``` ```bash # Frontend (separate terminal) cd frontend npm install npm run dev ``` Open `http://localhost:5173`. ### 9.3 Environment Variables | Variable | Required | Description | |----------|----------|-------------| | `GROQ_API_KEY` | Yes | Groq API key for LLM inference | ### 9.4 Deployment **Backend (Railway):** 1. Connect GitHub repo to Railway 2. Set start command: `cd src && uvicorn api:app --host 0.0.0.0 --port $PORT` 3. Add `GROQ_API_KEY` environment variable 4. Deploy and copy the public domain **Frontend (Vercel):** 1. Import the same GitHub repo 2. Set root directory to `frontend/` 3. Framework: Vite | Build: `npm run build` | Output: `dist` 4. No environment variables needed (backend URL is hardcoded in `UploadPage.jsx`) 5. Deploy --- ## 10. Conclusion ApplyAI demonstrates that multi-agent systems built with LangGraph can solve real, practical problems in a production-deployable way. The key architectural insight is the separation of concerns across agents — each agent does one thing well, and LangGraph's stateful graph handles the coordination, including parallel execution that would otherwise require complex async programming. The most important engineering lessons from this project are: parallel LangGraph nodes require Annotated state reducers, skill matching quality depends on normalization before matching, LLM critics need deterministic post-processing to suppress commentary, and full resume context produces dramatically better cover letters than skill lists alone. The full source code is available in the linked repository. --- ## References 1. LangGraph Documentation — Stateful Multi-Agent Workflows. https://langchain-ai.github.io/langgraph/ 2. LangChain Documentation. https://docs.langchain.com 3. Wang, L. et al. (2024). *A Survey on Large Language Model based Autonomous Agents*. Frontiers of Computer Science. https://arxiv.org/abs/2308.11432 4. Xi, Z. et al. (2023). *The Rise and Potential of Large Language Model Based Agents: A Survey*. https://arxiv.org/abs/2309.07864 5. FastAPI Documentation. https://fastapi.tiangolo.com 6. Groq — Fast AI Inference. https://console.groq.com 7. Meta AI. *Llama 3 Model Card*. https://github.com/meta-llama/llama3 ## License This project is released under the **MIT License**. You are free to use, modify, distribute, and build upon this work for both personal and commercial purposes, provided the original copyright notice is retained. See the [LICENSE](https://github.com/fahiyemuhammad/job-application-agent/blob/main/LICENSE) file in the repository for full terms.54:T7b50,![Multi-Agent System Overview](https://raw.githubusercontent.com/samrat-kar/rag-research-assistant/main/Multi-agent-AI-system-overview.png) **GitHub Repository:** [samrat-kar/rag-research-assistant](https://github.com/samrat-kar/rag-research-assistant) --- ## Introduction Chatbots built on large language models have a well-known failure mode: they confidently generate plausible-sounding answers that are factually wrong — a problem known as **hallucination**. This is especially damaging when users need accurate, verifiable information on a specific topic, and it gets worse when the knowledge required is either recent (not in the model's training data) or proprietary (stored in internal documents the model has never seen). This project addresses both failure modes simultaneously. Rather than relying on a single LLM to both search and synthesise, it decomposes the research task across **three specialised AI agents**, each with a clearly bounded responsibility: - A **Research Agent** that gathers evidence from the live web and a local document corpus. - An **Analyst Agent** that validates those findings, resolves conflicts, and verifies numbers. - A **Writer Agent** that synthesises the validated evidence into a clean, source-cited report. The three agents are orchestrated in a deterministic sequential pipeline using **CrewAI**, with explicit context handoffs between stages — the output of each agent becomes the grounded input for the next. This separation of concerns makes the system more reliable than a single-agent approach and the output more auditable. The project also ships a simpler single-agent interactive demo (`demo.py`) backed by the same local knowledge base, useful for quick Q&A without running the full pipeline. --- ## Key Concepts Understanding the system requires familiarity with a handful of foundational ideas. This section explains each briefly. ### What is RAG (Retrieval-Augmented Generation)? A standard LLM is a closed system: it can only answer questions from patterns baked into its training weights. If you need answers grounded in your own documents — or in information published after the training cutoff — the model has no way to access that knowledge. **RAG solves this by injecting retrieved context into the prompt at query time.** The workflow has two phases: 1. **Indexing (offline):** Documents are split into chunks, each chunk is converted into a dense vector (embedding) that captures its semantic meaning, and those vectors are stored in a searchable index. 2. **Retrieval + Generation (online):** When a question arrives, the same embedding model converts it into a vector, the index is searched for the nearest matching chunks, and those chunks are appended to the LLM's prompt. The model generates an answer *conditioned on that retrieved evidence*, not on memory alone. The result is an LLM that can cite sources, stay current, and reason over private data — without any fine-tuning. ### What are Vector Embeddings? An embedding is a list of numbers (a vector) that represents the meaning of a piece of text. Texts with similar meanings have vectors that are close together in high-dimensional space, measured by **cosine similarity**. This is what allows semantic search: instead of matching keywords, the system finds chunks that mean roughly the same thing as the query, even if they use different words. This project uses OpenAI's `text-embedding-3-small` model, which produces 1,536-dimensional vectors. ### What is a Multi-Agent System? A single LLM call mixes retrieval, reasoning, and writing into one opaque step. That makes errors hard to trace and easy to compound: a hallucinated "fact" retrieved in the first sentence contaminates everything that follows. A **multi-agent system** breaks the task into stages, assigns each stage to a specialised agent, and passes structured outputs between them. The agents in this project are purpose-limited by design: the Research Agent cannot draw conclusions, the Analyst Agent cannot do free-form writing, and the Writer Agent cannot retrieve new information. Each constraint prevents a whole class of errors. ### What is CrewAI? [CrewAI](https://www.crewai.com/) is an open-source Python framework for orchestrating multiple LLM agents as a coordinated "crew". It handles the plumbing: defining agent roles and goals, managing tool calls, passing context between tasks, and running tasks in sequence or in parallel. In this project, CrewAI's `Process.sequential` mode enforces a strict Research → Analyse → Write order, with each task's output explicitly wired as context to the next. ### What is Tavily? [Tavily](https://tavily.com/) is a search API built specifically for LLM workflows. Unlike scraping raw Google results, it returns clean, LLM-friendly summaries of web pages, including source URLs. The Research Agent uses it to pull live, up-to-date information that the local knowledge base may not contain. --- ## System Architecture ``` User Question │ ▼ ┌──────────────────────────────┐ TavilySearchTool (live web) │ Research Agent │◄─ LocalRAGSearchTool (local docs) │ │ │ Goal: Gather evidence from │ │ web + local knowledge base │ │ Output: bullet notes + │ │ sources list │ └──────────────┬───────────────┘ │ research notes + sources (via context=) ▼ ┌──────────────────────────────┐ CalculatorTool (verified arithmetic) │ Analyst Agent │◄─ LocalRAGSearchTool (cross-check) │ │ │ Goal: Validate claims, │ │ resolve source conflicts, │ │ verify numbers │ │ Output: analysis summary │ │ + answer outline │ └──────────────┬───────────────┘ │ analysis summary + outline (via context=) ▼ ┌──────────────────────────────┐ SaveReportTool │ Writer Agent │──► outputs/report.md │ │ │ Goal: Write structured, │ │ cited Markdown report │ │ No retrieval tools — │ │ writes from evidence only │ └──────────────────────────────┘ ``` Each stage passes its output as explicit `context` to the next task via CrewAI's `context=` parameter, ensuring a fully deterministic Research → Analyse → Write flow with no information leakage from outside the pipeline. ### Why Three Separate Stages? The three-stage design is not arbitrary — each stage removes a distinct failure mode: | Stage | Failure mode it prevents | |---|---| | Research Agent (retrieval only) | LLM making up facts when no search is performed | | Analyst Agent (validation only) | Conflicting sources silently resolved in favour of the wrong one | | Writer Agent (write only, no retrieval) | New hallucinated content injected at the final stage | A single-agent approach merges all three into one opaque LLM call. If the final answer is wrong, there is no clean way to tell which stage introduced the error. With three separated agents, each stage's output is inspectable independently. --- ## Agent Roles and Responsibilities ### Research Agent | Attribute | Value | |---|---| | **Role** | Research Agent | | **Goal** | Collect reliable information from the web and local knowledge base to answer the user's query | | **Tools** | `TavilySearchTool`, `LocalRAGSearchTool` | | **Output** | Bullet-pointed research notes with a Sources section listing URLs and/or local file names | | **Delegation** | Disabled — operates independently, does not hand off mid-task | The Research Agent is the first to act. It queries both live web search (Tavily) and the local document corpus (via semantic embedding retrieval) to collect raw evidence. It is deliberately constrained: it does not draw conclusions, make recommendations, or synthesise findings. Its sole job is evidence gathering with source attribution. This means downstream agents always know the provenance of every claim. ### Analyst Agent | Attribute | Value | |---|---| | **Role** | Analyst Agent | | **Goal** | Analyse research notes, reconcile conflicts, compute any needed numbers, and produce bulletproof conclusions | | **Tools** | `CalculatorTool`, `LocalRAGSearchTool` | | **Input** | Research Agent's notes (via `context=` parameter) | | **Output** | Analysis summary and a clear answer outline (sections + key bullets) | | **Delegation** | Disabled — validates, does not regenerate research | The Analyst Agent receives the Research Agent's notes and critically evaluates them. If sources disagree, it surfaces the conflict rather than silently picking one. If the question involves numbers, it verifies them using the sandboxed `CalculatorTool`. It may also re-query the local knowledge base to cross-check claims. Its output is a structured answer outline, not a final report — the structure is intentional, as it forces the Analyst to commit to conclusions before the Writer embellishes them. ### Writer Agent | Attribute | Value | |---|---| | **Role** | Writer Agent | | **Goal** | Write the final grounded answer in a clean report format with clear sections and sources | | **Tools** | `SaveReportTool` | | **Input** | Analyst Agent's summary (via `context=` parameter) | | **Output** | A saved `outputs/report.md` in structured Markdown format | | **Delegation** | Disabled — writes only what can be supported by prior stages | The Writer Agent has **no retrieval tools** — this is a key architectural constraint. It is intentionally limited to writing from what the Analyst provided, preventing the Writer from re-introducing hallucinated content at the final stage. In many single-agent systems, the last "write this up nicely" step is where the model drifts back to pattern-matching from training data. Removing retrieval tools from the Writer eliminates that failure path entirely. --- ## Tools | Tool | Class | Used By | Purpose | |---|---|---|---| | `TavilySearchTool` | `crewai_tools.TavilySearchTool` | Research Agent | Live web search for up-to-date information | | `LocalRAGSearchTool` | `src/tools.py` | Research Agent, Analyst Agent | Semantic search over `./data` files using OpenAI embeddings and cosine similarity | | `CalculatorTool` | `src/tools.py` | Analyst Agent | Safe sandboxed arithmetic — only numeric operators allowed, no imports | | `SaveReportTool` | `src/tools.py` | Writer Agent | Writes the final Markdown report to `./outputs/`, with path sanitisation | ### LocalRAGSearchTool — How It Works The `LocalRAGSearchTool` is backed by an in-memory `VectorDB` (`src/vectordb.py`) built at startup: 1. **Ingestion** — Documents in `./data` (`.txt`, `.md`, `.csv`, `.json`) are read as UTF-8 text. 2. **Chunking** — Each document is split into 500-character chunks with 50-character overlap using `RecursiveCharacterTextSplitter`. Overlap ensures that sentences at chunk boundaries are not lost. 3. **Embedding** — Chunks are embedded with `text-embedding-3-small` (1,536-dim) via OpenAI. 4. **Retrieval** — At query time, the query is embedded and compared against all chunk vectors using cosine similarity. Top-k chunks are returned with source filenames. The same vector index is shared between the Research Agent and Analyst Agent, ensuring both operate from the same local evidence base. ### CalculatorTool — Why a Safe Evaluator? LLMs are notoriously unreliable at arithmetic, especially for multi-step calculations. The `CalculatorTool` solves this by delegating all numeric computation to Python's `eval()` — but with a strict allowlist of characters (`0-9 + - * / ( ) . %`). Any expression containing letters, imports, or function calls is rejected before execution. This sandboxing prevents prompt injection via crafted expressions while still giving the Analyst a reliable arithmetic oracle. --- ## CrewAI Orchestration The crew uses `Process.sequential` — each task runs to completion before the next begins. Context is passed explicitly: ```python analysis_task = Task(..., context=[research_task]) # receives research output writing_task = Task(..., context=[analysis_task]) # receives analysis output ``` This deterministic handoff eliminates non-determinism from parallel or hierarchical coordination and makes the pipeline easy to debug: if the final report is wrong, you can inspect each stage's output independently in the console log. --- ## System in Action ### Running the Multi-Agent Pipeline ```bash python -m src.main "Compare solar and wind energy efficiency" ``` Below is a representative console session showing what each agent does in real time: ``` [2026-03-28 14:22:01] INFO Building vector index from ./data (7 documents)... [2026-03-28 14:22:04] INFO Vector index ready. Starting crew... > Entering new CrewAgentExecutor chain... ╔══════════════════════════════════════════════════════╗ ║ Research Agent — Evidence Gathering ║ ╚══════════════════════════════════════════════════════╝ Thought: I need to find information about solar and wind energy efficiency. I'll search the web for current statistics, then check the local knowledge base. Action: tavily_search_results_json Action Input: {"query": "solar panel efficiency vs wind turbine capacity factor 2024"} Observation: [Tavily] Solar photovoltaic panels achieve 15–22% efficiency commercially (up to 29% in lab settings). Offshore wind turbines reach 40–50% capacity factor... Sources: [https://iea.org/...], [https://energy.gov/...] Action: local_rag_search Action Input: {"query": "solar wind energy efficiency comparison", "top_k": 4} Observation: [1] Source: sustainable_energy.txt Solar power conversion efficiency has improved dramatically from ~6% in 1954 to over 22% today for commercial silicon panels... [2] Source: sustainable_energy.txt Wind turbines convert kinetic energy at 35–45% capacity factor onshore, rising to 45–55% offshore where wind speeds are higher and more consistent... Final Answer (Research Agent): ## Research Notes: Solar vs Wind Energy Efficiency **Solar Energy:** - Commercial panels: 15–22% efficiency (ratio of solar energy in → electricity out) - Best commercial: ~22–23% (monocrystalline silicon) - Lab record: ~29% (multi-junction cells) - Trend: improving ~0.5% per year **Wind Energy:** - Onshore capacity factor: 35–45% - Offshore capacity factor: 45–55% - Theoretical maximum (Betz limit): 59.3% - Trend: growing turbine size increasing yield **Note:** Efficiency metrics differ — solar uses conversion efficiency, wind uses capacity factor. Direct comparison requires context. **Sources:** - https://iea.org/reports/solar-pv (web) - https://energy.gov/wind-efficiency (web) - sustainable_energy.txt (local) ╔══════════════════════════════════════════════════════╗ ║ Analyst Agent — Validation & Analysis ║ ╚══════════════════════════════════════════════════════╝ Thought: I have research notes. Key issue: the metrics are not directly comparable. Solar uses conversion efficiency; wind uses capacity factor. I need to flag this. Let me also verify the percentage figures using the calculator. Action: calculator Action Input: {"expression": "59.3 * 0.75"} Observation: 44.475 [Analyst notes: real-world wind turbines achieve ~75% of the Betz limit, confirming the 40–45% capacity factor range is physically consistent] Final Answer (Analyst Agent): ## Analysis Summary **Core finding:** Solar and wind use *different efficiency metrics* — a direct number comparison is misleading without context. **Solar (conversion efficiency):** measures how much incident sunlight becomes electricity. Commercial: 15–22%. Lab: up to 29%. **Wind (capacity factor):** measures actual output vs theoretical maximum output over time. Onshore: 35–45%. Offshore: 45–55%. Betz-limit ceiling: 59.3%. **Conflict resolution:** No source conflicts detected. Web and local sources are consistent within measurement error. **Answer outline:** 1. Short answer: both are competitive; metrics differ 2. Solar efficiency detail + trend 3. Wind capacity factor detail + trend 4. Comparison caveat: apples vs oranges 5. Cost context: both are grid-competitive as of 2024 6. Sources ╔══════════════════════════════════════════════════════╗ ║ Writer Agent — Report Composition ║ ╚══════════════════════════════════════════════════════╝ Action: save_report Action Input: {"filename": "report.md", "content": "# Solar vs Wind..."} Observation: Saved report to: outputs/report.md > Finished chain. ===== FINAL RESULT ===== Report saved to: outputs/report.md ``` --- ### Generated Report (`outputs/report.md`) ```markdown # Solar vs Wind Energy Efficiency ## Short Answer Solar panels convert 15–22% of incident sunlight into electricity. Wind turbines achieve a 35–45% capacity factor onshore and 45–55% offshore — but these are different metrics and should not be compared directly as raw numbers. ## Explanation **Solar Photovoltaic Efficiency** - Measures the fraction of sunlight converted to electricity - Commercial silicon panels: 15–22% (monocrystalline cells reaching ~22–23%) - Laboratory record: ~29% using multi-junction cell technology - Efficiency has improved by roughly 0.5 percentage points per year since 2010 - Cost: ~$0.04–0.06/kWh as of 2024 (utility scale) **Wind Turbine Capacity Factor** - Measures actual annual output vs maximum possible output if running 100% of the time - Onshore: 35–45% capacity factor under good wind conditions - Offshore: 45–55% due to stronger, more consistent winds - Theoretical ceiling (Betz limit): 59.3% — no turbine can exceed this - Cost: ~$0.03–0.05/kWh onshore; ~$0.08–0.10/kWh offshore as of 2024 **Comparing the Two** - The metrics measure different things: solar efficiency is an instantaneous conversion ratio; wind capacity factor is a time-averaged utilisation measure - Both technologies are cost-competitive with natural gas as of 2024 - Solar is better suited to sun-rich regions; wind to coastal and high-altitude areas - Many utility-scale projects now combine both for complementary generation profiles ## Sources - sustainable_energy.txt (local knowledge base) - https://iea.org/reports/solar-pv - https://energy.gov/wind-efficiency ``` --- ### Interactive Demo (`demo.py`) For quick Q&A without the full pipeline, `demo.py` runs a single-agent assistant backed by the same local knowledge base: ``` $ python demo.py Loading documents from ./data... 7 documents loaded. Building vector index... done. Example queries (tool-calling agent): Q: What is machine learning? A: Machine learning is a subset of artificial intelligence that enables systems to learn from data and improve their performance without being explicitly programmed. It encompasses supervised learning (labelled training data), unsupervised learning (pattern discovery), and reinforcement learning (reward-based optimisation). Sources: artificial_intelligence.txt Q: How does deep learning work? A: Deep learning uses artificial neural networks with multiple layers (hence "deep") to learn hierarchical representations of data. Lower layers detect simple features (edges, tones); higher layers combine them into abstract concepts (faces, sentiment). Training adjusts the weights via backpropagation to minimise a loss function. Sources: artificial_intelligence.txt Q: What are key AI ethics concerns? A: Key concerns include: bias and fairness (models reflecting historical prejudices), transparency (black-box decisions in high-stakes settings), privacy (training on sensitive data), accountability (who is responsible when AI causes harm), and misuse (deepfakes, autonomous weapons). Sources: artificial_intelligence.txt Interactive mode (type 'quit' to exit) You: What are the latest advances in quantum computing? Assistant: Based on the local knowledge base, quantum computing advances include error correction milestones, increased qubit counts (IBM reached 1,000+ qubits with their Condor processor), and progress on fault-tolerant logical qubits... Sources: quantum_computing.txt You: quit ``` --- ## Error Handling and System Resilience ### API Key Validation Both required API keys (`OPENAI_API_KEY`, `TAVILY_API_KEY`) are validated at startup before any agent runs. Missing keys raise a `ValueError` with a clear message pointing to the `.env` file — the crew never starts in a partially-configured state. ### Tool-Level Resilience | Failure Mode | Handling | |---|---| | Tavily API error / timeout | CrewAI catches the tool error and the Research Agent falls back to local RAG context only | | OpenAI API error (embedding) | Exception is raised and logged; the vector index is not partially populated | | OpenAI API error (generation) | CrewAI surfaces the error; the task fails cleanly rather than silently producing an empty result | | Empty local knowledge base | `build_vectordb()` logs a warning and returns an empty index; `LocalRAGSearchTool` returns `"No relevant local context found."` | | Calculator: unsafe expression | Input is validated against an allowlist (`0-9 + - * / ( ) . %`) before evaluation. Anything outside is rejected, not executed | | SaveReportTool: path traversal | `..`, `/`, and `\` are stripped from the filename before writing, preventing directory traversal | ### Graceful Degradation If Tavily web search fails entirely, the Research Agent produces output from local RAG retrieval alone. Downstream Analyst and Writer agents continue normally, and the final report cites only local sources. The system degrades to a narrower-scope answer rather than failing completely. ### Logging All modules use Python's `logging` module (not `print`). The CLI entry point (`src/main.py`) configures `basicConfig` at startup so every agent's INFO-level activity is timestamped in the console. Tool errors are logged at `WARNING` level with context, making post-run diagnosis straightforward. --- ## Results and Observed Behaviour ### Output Format Every successful pipeline run produces a structured Markdown report at `./outputs/report.md`: ```markdown # [Topic] Report ## Short Answer [A concise 1–2 sentence answer] ## Explanation - Key finding 1 (with source) - Key finding 2 (with source) - Key finding 3 (with source) ## Sources - https://... (web) - artificial_intelligence.txt (local) ``` ### Observed Behaviour Across Queries - **Research Agent** consistently retrieves domain-relevant local chunks alongside web results. When a query maps well to a local file (e.g., "quantum entanglement" → `quantum_computing.txt`), the local context often provides more detailed technical content than a brief web snippet. - **Analyst Agent** correctly surfaces conflicts when web and local sources differ — for example, when a local document contains older statistics and a Tavily result has updated figures. Rather than silently picking one, it includes both with a date qualifier. - **Writer Agent** produces structured, citation-complete Markdown without introducing facts absent from the analysis stage. In all test runs, no new claims appeared in the final report that were not in the Analyst's outline. - The pipeline completes end-to-end in approximately **30–60 seconds** depending on Tavily and OpenAI response latency. The dominant cost is three separate OpenAI chat completions (one per agent), each involving 1–3 tool calls. ### Comparison: Single-Agent vs Multi-Agent | Dimension | Single Agent (demo.py) | Multi-Agent Pipeline | |---|---|---| | Setup | No Tavily key needed | Requires `TAVILY_API_KEY` | | Speed | ~5–10 seconds | ~30–60 seconds | | Web coverage | Local docs only | Web + local docs | | Fact verification | None | Analyst checks numbers | | Source conflict handling | Not supported | Analyst surfaces conflicts | | Output format | Ad-hoc text | Structured Markdown report | | Auditability | Single output | 3 inspectable stage outputs | The single-agent demo is better for quick lookups over the local corpus. The multi-agent pipeline is better when accuracy, source coverage, and verifiability matter. --- ## Limitations 1. **Sequential latency** — Three agent turns plus multiple tool calls means total wall-clock time is longer than a single LLM call. For time-sensitive use cases, parallel retrieval (not sequential) would be faster. 2. **Tavily API dependency** — Live web search requires a Tavily API key and internet access. In offline environments, the system falls back to local RAG only, limiting the breadth of evidence. 3. **No conversational memory** — Each `crew.kickoff()` call is stateless. Follow-up questions that reference a prior answer are not supported without explicit conversation history management. 4. **In-memory knowledge base** — The local vector index is rebuilt from scratch on every run. For larger corpora or production use, a persistent vector database (ChromaDB, FAISS, Pinecone) would eliminate the re-embedding overhead and allow incremental updates. 5. **No reranking** — Retrieval uses first-stage cosine similarity only. A cross-encoder reranker could improve precision for queries where the top-k chunks are not all equally relevant — the cosine search is fast but imprecise near the relevance boundary. 6. **Single output format** — The Writer Agent always produces Markdown. Different output formats (JSON, structured tables, HTML) would require task prompt changes or additional output parsers. --- ## Reproducibility and Setup ### Prerequisites - Python 3.12+ - An OpenAI API key (for chat completions and embeddings) - A Tavily API key (for live web search; free tier available at [tavily.com](https://tavily.com)) ### Environment Variables Create `.env` in the project root: ``` OPENAI_API_KEY=your_openai_key TAVILY_API_KEY=your_tavily_key OPENAI_MODEL=gpt-4o-mini OPENAI_EMBEDDING_MODEL=text-embedding-3-small ``` ### Install ```bash python3.12 -m venv .venv312 source .venv312/bin/activate # Windows: .\.venv312\Scripts\Activate.ps1 pip install -r requirements.txt ``` ### Run ```bash # Full multi-agent pipeline python -m src.main "Your research question here" # Single-agent interactive demo python demo.py ``` ### Docker ```bash docker build -t rag-research-assistant . docker run --env-file .env rag-research-assistant "What is quantum entanglement?" ``` --- ## Conclusion ### What This Project Demonstrates This project demonstrates that **dividing responsibilities across specialised agents is a practical and effective strategy for reducing LLM hallucinations** in research tasks. The key insight is architectural: rather than asking one LLM to retrieve, reason, and write simultaneously, each concern is isolated and handled by an agent constrained to that concern alone. Three design decisions are worth highlighting: **1. The Writer Agent has no retrieval tools.** This is the most important constraint in the system. In many agentic pipelines, the final synthesis step is where the model drifts back to pattern-matching from training data, because nothing prevents it from doing so. By removing all retrieval tools from the Writer, the system enforces a hard boundary: every claim in the final report must trace back to something the Analyst explicitly included in the outline. The pipeline cannot hallucinate at the last step. **2. Context is passed explicitly, not implicitly.** CrewAI's `context=` parameter means each agent receives a clean, explicit version of the prior stage's output — not a growing conversation history that degrades over multiple turns. This keeps each agent focused and makes the data flow auditable. **3. Source conflicts are surfaced, not silenced.** The Analyst Agent is prompted to flag disagreements between sources rather than resolve them quietly. This is a deliberate choice for a research tool: a user who sees "web source says X, local document says Y (2022 data)" can make an informed judgement. A system that silently picks one gives false confidence. ### Key Takeaways - **RAG + multi-agent architecture is a practical combination** for any task requiring accuracy over a private document corpus combined with live web access. The components (embeddings, vector search, tool-calling agents, sequential orchestration) are all production-ready with current open-source libraries. - **CrewAI's sequential process with explicit context handoffs** provides enough structure to build reliable pipelines without the complexity of a hierarchical or parallel agent topology. - **Role constraints are more valuable than capabilities**: the Writer Agent's usefulness comes not from what it *can* do but from what it is *prevented* from doing. - **LLM arithmetic is unreliable; tool-based arithmetic is not.** The `CalculatorTool` pattern (delegate numbers to a sandboxed evaluator, not to the LLM's internal reasoning) generalises to any domain where numeric accuracy matters. ### Extensions Worth Exploring For anyone building on top of this design, the highest-value extensions would be: - **Persistent vector store** (ChromaDB or FAISS) to avoid re-embedding on every run. - **Cross-encoder reranking** after initial cosine retrieval to improve chunk precision. - **Conversational memory** (LangChain `ConversationBufferMemory` or similar) to support follow-up questions. - **Parallel retrieval** (run Tavily and local RAG simultaneously) to cut Research Agent latency roughly in half. - **Streaming output** so users see partial results as each agent completes rather than waiting for the full pipeline. --- ## Licensing This project is released under **CC BY-NC-SA 4.0** — free to use, share, and adapt for non-commercial purposes with attribution. See [LICENSE](https://github.com/samrat-kar/rag-research-assistant/blob/main/LICENSE). Third-party dependencies: CrewAI (MIT), LangChain (MIT), OpenAI SDK (MIT), NumPy (BSD). Use of the OpenAI and Tavily APIs is subject to their respective Terms of Service. --- ## Tags `Multi-Agent AI` `RAG` `CrewAI` `LangChain` `OpenAI` `GPT-4o-mini` `Agentic AI` `Web Search` `Tavily` `Document QA` `Sequential Agents` `Tool Use` `Hallucination Reduction` `Research Assistant` `Vector Database` `Text Embeddings` `Python` `Generative AI` `NLP` `Source Attribution` 55:T445e,![Generated Image March 02, 2026 - 6_36PM.png](Generated%20Image%20March%2002%2C%202026%20-%206_36PM.png) ## Abstract SwiftAudit is a multi-agent security analysis system that combines deterministic scanning tools with LLM-powered reasoning to audit any public GitHub repository. Built on LangGraph, the system uses four specialised agents — Navigator, Researcher, Exploiter, and Auditor — that coordinate through shared state to detect vulnerabilities ranging from SQL injection and hardcoded secrets to broken authentication flows and business logic flaws that pattern-matching tools alone cannot find. Results stream to a React dashboard in real time via Server-Sent Events, typically completing a full audit in under two minutes. --- ## 1. Introduction and Motivation Security auditing is one of the most cognitively demanding tasks in software development. A skilled penetration tester must simultaneously understand code logic, track data flows across files, reason about attacker goals, and produce actionable remediation advice. It is also repetitive at scale — the same classes of vulnerabilities appear in codebase after codebase. This combination makes it a strong candidate for multi-agent AI: decompose the task into specialist roles, run the expensive parts in parallel, and let deterministic tools handle what they are good at while LLM reasoning handles what they cannot. SwiftAudit was built to answer one question: **can a multi-agent system perform a useful security audit of an unfamiliar codebase in under two minutes, producing findings a developer can act on immediately?** The answer, in practice, is yes — with caveats worth discussing honestly. --- ## 2. System Architecture ### 2.1 Orchestration Framework SwiftAudit uses **LangGraph** as its orchestration framework. The pipeline is a compiled `StateGraph` with four agent nodes connected by directed edges and one conditional routing step. ``` Navigator → Researcher → [conditional] → Exploiter → Auditor ↘ (no HIGH/CRITICAL) → Auditor ``` ![Generated Image March 02, 2026 - 6_40PM.png](Generated%20Image%20March%2002%2C%202026%20-%206_40PM.png) LangGraph was chosen over alternatives (CrewAI, AutoGen) for three reasons. First, its explicit graph model makes the data flow easy to reason about and debug. Second, the `TypedDict`-based `ScanState` with `Annotated[List, operator.add]` reducers lets multiple nodes append to shared lists without race conditions. Third, conditional edges allow routing decisions based on runtime data — in SwiftAudit's case, skipping the Exploiter entirely when no high-severity findings justify the LLM cost. ### 2.2 Shared State All four agents communicate through a single `ScanState` TypedDict. Fields are either: - **Set once** — `metadata`, `files`, `overall_risk_score` (plain types, last write wins) - **Accumulated** — `findings`, `agent_logs`, `errors` (declared with `operator.add` so each node appends without overwriting) This design means each node is a pure function that reads what it needs and returns only the fields it updated. Nodes have no shared mutable state outside of `ScanState`. ### 2.3 Real-Time Streaming A custom in-process SSE bus (`core/events.py`) lets any agent thread push events to the browser with ~50ms latency. Each scan ID has its own list of per-connection queues. Pipeline threads call `emit(scan_id, event_type, data)` which is non-blocking and thread-safe. A history buffer of 300 events supports late-joining clients (e.g. page refresh mid-scan). --- ## 3. Agent Design ### 3.1 Navigator Agent **Role:** Repository intake, file selection, parallel content fetching The Navigator fetches the full recursive file tree from the GitHub API, then scores every file on a 0–100 priority scale using the `score_file_priority` LangChain tool. The scoring function is fully deterministic — it awards points for security-relevant filenames (auth, login, config, .env), path keywords (sql, password, token, upload, admin), source code extensions, and IaC files (Dockerfiles, Terraform, Kubernetes manifests). The top-scoring files are fetched in parallel using a `ThreadPoolExecutor` with 6 workers. In sequential form (v9), fetching 15 files took 30–45 seconds. Parallel fetching reduced this to 5–8 seconds — a 6× improvement for a pipeline where every second matters. ![Generated Image March 02, 2026 - 6_52PM.png](Generated%20Image%20March%2002%2C%202026%20-%206_52PM.png) **Key design decision:** Scoring is deterministic rather than LLM-driven. An LLM-based file scorer was prototyped but discarded — it was slower, occasionally made poor choices, and added an LLM call to a phase that doesn't benefit from reasoning. ### 3.2 Researcher Agent **Role:** Tool scanning + LLM analysis, finding normalisation and deduplication The Researcher is the most complex agent. It runs two workstreams concurrently: **Tool workstream** (parallel subprocesses): - **Snyk Code** — SAST, finds injection vulnerabilities, XSS, path traversal, hardcoded secrets in source code - **Trivy** — SCA across 15+ package managers (CVE detection), secrets scanning across all file types, Dockerfile misconfiguration analysis via `--scanners vuln,secret,misconfig` - **HistoryGuard** — a custom entropy scanner that streams `git log -p` and computes Shannon entropy on every string literal in deleted diff lines. Strings with entropy > 4.5 that are not git SHAs, UUIDs, or MD5s are reported as "zombie secrets" — credentials that were committed and then deleted but remain permanently accessible in git history ![Generated Image March 02, 2026 - 6_54PM.png](Generated%20Image%20March%2002%2C%202026%20-%206_54PM.png) **LLM workstream** (parallel thread pool, 4 workers): High-priority files are chunked using Pygments-based token-aware splitting and sent to the LLM with a Chain-of-Density prompt. The prompt explicitly instructs the model to target logic-level vulnerabilities that scanners cannot find: broken authentication flows (missing checks, wrong order), IDOR (accessing other users' resources without validation), business logic flaws, race conditions, and insecure session management. The model is explicitly told *not* to report issues Snyk and Trivy already cover. All findings from both workstreams are normalised into `VulnerabilityFinding` Pydantic models and deduplicated. Deduplication uses a combination of file path, line number range, and category matching — the same vulnerability found by both Snyk and the LLM is merged into a single finding with the tool source preferred. **Key design decision:** Running tool and LLM workstreams concurrently rather than sequentially was the single largest latency improvement. On a 15-file repository, this reduced Researcher time from ~90 seconds to ~45 seconds. ### 3.3 Exploiter Agent **Role:** Attacker simulation for high-severity findings The Exploiter only activates when CRITICAL or HIGH findings exist (enforced by LangGraph's conditional edge). For each qualifying finding it calls `generate_exploit_path`, which prompts the LLM to write a realistic red-team simulation: prerequisites, numbered attack steps with target and result, impact statement, attacker profile (Script Kiddie to Nation-State), and a proof-of-concept. Python PoC code is validated with `ast.parse()` before being included in the output. Syntactically invalid PoC is marked `poc_verified: false` so the UI can warn users clearly. **Key design decision:** The Exploiter was intentionally scoped to CRITICAL and HIGH findings only. Running it on all findings would triple the LLM cost and produce exploit paths for low-severity issues where the attack surface is not interesting enough to warrant detailed simulation. ### 3.4 Auditor Agent **Role:** Deterministic risk scoring, radar calculation, executive summary, report assembly The Auditor calculates the risk score using **pure Python math** with no LLM involvement. Severity weights (CRITICAL=25, HIGH=15, MEDIUM=8, LOW=3, INFO=1) are summed and normalised to 0–100. This deterministic approach was chosen deliberately — an earlier version used an LLM to generate the score, which produced inconsistent results (the same finding set could score 45 on one run and 62 on another). A six-dimension radar maps each finding category to one of: authentication, input validation, secrets management, API security, dependency safety, or configuration. Each dimension starts at 100 and loses points proportional to the severity of findings in that category. The executive summary is the one place in the Auditor where an LLM is used — it is genuinely a writing task where model quality matters. --- ## 4. Tool Integration | Tool | Integration Type | Phase | What It Finds | |---|---|---|---| | `score_file_priority` | Custom LangChain `@tool` | Navigator | Security-relevant files in repo | | Snyk Code CLI | External subprocess | Researcher | Injection, XSS, path traversal, secrets | | Trivy CLI | External subprocess | Researcher | CVEs, secrets, Dockerfile misconfiguration | | HistoryGuard | Custom Python class | Researcher | Zombie secrets in git history | | `analyze_file_for_vulnerabilities` | Custom LangChain `@tool` | Researcher | Logic flaws, broken auth, IDOR | | `generate_exploit_path` | Custom LangChain `@tool` | Exploiter | Attack simulation with PoC code | | `calculate_risk_score` | Custom LangChain `@tool` | Auditor | Risk score and radar dimensions | | `generate_executive_summary` | Custom LangChain `@tool` | Auditor | Professional summary prose | --- ## 5. LLM Reliability: The 12-Provider Fallback Chain A security scanner that silently fails mid-scan because Groq is rate-limited is not useful. SwiftAudit implements a 12-provider fallback chain managed by `utils/llm_client.py`. Every LLM call goes through `call_llm()` which iterates the provider chain in priority order. On any exception — rate limit (429), auth error (401), server error (500), timeout — it logs the failure and immediately retries with the next provider using the identical prompt. The prompt is stateless so no partial results need to be carried. Providers are initialised once at module load. Any provider whose API key is missing or whose client fails to initialise is silently excluded from the chain. The chain is logged at startup so it is always clear which providers are available. Provider priority (fastest/most capable first): 1. Groq — llama-3.1-70b (fastest, generous free tier) 2. Gemini 2.5 Flash 3. GitHub Models — gpt-4.1 4. SambaNova — Llama-4-Maverick 5. Mistral Large 6. Gemini 2.0 Flash (second key) 7. Scaleway — gpt-oss-120b 8. NVIDIA — Nemotron-30B 9. OpenRouter — Nemotron-30B (free tier) 10. Novita — Llama-3.3-70B 11. Fireworks — Llama-405B 12. Cloudflare Workers AI — Llama-3.2-3B (emergency) ![Generated Image March 02, 2026 - 6_59PM.png](Generated%20Image%20March%2002%2C%202026%20-%206_59PM.png) In practice, with Groq + two Gemini keys configured, no scan in development ever fell past provider 3. --- ## 6. Results and Example Findings The following is a representative set of findings from scanning [DSVW](https://github.com/stamparm/DSVW), a deliberately vulnerable Python web application: | Finding | Severity | Source | CVSS | |---|---|---|---| | SQL Injection via unsanitised user input | CRITICAL | Snyk Code | 9.8 | | OS Command Injection via shell=True | CRITICAL | Snyk Code | 10.0 | | Reflected XSS — unescaped user input | HIGH | LLM | 7.4 | | Path Traversal — arbitrary file read | HIGH | Snyk Code | 7.5 | | Werkzeug 0.9.6 — CVE-2023-25577 | HIGH | Trivy | 7.5 | For the SQL injection finding, the Exploiter generated a three-step attack simulation showing exactly how an attacker would use a UNION-based payload to exfiltrate the full user database, with a working Python proof-of-concept and a verified `ast.parse()` result. The full output for this scan is available in [`examples/sample_output.json`](examples/sample_output.json). --- ## 7. Design Decisions and Lessons Learned **Deterministic over LLM where possible.** File scoring, risk calculation, and severity weighting are all pure Python. LLMs were used where reasoning genuinely helps (logic vulnerability detection, exploit simulation, summary writing) and avoided where math or rules are sufficient. This improved consistency and reduced latency. **Parallel everything.** The single biggest performance gain came from parallelising file fetching, scanner execution, and LLM analysis simultaneously rather than sequentially. A 6× improvement in fetching time and a 2× improvement in analysis time came purely from `ThreadPoolExecutor` — no architectural changes required. **SSE over polling.** An earlier version polled the `/status` endpoint every two seconds. Switching to SSE cut perceived latency dramatically — the browser now shows findings the instant they are found rather than on the next poll interval. **The Exploiter routing decision.** Routing the Exploiter conditionally (only when CRITICAL/HIGH findings exist) was important. In clean repositories, skipping the Exploiter saves 20–40 seconds and several LLM calls on findings that don't warrant detailed attack simulation. **LLM false positives are real.** The LLM analysis workstream produces false positives, particularly in well-written code where the model finds theoretical issues that require multiple unlikely conditions to exploit. Tagging every finding with `detection_source` (snyk_code, trivy, llm_only) and displaying this prominently in the UI lets users apply appropriate skepticism to LLM findings versus deterministic tool findings. --- ## 8. Installation and Usage ### Prerequisites - Python 3.10 or higher - Node.js (for Snyk CLI) - Git installed and on PATH ### Step 1 — Install external CLI tools ```bash # Snyk Code (SAST scanner) npm install -g snyk snyk auth # Trivy (SCA + secrets scanner) # macOS: brew install trivy # Linux: curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh # Pre-warm the Trivy CVE database (downloads ~200MB once) trivy image alpine ``` ### Step 2 — Clone and install ```bash git clone https://github.com/10486-JosephMutua/SwiftAudit.git cd SwiftAudit pip install -r requirements.txt ``` ### Step 3 — Configure environment ```bash cp .env.example .env ``` Open `.env` and set your keys. The minimum required configuration is: ```env GROQ_API_KEY=your_groq_api_key # free at console.groq.com GITHUB_TOKEN=your_github_token # raises rate limit to 5000 req/hr SNYK_TOKEN=your_snyk_token # free at app.snyk.io ``` ### Step 4 — Run ```bash python app.py ``` Open [http://localhost:5000](http://localhost:5000) in your browser. ### Usage 1. Paste any public GitHub repository URL into the input field 2. Click **Scan** 3. Watch findings stream in live as each scanner reports 4. Switch to the **Report** tab when complete for the full risk score, radar chart, and executive summary ### Verify your setup ```bash python -c "from core.config import config; config.validate()" trivy --version snyk --version ``` ### License SwiftAudit is released under the **MIT License**. You are free to use, copy, modify, and distribute this software for any purpose, including commercial use, provided the original copyright notice is retained. See the [LICENSE](https://github.com/10486-JosephMutua/SwiftAudit/blob/main/LICENSE) file for full terms. ## 9. Limitations - **Private repositories** are not supported without a GitHub token with appropriate permissions - **Very large repositories** (>500 files) are scanned on a top-15 selection only; deep coverage requires raising `MAX_FILES_TO_ANALYZE` - **LLM findings require human review** — the system explicitly tags these and the UI communicates their AI-assisted nature - **First-run Trivy setup** requires downloading a ~200MB CVE database; subsequent scans use the cached copy --- ## 10. Conclusion SwiftAudit demonstrates that a multi-agent architecture can meaningfully augment traditional security scanning. The LangGraph pipeline coordinates four specialised agents cleanly, the fallback chain makes the system resilient to LLM provider failures, and the parallel execution design keeps the end-to-end runtime practical. The most important lesson from building this system is that multi-agent AI works best when each agent has a genuinely distinct role with a clear boundary — not just a different name. Navigator, Researcher, Exploiter, and Auditor each do something the others cannot, and the coordination overhead of passing state between them is justified by the specialisation. --- ## 11. Repository **GitHub:** [https://github.com/10486-JosephMutua/Swift](https://github.com/10486-JosephMutua/Swift) The repository contains complete source code, setup instructions, a `.env.example` with all configuration options, and a sample scan output in `examples/sample_output.json`. --- ## References - LangGraph Documentation — https://langchain-ai.github.io/langgraph/ - Snyk Code Documentation — https://docs.snyk.io/scan-using-snyk/snyk-code - Trivy Documentation — https://aquasecurity.github.io/trivy/ - OWASP Top 10 (2021) — https://owasp.org/Top10/ - CWE/SANS Top 25 — https://cwe.mitre.org/top25/ - Shannon, C.E. (1948). A Mathematical Theory of Communication. *Bell System Technical Journal* 56:T50fc,![ChatGPT Image Mar 1, 2026, 06_17_01 PM.png](ChatGPT%20Image%20Mar%201%2C%202026%2C%2006_17_01%20PM.png) # Abstract AI can now generate code faster than humans can review it. This creates a dangerous bottleneck where security risks and architectural flaws can hide inside large volumes of machine-generated software. To address this problem, I built the Automaton Auditor (Emerald Suite v2.0) — a multi-agent LangGraph forensic swarm designed to govern code rather than generate it. The system introduces a Digital Courtroom architecture where specialized AI agents analyze repositories, argue opposing interpretations, and synthesize a final verdict based on verifiable evidence. By combining AST-based code analysis, strict Pydantic state contracts, and adversarial multi-agent reasoning, the Emerald Suite transforms manual code review into a scalable forensic service. # Introduction: The Scaling Paradox Modern development has entered the era of “vibe coding.” Developers can describe a system and AI generates thousands of lines of code instantly. The problem is that human review cannot scale at the same speed.This leads to what I call Orchestration Fraud — when a system claims to do one thing but the underlying code tells another story. The Emerald Suite addresses this by shifting the engineer’s role: from writing code → to governing code. My mission was to shift from being a "bricklayer" who writes code to an "architect" who governs it. **1. I built the Emerald Suite as a production-ready solution.** It is a "Glass Box" system. Every decision in our courtroom is explicit, traceable, and anchored in hard evidence rather than guesses. **2. Evaluation: Why a Digital Courtroom?** Traditional AI grading is broken. If you ask an LLM to rate code on a scale of 1 to 10, you get inconsistent "vibe" scores. Instead of a single AI judge, the system creates structured disagreement between agents. The Courtroom Model works better because LLMs are excellent at arguing specific positions. We use this to bridge the "Judicial Gap"—the space between seeing a file exists and judging its actual quality. **The Courtroom Roles:** **The Prosecutor (Pessimistic)**: Philosophy is "Trust No One." Its mission is to find gaps, security flaws, and "Hallucination Liabilities." **The Defense (Optimistic)**: Focuses on the "Spirit of the Law." It identifies engineering intent and creative workarounds visible in the Git history. **The Tech Lead (Realistic)**: The pragmatic anchor. It evaluates code maintainability and whether the system is built to scale. # Methodology: **Architecture:** Hierarchical multi-agent system (“Digital Courtroom”) with Detectives (RepoInvestigator, DocAnalyst, VisionInspector), Judges (Prosecutor, Defense, Tech Lead), and Chief Justice synthesizing final verdicts. Detectives collect structured evidence, Judges analyze it independently, Chief Justice resolves conflicts and produces the audit report. **Tools & Frameworks:** Python, LangGraph for multi-agent orchestration, Pydantic for typed state, AST parsing for code analysis, RAG-lite PDF parsing for reports, sandboxed git clone using tempfile. Installation: ```bash git clone https://github.com/hydropython/forensic-swarm-auditor.git cd forensic-swarm-auditor uv install cp .env.example .env ``` Running the Auditor: Provide a GitHub repo URL and a PDF report. The system outputs a structured audit report (Markdown/PDF) with scores, judge opinions, and remediation steps. ![nn.jpg](nn.jpg) ## Workflow / Architecture Flow Start & Sandbox: The process begins by initializing a forensic sandbox where the repository and related files are isolated for safe analysis. The AgentState Contract maintains typed, structured state throughout the workflow. Dispatcher & Detectives: A dispatcher assigns tasks to multiple forensic detectives in parallel: - Repo Detective: Examines the repository structure and code. - Doc Analyst: Reviews associated documentation. - Vision Inspector: Processes visual evidence or images. - Aggregation: All detective outputs feed into the Clerk Aggregator, which applies min-max logic to evaluate whether evidence is complete or needs further review. - Judicial Review: When evidence meets thresholds, the case moves to the Judicial Courtroom for parallel evaluation by the Prosecutor, Defense, and Tech Lead, each forming independent judgments. - Chief Justice Synthesis: The Chief Justice deterministically synthesizes all inputs, resolves conflicts, and decides the final audit outcome. - Report Generation: The workflow ends with the Report Generator, producing a structured audit report summarizing findings, scores, and recommendations. ## The Automaton Auditor Swarm Architecture This table summarizes the specialized roles, responsibilities, and tools for each agent within the Digital Courtroom (LangGraph State Machine). | Layer | Agent | Role & Responsibility | Primary Tools & Protocols | |-----------|-----------------|-------------------------------------------------------------------------------------|----------------------------------------------------------------| | Detective | Repo Investigator | Code Forensic: Verifies Pydantic state, AST-based graph wiring, and Git history. | ast module, git clone, tempfile (sandboxing), pathlib | | Detective | Doc Analyst | Document Forensic: Cross-references PDF report claims against repository facts. | Docling / PyMuPDF, RAG-lite vector search | | Detective | Vision Inspector | Visual Forensic: Validates that architectural diagrams match implemented logic. | Gemini Pro Vision / GPT-4o, pdf_image_extractor | | Judicial | The Prosecutor | Critical Lens: Scrutinizes evidence for "Vibe Coding" and security flaws. | .with_structured_output(), "Trust No One" prompt | | Judicial | The Defense | Optimistic Lens: Highlights effort, engineering process, and conceptual depth. | .with_structured_output(), "Spirit of the Law" prompt | | Judicial | The Tech Lead | Pragmatic Lens: Evaluates technical debt and architectural soundness. | .with_structured_output(), "Production-Ready" prompt | | Supreme | Chief Justice | Synthesis Engine: Resolves judicial conflict using deterministic rules. | Hardcoded Python logic (Security & Fact Overrides) | :::highlight{title="Important Notes for Running the Auditor "} - Rubric as Constitution – The system strictly follows a single rubric as its governing framework; it can be adapted to any rubric if needed. - Inputs Required – A GitHub repository URL and a PDF report/publication are mandatory for the auditor to run. - Produced – The system generates a structured audit report in Markdown (or PDF), summarizing scores, judge opinions, and remediation instructions. ::: # Experiments --- ::youtube[Title]{#https://www.youtube.com/watch?v=3MjdDmIcL3M&t=1s} --- ## Ouput of the experment: - I put the auditor to work on the current forensic-swarm-auditor.git repository. The system analyzed 51 historical commits and 14 core source files. - Global Verdict: Emerald Tier: The system rendered an Aggregated Score of 4.12 / 5.00. This reflects a highly stable system that successfully passed the "bulk-upload" threshold. - Findings & Judicial Conflict Engineering Chronology (5.0): The REPO agent verified an elite, atomic progression of work across 51 commits. - Security Hygiene (1.2): Critical Breach Detected. The Prosecutor identified a path-injection risk due to raw string concatenation. - Judicial Dialectic: Deep friction was recorded. The Prosecutor argued the security gap was a total failure. The Defense successfully argued that the iteration proved high sovereign state-tracking intent. The Chief Justice used deterministic rules to cap the score at 4.12. ## Dialectic Friction (Trial Transcript) The beauty of the courtroom is that it turns disagreement into data. For the Engineering Chronology and Swarm Resilience criteria, I saw a fascinating clash: - The Prosecutor’s Charge: "The commit trace is undeniable, but the security gap is a fail." The Prosecutor looked at my path management and saw red. It identified raw string concatenations in src/core/graph.py as an "Orchestration Fraud" liability, docking the score by 2.0 points. - The Defense’s Rebuttal: "Iteration proves intent. High state-tracking sovereignty." The Defense fought back by pointing to the 51 verified commits. It argued that a developer who iterates that much isn't being lazy; they are building a "Master-class" chronology, which should outweigh a localized path error. - The Tech Lead’s Ruling: "AST sharding implementation is architecturally sound." The Tech Lead acted as the realistic anchor. It acknowledged the Prosecutor's security fear but confirmed that the Pydantic schema and AST sharding were world-class, providing the final weight to keep the score at an Emerald level.( for more check out the sample report output of the auidtor) ## From Conflict to Remediation This friction is what makes the Remediation Plan so clear. Because the Prosecutor focused so heavily on the "fail" of my path strings, the system produced a specific instruction: “Replace all raw string path concatenations with pathlib.Path objects.” This isn't just a generic suggestion; it’s a fix born from a trial. :::highlight{title="Sample report output of the auidtor "} # Automaton Auditor - Final Audit Report **Generated:** 2026-02-27 14:11:16 **Overall Score:** 2.00 / 5.00 --- ## Executive Summary The evaluation was performed using a hierarchical swarm of specialized agents operating in a digital courtroom paradigm. ### Verdict **DEVELOPING ENGINEER** - Basic implementation with significant gaps. --- ## Criterion Breakdown ### Forensic Accuracy (Codebase) **Score:** 2/5 **Dissent:** All judges largely agreed. ### Forensic Accuracy (Documentation) **Score:** 2/5 **Dissent:** All judges largely agreed. ### Judicial Nuance & Dialectics **Score:** 2/5 **Dissent:** Defense gave high score but evidence shows gaps. ### LangGraph Orchestration Rigor **Score:** 2/5 **Dissent:** All judges largely agreed. --- ## Judicial Opinions Summary ### Forensic Accuracy (Codebase) **Defense:** Score 3/5 _While the Forensic Accuracy (Codebase) criterion is not fully met, I argue that the effort and intent behind the work should be rewarded. The codebase lacks production-grade engineering, but it's clea..._ **Prosecutor:** Score 1/5 _Fundamental failure to meet the rubric criterion. The evidence does not demonstrate production-grade engineering or Pydantic State models in 'src/graph.py' or 'src/state.py'. Additionally, there is no..._ **TechLead:** Score 2/5 _The codebase lacks production-grade engineering and Pydantic State models in 'src/graph.py' or 'src/state.py'. The absence of these models makes it difficult to verify the accuracy of the forensic ana..._ ### Forensic Accuracy (Documentation) **Defense:** Score 3/5 _While the documentation for Forensic Accuracy (Documentation) may not be exhaustive, it demonstrates a good understanding of theoretical concepts such as Dialectical Synthesis and Metacognition. The m..._ **Prosecutor:** Score 2/5 _The Forensic Accuracy (Documentation) criterion is not met due to significant gaps and omissions. The evidence provided does not demonstrate a thorough scan of the PDF for theoretical depth, nor does ..._ **TechLead:** Score 2/5 _The code does not appear to be functional in terms of forensic accuracy. The error message 'Unable to get page count' suggests that the image extraction functionality is broken. Additionally, the lack..._ ### Judicial Nuance & Dialectics **Defense:** Score 4/5 _While the submission does not explicitly demonstrate distinct, conflicting system prompts for the Prosecutor, Defense, and Tech Lead personas, it shows a deep understanding of key concepts in the theo..._ **Prosecutor:** Score 1/5 _The rubric criterion requires distinct, conflicting system prompts for Prosecutor, Defense, and Tech Lead personas. However, the provided evidence does not meet this requirement as there is no mention..._ **TechLead:** Score 2/5 _The code does not meet the requirements for Judicial Nuance & Dialectics. The error in image extraction and lack of poppler installation prevent the system from functioning as intended. Additionally, ..._ ### LangGraph Orchestration Rigor **Defense:** Score 3/5 _Although the LangGraph StateGraph definition is incomplete, I find merit in the effort to explore parallel branches and conditional edges. The absence of fan-out for Judges and Detectives can be mitig..._ **Prosecutor:** Score 1/5 _Fundamental failure to define StateGraph. No parallel branches (fan-out) for Judges and Detectives. No conditional edges handling 'Evidence Missing' or 'Node Failure' scenarios. This is a fundamental ..._ **TechLead:** Score 2/5 _The LangGraph StateGraph definition is incomplete and does not demonstrate the use of parallel branches (fan-out) for Judges and Detectives. Additionally, there are no conditional edges that handle 'E..._ --- ## Remediation Plan 1. [forensic_accuracy_code] Fix security issues: Use tempfile for git clone, add error handling. Implement Pydantic state models. 2. [forensic_accuracy_docs] Verify all claims in PDF match actual code. Remove hallucinations. 3. [judicial_nuance] Create distinct judge personas with separate system prompts. Implement structured JSON output. 4. [langgraph_architecture] Implement parallel execution (fan-out) for detectives and judges. Add synchronization node (fan-in). --- ## Methodology This audit was conducted using a three-layer agent swarm: 1. **Detective Layer**: Specialized forensic agents (RepoInvestigator, DocAnalyst, VisionInspector) collected objective evidence through AST parsing, git history analysis, and document verification. 2. **Judicial Layer**: Three distinct judges analyzed the evidence through different lenses: - **Prosecutor**: Critical assessment looking for violations - **Defense**: Optimistic assessment finding mitigating factors - **TechLead**: Technical assessment of viability 3. **Supreme Court**: The Chief Justice resolved conflicts using deterministic rules: - Security Override: Confirmed security flaws cap scores at 3 - Fact Supremacy: Forensic evidence overrides judicial opinion - Dissent Requirement: All conflicts are documented --- *Report generated by Automaton Auditor v2.0* ::: ## System Maintenance & Support Status Forensic Swarm Auditor: Professional-Grade Maintenance & Support This document outlines the architectural hardening, maintenance protocols, and operational visibility implemented to ensure the long-term success of the Automaton Auditor within an intranet workstation environment. ### 1. System Maintenance & Support Status Current Version: 1.1.0 (Production-Ready) **Support Level**: Active development for FDE Challenge Week 2. **Support Status**: Maintained by Addisu Taye Dadi. The system is designed for high-frequency auditing of internal repositories and project documentation. **Update Protocol**: The system utilizes a decoupled logic layer. To update audit standards or grading weights, users modify config/rubric.json without requiring a full code redeployment. ```js // config/rubric.json - Maintenance Layer { "version": "1.1.0", "criteria": { "C1_STATE_RIGOR": { "weight": 0.4, "description": "Verification of Pydantic models and operator.add reducers." }, "C2_SECURITY": { "weight": 0.6, "description": "Validation of JWT implementation in intranet endpoints." } } } ``` ## 2. Reliability Architecture (Resilience) To ensure "trust and usability," the system implements a persistence layer using a SqliteSaver checkpointer. This allows the graph to "remember" its state, ensuring that if the workstation reboots or the intranet connection drops, the audit can be resumed from the last successful node. Python #### src/graph.py - Persistence Layer ```python from langgraph.checkpoint.sqlite import SqliteSaver import sqlite3 # Physical data persistence for long-running forensic audits conn = sqlite3.connect("audit_checkpoints.db", check_same_thread=False) memory = SqliteSaver(conn) # Compiling with checkpointer satisfies 'Reliability' feedback forensic_app = builder.compile(checkpointer=memory) ``` ## 3. Monitoring & Operational Visibility Every decision made by the Detective Swarm and the Judicial Layer is recorded in a transparent forensic trail. **Audit Logging**: All agent reasoning (Prosecutor, Defense, Tech Lead) is captured in logs/audit_trace.log. **Pre-Flight Health Checks**: An automated node validates local LLM connectivity (GPT-Mini/Ollama) and workstation resources before execution. Python #### src/nodes/health.py - Operational Guardrail ```python def health_check_node(state: AgentState): # Validates GPT-Mini connectivity and workspace permissions response = requests.get(f"{LLM_BASE_URL}/api/tags") if response.status_code == 200: return {"global_verdict": "Environment Healthy"} raise RuntimeError("Infrastructure Check Failed: Check local LLM endpoint.") ``` 4. Optimized Orchestration (Performance) The system maximizes workstation efficiency by utilizing a Sovereign Parallel Flow. Detectives and Judges operate in concurrent fan-out branches, significantly reducing total audit latency. Python #### src/graph.py - Parallel Orchestration ```python builder.add_edge("dispatcher", "repo_detective") builder.add_edge("dispatcher", "docs_detective") builder.add_edge("dispatcher", "vision_detective") builder.add_edge("repo_detective", "aggregator") builder.add_edge("docs_detective", "aggregator") ``` 5. Deployment Configuration The auditor is optimized for isolated intranet environments via containerization: Dockerfile: Packages Python 3.11, Git, and all dependencies for one-click deployment. Volumes: Maps logs/ and audit_checkpoints.db to the host machine to ensure audit history is preserved outside the container lifecycle. # Conclusion This project proves that reproducibility is the price of scale. We have transformed a manual bottleneck into an automated service. By forcing the AI to argue against itself, we eliminated the "agreement trap" and surfaced a critical security flaw I had missed. The Emerald Suite now "thinks about thinking" to ensure code is structurally verified and secure. Market leadership in the AI era will be defined by the integrity of the systems that govern code, not the volume of code produced. --- ## Future Work: The 10x Scale-Up I asked myself: **What happens if this system has to work 10x faster and 10x larger by tomorrow?** Three parts of the foundation will crack first. Our future work focuses on these limits. - From File Dumps to Intelligent Sharding At 10x scale, sending a full repository dump to an agent causes Context Saturation. Precision drops. I will implement Smarter Sharding. This means using AST pre-scanners to send only "relevant code clusters" to specific agents, keeping context windows lean and accuracy high. - From Local Tempfiles to MicroVM Orchestration Cloning 10x more repos concurrently on a local machine creates resource contention and security risks. Our current tempfile strategy is fast but has no resource limits. We will migrate to MicroVM isolation (e.g., Firecracker or gVisor). This provides a "Dedicated Clean Room" for every audit with hard caps on CPU and RAM. - From Multimodal Vision to 2M-Token Gating Complex system diagrams for large architectures can exceed 1M-token windows when combined with full repository maps. I plan to upgrade the VisionInspector to Gemini 2.0 Pro. This will enable a Deep-Gating mechanism, allowing the auditor to analyze 1,000-page technical manuals alongside full AST dumps in a single inference pass.**(Different and optimized use of llm models at diffrent nodes)** - Automated Constitution Updates Currently, the human lead is the bottleneck for updating the audit rubric. We will explore Recursive Governance. Agents will monitor real-world attack patterns and peer-audit results to propose new "Statutes" for the courtroom, ensuring the auditor evolves as fast as the code it governs. ---- 57:T4220,![cover photo.png](cover%20photo.png) # Autonomous Multi-Agent Research Report Generation System ---------------------------------------------------------------------------------------------------- ## 1. Introduction Large Language Models are powerful at generating text, but they struggle with structured reasoning, source grounding, and evidence validation when operating as a single monolithic system. Traditional pipelines often combine planning, retrieval, verification, and synthesis into one opaque process, leading to hallucinations, weak attribution, and limited explainability. This project presents an **Autonomous Multi-Agent Research Report Generation System** built using LangGraph orchestration, ChromaDB-based Retrieval-Augmented Generation (RAG), DuckDuckGo web search, FastAPI for backend services, and Streamlit for interactive UI. The system decomposes research into structured steps executed by specialized agents, ensuring modular reasoning, traceability, and evidence-backed outputs. The system supports multiple LLM providers (OpenAI, Groq, Google Gemini) and generates outputs in Markdown and PDF formats. --- ## 2. Problem Statement Generating high-quality research reports requires: * Structured topic decomposition * Reliable information retrieval * Evidence validation * Logical synthesis * Proper citation and traceability Single-agent systems attempt to solve all of these simultaneously, resulting in: * Hallucinated or unsupported claims * Weak citation grounding * Poor modularity * Low transparency in reasoning This project addresses these limitations through a **multi-agent architecture**, where each agent performs a well-defined role within a coordinated workflow. --- ## 3. System Architecture Overview The system is implemented as a **LangGraph state machine**, where agents operate over a shared structured state and communicate through deterministic transitions. ### Technology Stack | Component | Technology | Purpose | | ------------- | -------------------------------------- | ---------------------- | | Orchestration | LangGraph | State machine workflow | | API | FastAPI | REST API | | Frontend | Streamlit | Interactive UI | | LLM | OpenAI / Groq / Gemini | Language models | | Embeddings | sentence-transformers/all-MiniLM-L6-v2 | Semantic encoding | | Vector DB | ChromaDB | Persistent retrieval | | Search | DuckDuckGo | Web search | | Scraping | BeautifulSoup + requests | Content extraction | | Export | ReportLab | PDF generation | | Output Format | Markdown / PDF | Report formatting | --- ## 4. Multi-Agent Design The system consists of four specialized agents: ### 4.1 Planner Agent Responsible for transforming the input topic into a structured research plan: * Decomposes topic into logical sections * Generates research questions * Produces structured JSON outline --- ### 4.2 Research Agent Builds the knowledge base: * Performs DuckDuckGo search * Extracts webpage content * Chunks text into segments * Generates embeddings * Stores vectors in ChromaDB with metadata --- ### 4.3 Verifier Agent Validates the quality and completeness of retrieved information: * Performs similarity search * Computes coverage score * Evaluates source diversity * Applies trust scoring heuristics * Flags insufficient or low-confidence data --- ### 4.4 Writer Agent Generates the final report: * Retrieves top-k relevant chunks * Synthesizes findings into structured sections * Attaches citations * Outputs Markdown and PDF --- ## 5. Orchestration with LangGraph The system uses a shared state object: ```python class ResearchState(TypedDict): topic: str outline: dict research_complete: bool verified: bool report: str ``` ### Workflow ``` User Topic ↓ Planner Agent ↓ Researcher Agent ↓ Verifier Agent ↓ Writer Agent ↓ Structured Report (MD/PDF) ``` Each agent updates the shared state, enabling controlled transitions between stages. This design ensures: * Clear separation of concerns * Traceable reasoning flow * Modular debugging * Expandability ### Flow Diagram The workflow pipeline is visualized as: ![resercher-graph.png](resercher-graph.png) --- ## 6. Tool Integration The system integrates multiple external tools: ### 6.1. DuckDuckGo Search Tool Provides free web search capability for retrieving research sources. ### 6.2. Web Content Extraction Tool Uses `requests` and `BeautifulSoup` to extract readable text from webpages. ### 6.3. Embedding Model `sentence-transformers/all-MiniLM-L6-v2` generates semantic embeddings for chunked text. ### 6.4. ChromaDB Vector Store Stores embeddings and metadata for similarity-based retrieval. ### 6.5. Markdown Report Formatter Formats structured output into publishable research documentation. ### 6.6. ReportLab PDF Exporter Generates PDF versions of reports. This satisfies the requirement of integrating multiple tools within a coordinated multi-agent system. --- ## 7. Execution Flow 1. User provides a research topic via API or UI. 2. Planner generates a structured outline. 3. The research agent performs a web search and builds a vector knowledge base. 4. Verifier checks coverage and retrieval quality. 5. Writer synthesizes final evidence-backed report. 6. Final report is exported in Markdown and PDF formats. --- ## 8. Screenshots & User Interface The system provides an interactive Streamlit frontend for easy usage, alongside the FastAPI backend. Below are key screenshots demonstrating the user experience and output quality. ### 8.1 Streamlit Frontend – Input Screen - Topic entry field - "Generate Report" button ![src 1.PNG](src%201.PNG) ### 8.2 Final Report Output (Markdown View) - Structured sections with headings - Inline citations - Clean, readable formatting ![src 2.PNG](src%202.PNG) -- ![src 3.PNG](src%203.PNG) -- ![src 4.PNG](src%204.PNG) ### 8.3 PDF Export Preview - Professional layout generated via ReportLab - Preserves citations and formatting ![src 5.PNG](src%205.PNG) These screenshots showcase the end-to-end user journey from topic input to fully cited, exportable research report. --- ## 9. Demo Video A short walkthrough demonstrating: - End-to-end workflow (topic → report) - Agent pipeline execution - Verification step behavior - Final output (Markdown and PDF) Video Link: ::youtube[Autonomous Multi-Agent Research Report Generation System]{#QuRJXQIH4Z8} --- ## 10. Repository Structure ``` . ├── backend/ │ ├── app/ │ │ ├── agents/ # Agent logic │ │ ├── api/ # FastAPI routes │ │ ├── config/ # Settings & env handling │ │ ├── core/ # Shared utilities │ │ ├── data/ │ │ │ ├── chroma/ # ChromaDB persistence │ │ │ └── state/ # JSON state snapshots per report │ │ ├── graph/ # LangGraph workflow definition │ │ ├── schemas/ # Pydantic models │ │ ├── tools/ # Search, loader, embedding tools │ │ ├── outputs/ # ← Generated Markdown + PDF reports go here │ │ └── main.py # FastAPI entry point │ └── tests/ # Tests ├── frontend/ │ └── app.py # Streamlit UI ├── sample-scr/ # Sample screenshots / example outputs ├── .env_example ├── .gitignore ├── LICENSE ├── README.md └── requirements.txt ``` This modular structure reflects the agent-tool separation principle. --- ## 11. Key Design Decisions ### 11.1. Explicit Role Separation Each agent performs one clearly defined responsibility. ### 11.2. Local Embeddings + Vector Store Ensures cost-efficiency and reproducibility. ### 11.3. Free Web Search Integration Avoids API dependency barriers. ### 11.4. State-Based Orchestration LangGraph enables deterministic and extensible workflow control. ### 11.5. Multi-LLM Support Supports OpenAI, Groq, and Google Gemini for flexibility. ### 11.6. API and UI Integration FastAPI for backend services and Streamlit for user-friendly interface. --- ## 12. Performance Evaluation ### Evaluation Setup The system was tested on 10 topics across multiple domains: - Artificial Intelligence - Healthcare - Finance - Climate Science - Education Each topic was processed once using identical system configuration. ### Metrics Definition - Coverage Score = (number of sections with at least one supporting source) / (total planned sections) - Response Time = total time taken to generate final report - Source Count = number of unique sources used per report - Hallucination Proxy = percentage of unsupported claims (manually sampled) ### Results | Metric | Value Range | |------------------|------------------| | Response Time | 8–15 seconds | | Coverage Score | 0.75 – 0.90 | | Sources Used | 4 – 8 | | Hallucination | ~10–15% (sampled) | --- ## 13. Comparison with Baseline Baseline: Single-agent LLM pipeline without verification | Metric | Single-Agent | Multi-Agent System | |------------------|-------------|--------------------| | Avg Latency | ~6 sec | 8–15 sec | | Coverage Score | ~0.55–0.65 | 0.75–0.90 | | Sources Used | 2–3 | 4–8 | | Hallucination | ~30–40% | ~10–15% | | Explainability | Low | High | --- ## 14. Error Handling Mechanism The system incorporates fault tolerance and robustness strategies: * Retry logic for failed API or network calls * Fallback mechanisms for insufficient search results * Verifier-based detection of low coverage scenarios * Graceful degradation allowing partial report generation * Deduplication and filtering of noisy data * Exception handling across agent transitions ### Example Failure Scenario If the Research Agent fails to retrieve sufficient content: - Retry is triggered (based on MAX_RETRIES) - If still insufficient, Verifier flags low coverage - System proceeds with partial report generation - Output is marked with lower confidence --- ## 15. Significance & Real-World Impact This system provides a scalable framework for automated research generation with strong grounding and traceability. ### Key Contributions * Reduces manual research effort * Improves reliability via verification layers * Enables structured knowledge synthesis * Provides a transparent reasoning pipeline ### Applications * Academic research automation * Business intelligence reporting * Market analysis * Technical documentation generation ### Trade-offs - Improved accuracy comes at the cost of increased latency - System complexity is higher compared to single-agent pipelines --- ## 16. Results The system successfully produces: * Structured, multi-section research reports * Citation-backed outputs * Traceable execution flow * Improved factual consistency compared to baseline systems --- ## 17. License & Usage Rights This project is licensed under the **MIT License**. Permissions: * Commercial use * Modification * Distribution * Private use Conditions: * License and copyright notice must be included Limitations: * No liability or warranty provided --- ## 18. Configuration and Tuning ### LLM Priority Order 1. OpenAI 2. Groq 3. Google Gemini Override models: ``` OPENAI_MODEL=gpt-4o-mini GROQ_MODEL=llama-3.1-8b-instant GOOGLE_MODEL=gemini-2.0-flash ``` ### Search & Retrieval | Variable | Default | |----------------------|---------| | MAX_SEARCH_RESULTS | 4 | | MIN_TEXT_LENGTH | 800 | | CHUNK_SIZE | 800 | | CHUNK_OVERLAP | 120 | | TOP_K_EVIDENCE | 5 | ### Verification | Variable | Default | |----------------------|---------| | COVERAGE_THRESHOLD | 0.7 | | MIN_SOURCE_DIVERSITY | 0.3 | | MAX_RETRIES | 1 | ### Storage | Variable | Default | |----------------------|--------------------------------| | CHROMA_PERSIST_DIR | backend/app/data/chroma | | STATE_DIR | backend/app/data/state | | OUTPUT_DIR | backend/app/outputs | | EXPORT_PDF | 1 | ### Performance Tuning - **Optimize for Speed:** Reduce MAX_SEARCH_RESULTS, CHUNK_SIZE, TOP_K_EVIDENCE. - **Optimize for Quality:** Increase MAX_SEARCH_RESULTS, CHUNK_SIZE, TOP_K_EVIDENCE, COVERAGE_THRESHOLD. - **Optimize for Cost:** Use Groq or Google models. ## 19. API Reference **Base URL:** `http://localhost:8000` ### Generate Research Report **POST** `/generate-report` **Request:** ```json { "topic": "Applications of artificial intelligence in healthcare" } ``` **Response:** ```json { "topic": "...", "report": "...", "citations": [], "coverage_score": 0.85, "verified": true, "report_id": "uuid", "outputs": { "markdown": "...", "pdf": "..." }, "research_status": { "planning": "completed", "research": "completed", "verification": "completed", "writing": "completed" } } ``` ### Report History **GET** `/history` Returns list of all reports. ### Retrieve Specific Report **GET** `/history/{name}` Returns markdown content and PDF path. ### Health Check **GET** `/health` ```json { "status": "ok" } ``` ## 20. State Management State snapshots saved at: `backend/app/data/state/` Files: `{report_id}_planner.json` `{report_id}_researcher.json` `{report_id}_verifier.json` `{report_id}_writer.json` ## 21. Report Output Generated reports stored in: `backend/app/outputs/` Formats: - Markdown (.md) - PDF (.pdf) ## 22. Testing Run tests: ```bash pytest backend/tests/ pytest backend/tests/ --cov=backend/app ``` ## 23. Security Considerations - Never commit `.env` - Use HTTPS in production - Implement authentication - Enable rate limiting - Rotate API keys - Log API access - Use secrets manager - Backup state & outputs ## 24. Docker Deployment Dockerfile: ```dockerfile FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY backend ./backend COPY frontend ./frontend EXPOSE 8000 8501 CMD ["sh", "-c", "python -m uvicorn backend.app.main:app --host 0.0.0.0 --port 8000 & python -m streamlit run frontend/app.py --server.port 8501 --server.address 0.0.0.0"] ``` Build and run: ```bash docker build -t research-generator . docker run -p 8000:8000 -p 8501:8501 -e OPENAI_API_KEY=your_key research-generator ``` ## 25. Troubleshooting ### No API Key Ensure at least one provider key is set. ### Port in Use Use different port with `--port`. ### ChromaDB Issues Clear: ```bash rm -rf backend/app/data/chroma ``` ### Frontend Cannot Connect Check: ```bash curl http://localhost:8000/health ``` ## 26. Future Improvements / Roadmap * Iterative verification loops * Source credibility scoring * Parallelized research per section * Web UI interface enhancements * Async search optimization * Credibility weighting algorithms * Streaming responses * Batch reports * Academic DB integration * Agent pipeline builder * Version comparison * Multi-language support ## 27. Conclusion This project demonstrates how a properly designed **multi-agent architecture** can enhance reliability, modularity, and explainability in research report generation. By combining: * LangGraph orchestration * Tool-integrated RAG * Explicit agent role separation * API and UI layers * Multi-LLM support The system moves beyond a simple LLM pipeline and becomes a structured, extensible research automation framework. **GitHub Repository:** [https://github.com/Raghul-S-Coder/Multi-Agent-Research-Evidence-Based-Report-Generator](https://github.com/Raghul-S-Coder/Multi-Agent-Research-Evidence-Based-Report-Generator) **Author:** **Raghul S** GitHub: [https://github.com/Raghul-S-Coder](https://github.com/Raghul-S-Coder) **Version:** 0.1.0 **Last Updated:** February 20263e:["$","div",null,{"className":"page-module-scss-module__kAk0vW__main","children":[["$","aside",null,{"className":"page-module-scss-module__kAk0vW__aside","children":["$","$L3f",null,{"program":"$24:1:props:program"}]}],["$","$L40",null,{"program":"$24:1:props:program"}],["$","$L2e",null,{"className":"Link-module-scss-module__ndiAWW__main breadcrumb Link-module-scss-module__ndiAWW__withIcon","href":"/certifications","onClick":"$undefined","rel":"$undefined","target":"$undefined","title":"$undefined","children":[["$","$L41",null,{"fontSize":"small","className":"Link-module-scss-module__ndiAWW__icon"}],["$","span",null,{"children":"Back to programs"}],"$undefined",false]}],["$","div",null,{"children":[["$","div",null,{"className":"page-module-scss-module__kAk0vW__header","children":[["$","h1",null,{"children":"Mastering AI Agents"}],["$","$L42",null,{"program":"$24:1:props:program"}]]}],["$","div",null,{"className":"page-module-scss-module__kAk0vW__content","children":["$","$L43",null,{"program":"$24:1:props:program","submissions":[{"id":"vRbxc80txBMcymkSyQDzc","title":"IntegrationOs-Agent-Powered API Onboarding","content":"$44","authors":[],"created_at":"2026-08-09T21:13:02.205Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"avatar_21"},"full_name":"Victor Sunday","username":"sunvictor567"},"slug":"integrationos-agent-powered-api-onboarding","hub":{"name":"sunvictor567","handle":"sunvictor567","type":"personal"},"license":"mit","tags":["ai agent","api integraton","developer tool","langchain","multi-agent system","SDK Generation LLM"],"external_datasets":[],"external_code":[{"name":"IntegrationOS","url":"https://github.com/Sunvic567/IntegrationOS"}],"stats":{"reads_count":5,"likes_count":1},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"avatar_21"},"full_name":"Victor Sunday","username":"sunvictor567"},"published_at":"2026-08-09T21:26:13.933Z","first_published_at":"2026-08-09T21:26:13.933Z"},"original_language":null,"translation_info":null,"files":[{"id":"TbrfzRgg1rhrjle14ZdDU","name":"Screenshot_9-8-2026_22213_integrationos.streamlit.app.jpeg","url":"https://app-cdn.readytensor.ai/publications/vRbxc80txBMcymkSyQDzc/files/TbrfzRgg1rhrjle14ZdDU/Screenshot_9-8-2026_22213_integrationos.streamlit.app.jpeg?versionId=vuHvu6tF1CC6ksmjl_Q1umriPCXqreeC&Expires=1788927005&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=t7bWW-Npwu-kGPgRnbeJos6HT3Op56QkF1aCyEe2JKtzdaq7Gaf5a4Ad-u8b4ipOBoTMnxwS5DD2p57rW8AC-w9QyCQkd5pzJAZntynV2a2X0lhRNdW4toeyMlSinACZstf5uTzIoj2QOiZmezLSkQ6Lg9qNVvwt2Qwss40X4Hsu6Zt3T6CNB1mSPN390zgSLltafluw5T0gQo-q~UUmYeDfS78dBztZMxzuFUJ4tpi-ZgzxEcuGloL4jbF3Kmni8d3392wPcKOPiZciVRFDrwxuNPEN8ECCtTfJizX0QaxzAlHM7Sq1nPMgMUf1-1UYmXTt6lTkYBOlfyRejp7PUg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"JkVbJDVEO8IH","title":"Publication Assistant for AI Projects","content":"$45","authors":[],"created_at":"2026-07-05T11:30:14.000Z","archived_at":null,"created_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/OL0mUTtNR5MD1QvyWMKcCrGfd36UBmkw/uploads/avatar-8af6d356-a550-458a-a65b-2b18b2ebd9a3.jpeg?versionId=IzJ8SY1jfYdMX40.6lSLz.214r00.nWz&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ex33y~cF0Lv9xQI7BmaJoCjsRBSUgcUwTZrKa~5VYh~QYR4skpRrs9tkzwHggioPMOpfk7Jajkm14H56Lg6INaSvsrdy~kNRQcrDXBodPpyhMtsvFHk83rZMU-rJXI8MJTZAuJJNLhtKea-THDu1zRovNf6oqSU3i0mgbIcQ-CIgoioOEtMX5bz3nKIqRo3Klzh2bs7h2z-Qx9Q38L0uQttVX7geb7seM4xcsSk6fdQ7EUlBho6ngKWiwuKYKV8ynYF1HJV~0xGZXhtKeGF8pxGUXm2cXrM9AHcdYj7r0WcVuFpHTdHVf-UxbLiHyfSzO-7S9rRCFzsZ-d6MoT95Rg__"},"full_name":"Abdi Dabala","username":"abdi7d"},"slug":"publication-assistant-for-ai-projects","hub":{"name":"abdi7d","handle":"abdi7d","type":"personal"},"license":"mit","tags":["AAIDC","Agentic AI","LangGraph","Multi-Agent Systems"],"external_datasets":[],"external_code":[{"name":"Publication Assistant for AI Projects","url":"https://github.com/abdi7d/Publication-Assistant-for-AI-Projects"}],"stats":{"reads_count":5,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/OL0mUTtNR5MD1QvyWMKcCrGfd36UBmkw/uploads/avatar-8af6d356-a550-458a-a65b-2b18b2ebd9a3.jpeg?versionId=IzJ8SY1jfYdMX40.6lSLz.214r00.nWz&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ex33y~cF0Lv9xQI7BmaJoCjsRBSUgcUwTZrKa~5VYh~QYR4skpRrs9tkzwHggioPMOpfk7Jajkm14H56Lg6INaSvsrdy~kNRQcrDXBodPpyhMtsvFHk83rZMU-rJXI8MJTZAuJJNLhtKea-THDu1zRovNf6oqSU3i0mgbIcQ-CIgoioOEtMX5bz3nKIqRo3Klzh2bs7h2z-Qx9Q38L0uQttVX7geb7seM4xcsSk6fdQ7EUlBho6ngKWiwuKYKV8ynYF1HJV~0xGZXhtKeGF8pxGUXm2cXrM9AHcdYj7r0WcVuFpHTdHVf-UxbLiHyfSzO-7S9rRCFzsZ-d6MoT95Rg__"},"full_name":"Abdi Dabala","username":"abdi7d"},"published_at":"2026-07-05T12:27:33.000Z","first_published_at":"2026-07-05T12:27:33.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"uZGt6QflO055OcP3tW2V3","name":"image.png","url":"https://app-cdn.readytensor.ai/publications/JkVbJDVEO8IH/files/uZGt6QflO055OcP3tW2V3/image.png?versionId=_tfjovrTS2KDaYXGpqGMgXaLuR5SoVHR&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=LB-LYE0sQ3OXG9I29E3S9dwmKqXWwm0YFjMyWSD1kKQN1nUP6Ea8B4I8f~ighpozf7jUEtBrJTF79fR2vSYesqHfmDnqdiaYWVvYUYYZ~MazQV5AHP93sK8GXtKSquQujK51Wfq9cpmN8WqNyu~jrXL3QoTJiQzffvyGufMdR0aLbrYDl7koq5jjTHpNWGwexBFPOUIaWoGQjCzbp759uCAjyNNlLpw9AeutdUuzQ6k985JFemfS7GQL3M0EmObQWMk26dGxZzFt0ykYNCX9mVIMcgEE8PqTJQEJoiuIR7ydRIxy3YmgwIO2tQENRP1Dnt~F1LOYu9j4FwFTpXY5fg__"},{"id":"J3lZLjVzV0GscJAstd23W","name":"Screenshot 4.png","url":"https://app-cdn.readytensor.ai/publications/JkVbJDVEO8IH/files/J3lZLjVzV0GscJAstd23W/Screenshot%204.png?versionId=ZZ8zebagRj4Et8sqNE5L7al3WYZSdm6q&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=I0fFL1eBTMYn4nazZ3uShW0G2BIcj-GBPRTRzISU0DQ~IG-Rg~2fYIw9sjMv5XYxK1BZVPtckMBgiDMBa9wUFOC~9GGprdydmz401Jcn88WqnP3AnR~QeRswzzYqS322FyuUi0~6PsN2W8uPQfqTt5Ya1OTfNW4bxOVIaND3Q5c9miBHNWQ9zdvVeOD39E4HEACtWaiALfZEOwRA0pg4azCA2-N66kSYhNA5zxDou2qoYr3TEZehVdJERqbTP6eMfP84YRK8EmAimQJ7yiV6eiEdCE9Jym348cY6bUNQ9egHY2fUzRjwOqJJQ8PGVcEnXVasgpOaPmrlpvokGFv4Kg__"},{"id":"lrMpJnJDeRbyPP5iV0bWM","name":"Screenshot 5.png","url":"https://app-cdn.readytensor.ai/publications/JkVbJDVEO8IH/files/lrMpJnJDeRbyPP5iV0bWM/Screenshot%205.png?versionId=XNSsP_xFFj1At0hoPwVUgWKWe5ndQ3XB&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=zLcqY1fOUb89tJefJ~aUrUaz8WMxvW-WH9aP9b8apCW5Fij7g2qwS5P-NaKonPjDbBIw6krYPDX7UpW3EWkb5TxyoroOM2rcNXmJS2yU~TObZqnj6islHmPA9oIakLKIBOczia5TbzRwCTs57w8T9BYoYu0tDGq8RA6vEB69kkYaZa22GcguCgqf84sFOqnOcnIGQqj3gtc1VQ0Id3BZg18Rc6CpxA~Yjw33L34vTfoyG3AeyFbrO0ymIqbDDlE7PfbMhRUJSakXpcCp7~GIED35f5ulDqW-g-sf0RKZ~Pb4Zx74mGoywPaXuhevXPAEe8Ni-H1754p9s514DWlb1Q__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"nlxacX6mn8Ta","title":"Publication Assistant for AI Projects: A LangGraph Multi-Agent System for Repository Review","content":"$46","authors":[],"created_at":"2026-07-02T08:36:57.000Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"avatar_7"},"full_name":"Joram kirubi","username":"joramkirubi"},"slug":"publication-assistant-for-ai-projects-a-langgraph-multi-agent-system-for-repository-review","hub":{"name":"joramkirubi","handle":"joramkirubi","type":"personal"},"license":"mit","tags":["AgenticAI","AIAgents","GitHub","Groq","Langraph ","MultiAgentSystems","PublicationAssistant","RAG","RepositoryEvaluation","ToolUse"],"external_datasets":[],"external_code":[{"name":"Publication assistant","url":"https://github.com/joramkirubi/Publication-assistant"}],"stats":{"reads_count":6,"likes_count":1},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"avatar_7"},"full_name":"Joram kirubi","username":"joramkirubi"},"published_at":"2026-07-02T08:53:10.000Z","first_published_at":"2026-07-02T08:53:10.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"1K87Zhs0YiewGjfyix5qn","name":"architecture-diagram (1).svg","url":"https://app-cdn.readytensor.ai/publications/nlxacX6mn8Ta/files/1K87Zhs0YiewGjfyix5qn/architecture-diagram%20(1).svg?versionId=tIdzYON0tnpnrCQdpYfvdykJQxlxcIsc&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=HoKWeqeEsqrtgBKiuJERybqH5Vsh2T8olFhwmjNGXkn4sG61xDJPg6d-YJXyUYdLnRHLLhPoaumafPkLkAkxjUJt9UdMohFRVoIMZcO8p~L-Etk8sCEjhKe~I4pSOl~Qio4B-N3iy90SQTUQjx492gvMlvx2FILSUQbK8w6u-Y~qrtrrNhp5KmsiPzl-uSmeDhiL-pQn2sBzEzf43q2oSFKeZSJ5gltVdzXv9EO5d9c6RU~K~~~dPA~S4TYpzOlHLiBtTklXp79CwuENTOYsnU~aEA3bTM4wb6DSNAUc8wGqWQZTbXrq2-RM5n0pvHOj9KkLH8omOJ7jZjDCIx8iaQ__"},{"id":"WBzyp2k9h2XyT5xAhAffC","name":"hero-image.svg","url":"https://app-cdn.readytensor.ai/publications/nlxacX6mn8Ta/files/WBzyp2k9h2XyT5xAhAffC/hero-image.svg?versionId=Vp37uIGMn9nWKCIN0pGyxyXb6TbhxUOB&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=E7TEBCvEEx8xICBBirK~EiIm-4yld9X3FgcDHCecmgUP3KIDP9Ccoc-iRk4zogX~HaPBsWY9Y5NAyJHJlVbWo6Q~0Tzv5FFev7kxuMAxpRAfHR~eHk~CtnPc-Ji~ST35C70-OxctCtUEwH4iWS4S0Y4kaEEQ~Jl7~MutNDv2jMSz~08z5yPWMZK37Zb06qiXbVWbfeu6hVZ~-nMhmSIw3A3OJXaUAKKSclR10OXcWsNUln6DdTJdqnIr1d8OrOPDxYKV~jOHYjUXtfBXNX0X2KuSTddF8YKnx5Vbxt0EFPR2~0PyHKqWmC6P3dG965Ei-ngBZ8yfzlfyxWkVggqQMQ__"},{"id":"Cn5795NmKzTdWh2xFK1xF","name":"sample-report.md","url":"https://app-cdn.readytensor.ai/publications/nlxacX6mn8Ta/files/Cn5795NmKzTdWh2xFK1xF/sample-report.md?versionId=W6tXyOdN8Aw0UN3dLVA35qbc_8lhX1Ws&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=IhfhOaw3~CKujDGx80gsIBKdhcfWnToYtmtKwWBWlu0Omt48iM2MAgqXpP7HgUCZutSlKEAGrmonnG3J8JVNPqFAvvtD63PJofj7S2ZrGaxBQrY5iXtnhadt09xD67OdDQSFPKjTMNTpWp5yV9e45erkNODBrdfI4rv10hVK~pYjQEAaLunenVCP3HEwkeSo0GMaaYNgtJBBVMG9Djfl5WR0DTOIB8lzmqwrvZP0bwvtf5DMthY7cYEgtGiOUyJ9jXUfhYF4yevK7DlntCe9aA7e~9E9L7MEojeXxplUtaTEyiWYi23bGmZmZOBFDAw68jJEGzb-t8c7t06DY7HIWQ__"},{"id":"yRyAYVEM6PbNFiur6BxCH","name":"readme_quality_report.svg","url":"https://app-cdn.readytensor.ai/publications/nlxacX6mn8Ta/files/yRyAYVEM6PbNFiur6BxCH/readme_quality_report.svg?versionId=Ga5CYmOjrAqXg5BZ93BuLZWviy1tEa6H&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=e~BMx9stUdaX19nbvA0O2yBm4MyTnYWKQatgjYHFWBW2KCyHSbHPpyJlJHRvR4Jx3PbgetK5o5RbORs-XfIc972IYnxrX0qS-JSnjJkhC9Gqn~J6Oa83yzM1ggAzKF5neaSuufwKnZD1qfugw-3396gXECUhnEpAbovzHQjsx7Hl89ma6uLgg~68jpfjR12LPfdY9XVwI5WJJp~gNHlZqRwUTyxu6u3ozocLMItGR5W2BlnjyKDA667HvbSndsIKzO2NAV4o8PigMPauL5-JoUE8sbr46sRSbn0nmwt23W0O8uprRIUbUtoss-HfJAzzlMwzV2aDY4OFd5eXU70GgA__"},{"id":"r2Ve9k0fvBqs1UgPv9o3L","name":"demo-interaction.svg","url":"https://app-cdn.readytensor.ai/publications/nlxacX6mn8Ta/files/r2Ve9k0fvBqs1UgPv9o3L/demo-interaction.svg?versionId=L3OY5iudxEBsZW1KgjItlsgW3.EmcoLz&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=D9HGtFMaEKdww2P8z4-ONQyYMS4G-2lzUiFLLYtqoCaD0pa3e5aLnL07ozjHOdT6dxcHrWnB4pEzfaPujnhVyX8zKoauK8w8d7zcmBDEIYjt3QbGaJ8fOiYQjrYrknYPPoQgy9UpGjnetB6t5aa-MEcbTOzbbJLQNv34hPcK1xEHAjYFjJYQn2s~AW3o095JLA7lvWJgbPp~eXuRFNocy58KoVo3le5ZyC~139F6ZGUU9Wb62WYZszrgAwyLjMCNU1ScvbwMrvAiQvn03Mf8USRXuIiZfHYRW4hfCprwg0fEyAi3Ea4Z68mIBkGtI00634153lK1F~k4UAKbxpGHqA__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"AkB1Ig12GGpn","title":"FinSight — Agentic Financial Analyst over Your Own Documents","content":"$47","authors":[],"created_at":"2026-05-30T17:33:58.000Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"avatar_7"},"full_name":null,"username":"phanminhtai23"},"slug":"finsight-agentic-financial-analyst-over-your-own-documents","hub":{"name":"phanminhtai23","handle":"phanminhtai23","type":"personal"},"license":"mit","tags":["aaidc","contextual-retrieval","data-visualization","document-qa","jwt-auth","langsmith","reciprocal-rank-fusion","server-sent-events"],"external_datasets":[],"external_code":[{"name":"Finsight multi agent","url":"https://github.com/phanminhtai23/finsight-multi-agent"}],"stats":{"reads_count":10,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"avatar_7"},"full_name":null,"username":"phanminhtai23"},"published_at":"2026-05-30T17:43:11.000Z","first_published_at":"2026-05-30T17:43:11.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"O28nq7XjKWbOXlrMy3Vrd","name":"logo.svg","url":"https://app-cdn.readytensor.ai/publications/AkB1Ig12GGpn/files/O28nq7XjKWbOXlrMy3Vrd/logo.svg?versionId=Uckh4izDD1qkifooVvGWcC0joB6aebUk&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=kQZTUFvCqZeIqQ2Qgbp3oIL9MsmXQRbSAyOQYBo9wEo7E4~UxzHsAKcE0Z233m3wI1xIAviXbCAtgXUAO0jiZXx6YF-TTGYTpc36VmIQN348lofGNKvy0Hr~qhtx9IWKn2eZZvTlSxkoXd5da2cWGTaMJtMT8N7aeHGYTj1ptKgd7w0KeKULJ8X-nBMFLwtOyjlTwkJ0YRib6sI4EtC2AwHsmI1FfjK-AhkYwDUYx4tmc1BAc57O6Bv8iqHiAeL4IWtu5CoaIv80Rohp67995F8gVGXTitZdZyOM-KcT-XTl4pnbT70WCJ40wGnzMhOeZh3FIw79Ycmkfwrj6NGKow__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"mA6OAWi63NoY","title":"Multi Agent System - AI Project Improver","content":"$48","authors":[],"created_at":"2026-05-20T09:24:58.000Z","archived_at":null,"created_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/aPxUzU3kUOHMFjRlCSB1lyi2Il1f8AOq/uploads/avatar-1a8cfe5e-43f8-4a7d-a685-5eeec98f8d04.jpeg?versionId=n1wvH7E0AWBa7HovkDDmKPgvJ7uzoyVo&Expires=1788926807&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=BSFoAdDgz8ICI6L5iFgps8-fcTeo0oRcjx4M3ojH5dLqCf0hdcXeEzxgttjfAq-9SiixWte5a1vOOMsF-Awf1dkanb-n6KOxgiJL694IaDKl2~zEJ25FiHKs05eyDIO9PM~jtzH6saAc8oUAEd3---eSpmNBkSXzfqJ0FqX6Tn4T8zMKFszceeI3yKSHDEToibEcsC~dEJJGrOeMObVwA8xprF9zmnB39HKQdtomvrqvrhKcY0hkfZNqOYgjqfFbpFicU2zVGpp7NGwUa7N7-7cN-KHEBKka6QDoRcW7hbVBS8rtaB0DZAIWal~mDWrrbWSx0U25lKtyIILjL7HNVA__"},"full_name":"Sai Rama Reddy","username":"sairamareddykovvuri8"},"slug":"multi-agent-system-ai-project-improver","hub":{"name":"sairamareddykovvuri8","handle":"sairamareddykovvuri8","type":"personal"},"license":"none","tags":["agentic ai","ai","AI Project Improver","multi agent system","tools"],"external_datasets":[],"external_code":[{"name":"Multi agent system","url":"https://github.com/sai-rama-reddy-k9/multi_agent_system"}],"stats":{"reads_count":10,"likes_count":1},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/aPxUzU3kUOHMFjRlCSB1lyi2Il1f8AOq/uploads/avatar-1a8cfe5e-43f8-4a7d-a685-5eeec98f8d04.jpeg?versionId=n1wvH7E0AWBa7HovkDDmKPgvJ7uzoyVo&Expires=1788926807&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=BSFoAdDgz8ICI6L5iFgps8-fcTeo0oRcjx4M3ojH5dLqCf0hdcXeEzxgttjfAq-9SiixWte5a1vOOMsF-Awf1dkanb-n6KOxgiJL694IaDKl2~zEJ25FiHKs05eyDIO9PM~jtzH6saAc8oUAEd3---eSpmNBkSXzfqJ0FqX6Tn4T8zMKFszceeI3yKSHDEToibEcsC~dEJJGrOeMObVwA8xprF9zmnB39HKQdtomvrqvrhKcY0hkfZNqOYgjqfFbpFicU2zVGpp7NGwUa7N7-7cN-KHEBKka6QDoRcW7hbVBS8rtaB0DZAIWal~mDWrrbWSx0U25lKtyIILjL7HNVA__"},"full_name":"Sai Rama Reddy","username":"sairamareddykovvuri8"},"published_at":"2026-05-20T09:33:15.000Z","first_published_at":"2026-05-20T09:33:15.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"BPW0elWgz7xJlGe3270mp","name":"single-vs-mas.png","url":"https://app-cdn.readytensor.ai/publications/mA6OAWi63NoY/files/BPW0elWgz7xJlGe3270mp/single-vs-mas.png?versionId=PTVoCPnTRepauIquaC_n1jPkQ1zaTf12&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=OMvKSb4rDX~Fs20fQaHSEm9PbppLMNzczh7GAFGEGqyjVXrrWxItJ2y7yWlK8M6pUf0~B-7I2QeD14WvrItv7esujl2MPhNysjeStkWBhtJspU7wVCJzGfbuPG7bfDIhzADz0L3auu-Jm8K~mrwBLsc2VJE-oQZzfphkBFOMEUBII19CQVxB~JUfy7kNeBXgc7uoxGRWoGCtq5ApR5lfG07tomcxdeCSHSS64lnezTOwa0U57-BxjSUwnQV~nCSCJiAnqdFVHQSi6V80zNndVGqMbQHWFdqP5gf8CemzM3OivCbmV0utKceXN1A5sxNwDnqlrCNNdHlWKrCAlUQU2w__"},{"id":"8pTZ3NAUq2Ls04ocdMjtP","name":"1_3ja8oBP8ZRwEoC46_kXNAg.png","url":"https://app-cdn.readytensor.ai/publications/mA6OAWi63NoY/files/8pTZ3NAUq2Ls04ocdMjtP/1_3ja8oBP8ZRwEoC46_kXNAg.png?versionId=TP4Rc9CMJh2STRUOs_h9QXBkFAX8vOAl&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=bZNypDw0UC50v1KagoSWTFOzRrnu1WfqU~-9rHpyzFPzdQD~dygofW2nmjPDTJxpNeHbjcPuYOvFpTLD6XF6u47vP3vEwTY3gin4p2oNlAbWit8haJUui2ox9Mi3v9S9CWBDvM8WCoBjG19FgMCZH9CrTAOTF6fUy8RgjiQSKsJcAF40ypwoCr5vQW2H3km9BWPj3EN0tkNenI6PULKm1FWZg3FyBpRqXoWHucbV2U0YkkP1rJ28EBnZeN6THjukdWSvLf2zo9-rPtslO-6JcCqVwcetNnF-Mk2HwBLQkI6JNn9x6H9o4Bj81JFL1cbFQKv3i18Y4Xpv6udJzb1Esg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"2jBsvHEiOhc6","title":"Bus Driver Assistant: Multi-Agent Vision AI System for Road Safety","content":"$49","authors":[],"created_at":"2026-05-13T22:40:09.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Izuchukwu Pascal Nwokike ","username":"user-9055357011"},"slug":"bus-driver-assistant-multi-agent-vision-ai-system-for-road-safety","hub":{"name":"user-9055357011","handle":"user-9055357011","type":"personal"},"license":"mit","tags":["ai-safety","chroma-db","computer-vision","driver-fatigue-detection","eye-tracking","gemini-ai","langgraph","mediapipe","modular-ai","multi-agent-system","passenger-monitoring","public-transport","pyttsx3","real-time-monitoring","road-safety","transportation-ai","voice-assistant","yolov8"],"external_datasets":[],"external_code":[{"name":"Bus driver assistant","url":"https://github.com/pascalizu/bus-driver-assistant"}],"stats":{"reads_count":7,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Izuchukwu Pascal Nwokike ","username":"user-9055357011"},"published_at":"2026-06-05T21:24:11.000Z","first_published_at":"2026-06-05T21:24:11.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"hzBuYp4YWJRhPc4SL8Qxl","name":"banner.png","url":"https://app-cdn.readytensor.ai/publications/2jBsvHEiOhc6/files/hzBuYp4YWJRhPc4SL8Qxl/banner.png?versionId=44loPeSjcfcxzc68VNh8kZo2AGPiwhAI&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=yuh5-Xw7xTwRI-045~~aDKw-CZo4~GCITicPPQc61t2wCQkzg-60wp6Gbx8jCBdVQFSJCh-QZOkGu-izEIxqCFoNz4rQbODfCtIQBOCmLcSQ2VixAlBbXrJY2hLDgFAqIUqbA-4pk68aTpeKnmvm1N34hkNeQbbmt2gqvTyhvSAQXvrdvw341u4jp0NUzYT4lbaF6RpZyGDFynAJZma621KMjULQUBwuppscVKMzmfUh71Ui2eAF9IF7g8kQCYl4nSer52tMEp4ANJMOZHdvEo-g-njGn4gEzf23FIwCUJ3sVUz84w6TpYzVnmJmkAIhXRvZIAPHafkgvhTmTwwmHQ__"},{"id":"Fe0WkPYhYNjXeQgQwBphh","name":"camera_feed.png","url":"https://app-cdn.readytensor.ai/publications/2jBsvHEiOhc6/files/Fe0WkPYhYNjXeQgQwBphh/camera_feed.png?versionId=JYeMkLg5Ztp0Xz6MFT_aYrbR3QVYa4yS&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=nsvrYo4EDdzK0o0K0PTIecg-j5lyAC55sVB4PLOr51zFQ3LrsaOIEEAhn8YsWl0q8YEZkGjZ0ScMz-QyvRuvMLjj3ueCwe2SHqkr185Oe~A-fprIYwB7t-7IbNKjV-LzJP8ZCAVusWaULhdhCzVNq2WscKD8wqgCl4Skb40zPxIx4SwCfgwxC1OXmHiqX8y8VE4codYz7LhNF9G-PV~EhlSiE~zUPznusS3sJzQlGZCZMwVRSVHoeMTBHzDy~2o8siMHoy9OnSqkhrAUz86ccipDqhDdxd2l0-R1Ig5rMzFTlSx~~pcA8qYP93hFN9E453s62mHv4CC7QIPUupFl7A__"},{"id":"j9K5OZZb3RRNnl9kOBKPX","name":"terminal_output.png","url":"https://app-cdn.readytensor.ai/publications/2jBsvHEiOhc6/files/j9K5OZZb3RRNnl9kOBKPX/terminal_output.png?versionId=zNDnIC63vh8W6qNW0jS8Tm507kqMKNxg&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=N3E5Tgzt1ZKwXVpx7XNK3NZy0DPQYWpmwh3XLojHMeZTf8ZuFAB9H2Hcuw3wXCJoDIIw8yUCAXm9BachECFROzTKIn3j3KihTnu5eFsF4onwEaEuOLT6SrXMLmVBQTZ8qpKZXsNDlCJ-itHpJAJXbGFYdOpojxfvFujjAqHBUZAd3kUUat1L6mL6pPGq-nei8T-PHrYNLAIT46JEYiRxUPol8bMbt9YqL5tnK9G6ZfJQKMbJwrBTRwz5f2nFdfB1MbDRFcmQ7DyMpHk13akTCTcreFJryuWjbwwuZ1TDxNjZYVf5gzq4ZsACt-CGVYtIYlqTnjwRJwrNoBFjjsyEGA__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"ymALVZjVuUWB","title":"Touri : AI-Powered Travel Planner","content":"$4a","authors":[],"created_at":"2026-05-01T08:12:36.000Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"avatar_36"},"full_name":"Endale Tegegnework Lemma","username":"endalework90"},"slug":"touri","hub":{"name":"endalework90","handle":"endalework90","type":"personal"},"license":"mit","tags":["Agentic-AI","AI","AI-Agents","API-Integration","Automation","CrewAI","Flight-Search","Generative-AI","Hotel-Booking","Multi-Agent-Systems","streamlit","Travel-Planner","Travel-Tech"],"external_datasets":[],"external_code":[{"name":"Touri","url":"https://github.com/endx-star/Touri"}],"stats":{"reads_count":18,"likes_count":1},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"avatar_36"},"full_name":"Endale Tegegnework Lemma","username":"endalework90"},"published_at":"2026-05-01T10:59:44.000Z","first_published_at":"2026-05-01T10:59:44.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"55l9xIXH5RwbIsluDoWWb","name":"touri video.webm","url":"https://app-cdn.readytensor.ai/publications/ymALVZjVuUWB/files/55l9xIXH5RwbIsluDoWWb/touri%20video.webm?versionId=tBEw0L7.wby1eCkavB.e7EnJedEkvT64&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=laaEh3ygRTTR012qF4Oy4r9y~5zgkHACZ2WQ9stbxlo63QrFgaUZknAR9faN3edKqjysU~iUt7AoJc5ihjEGvECkEqhe4P72jl5Ci5z2z-Or7RqukHH126yKoA0DgspcUiC6LjYApCAluAzhTDQg8bptaH6UObwbj2wIqkc2q4oEmp1sv2~wLtNJ2wk3sKFDtOI9JciaceyY2WrY6P7E5FyWzy69wc3vEADA2-cbP3CPOEJmKnZLGZGNXQh9RcxpebnULaNny1osv9Lfr23fDdnrU1DkZsZCZC6IrPLGpKz4cHKW2AptdNkDIOikTn1GJoOKprCGpCj4opnbcDGCAg__"},{"id":"gnu8RG9WwY68eHbNHHB9y","name":"touri_thumbnaile.png","url":"https://app-cdn.readytensor.ai/publications/ymALVZjVuUWB/files/gnu8RG9WwY68eHbNHHB9y/touri_thumbnaile.png?versionId=kV0.ecHsS5PHviIZqcjvkXtrQ.oFk6uz&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=NM5xNv9ZEu9Mmt3F14a-XOICuq953XdB14RDhoCFoHfr1yrn8~vXqwqx6FPZtJZK6DKqNQP7zG9eDO8qSW~b6LdSnAI1-l4JwcTfwyl~YOIiPyS5I2vaNI-1JmqOEmKe2ELVey3zPNEyIlglpvQoXT7fgNhoKz~3tJN4GapWjrYumX4JkFaOdYEDe9Zf00O12FJmbOGeQilts122xtEACpMrT8l~IU0AEt0Td1sQax39drdWh9gwWKO9xyDCXk3x5jUci92ie5y9FpR9GrrvFjmJKvrs4PxoPETjhtMRpyAjEQNOGBiWUS5oY~ngYzrsDsjP5ngolJrAvLHbdmNeng__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"VdQpWkzqFwyG","title":"Automating Enterprise Procurement with a Multi-Agent AI System","content":"$4b","authors":[],"created_at":"2026-04-28T06:25:46.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Dariusz Sobala","username":"dar.sob.ml"},"slug":"automating-enterprise-procurement-with-a-multi-agent-ai-system","hub":{"name":"dar.sob.ml","handle":"dar.sob.ml","type":"personal"},"license":"none","tags":["automation","Claude","enterprise AI","LangGraph","multi-agent","procurement"],"external_datasets":[],"external_code":[{"name":"Dar_Sob_","url":"https://github.com/dar-sob/procurement-assistant-multi-ag-syst-v0/tree/main"}],"stats":{"reads_count":16,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Dariusz Sobala","username":"dar.sob.ml"},"published_at":"2026-04-28T06:29:28.000Z","first_published_at":"2026-04-28T06:29:28.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"URDesWSHuJQvHZBk6Y8Q3","name":"_psaImage.jpg","url":"https://app-cdn.readytensor.ai/publications/VdQpWkzqFwyG/files/URDesWSHuJQvHZBk6Y8Q3/_psaImage.jpg?versionId=fSLKJU8rGUL0eZVE90Uimps6q0sXxDMx&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=uTJq3KPorrQ6E0dZenkQ1QG3MLFS9ehGbNhtMr5IIU-xuXnzUVQKSZ~YZqaMOvQ3xFuAXNrgti2ItZJQ8EYr4gRlX91H8pl5RNyWL4dGB6RvrO~WDgjpEuD-gjz1LIL09xqaUB98bgZlixiNYiFsjbiAe45re8rChnoiqJTEH7b2ebJXY14loij-EVGBPEFJ1rd6UfjXKSL51HZHj-NjPrDVsXn9ZAibAJY10e0~LsF3v~Lt8KB~TGDDuzK2D17kGPLE~sJbmBJW1fv30hgAsav4d7xc7IV69LRTK05tOKJiAujpsPfvGDJtDcNkAXdXyHWCeqe8LIJaw6LR87vwOg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"znuDMpZcBiV7","title":"Personal Identity OS: Multi-Agent Fact Dossier Builder","content":"$4c","authors":[],"created_at":"2026-04-23T19:58:03.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Egor","username":"zegor88"},"slug":"personal-identity-os-multi-agent-fact-dossier-builder","hub":{"name":"zegor88","handle":"zegor88","type":"personal"},"license":"mit","tags":["ai agents","document processing","fact extraction","human-in-the-loop","knowledge management","langgraph","multi-agent system","python"],"external_datasets":[],"external_code":[{"name":"Personal Identity OS","url":"https://github.com/Zegor88/identity-os"}],"stats":{"reads_count":16,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Egor","username":"zegor88"},"published_at":"2026-04-23T20:24:36.000Z","first_published_at":"2026-04-23T20:24:36.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"tTQuaA5h56PvnaqZP6pIK","name":"ig_0bd4f6fc9fe063f30169ea8054df4c8191a1de707953b0f381.png","url":"https://app-cdn.readytensor.ai/publications/znuDMpZcBiV7/files/tTQuaA5h56PvnaqZP6pIK/ig_0bd4f6fc9fe063f30169ea8054df4c8191a1de707953b0f381.png?versionId=UkZYo1Iiw91G_CdyY5gB0OKzYe0fB8Xq&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=JRLBOWo9SIpcEv1DJiaqsxofb-mjK2ilATe0O3JeuEGS-PTnVe07EFrjVjf-s8zv4Szgu2c6HZY79OLl0ps2bnlX8IX5cilMUUmHYyf~3rTQNHNbUSQI2dfi8RYYS3wFoqRGVE9M35iXy6txIAOqnG0R7Va9lw3xxnyM6f89ooi~XZg3kaj2Xmir43sykAwUqVwNfKsM6ruhwXvV3O4hgaImR8aN9zHTa~NHkbV5LcDmquLL~Gzu~4XbbnhapNeXLQtgt40RQu9uQBklbMBXgWdVLnJauNKLXYAmP0sVSDFfX24KvvKZGS14Ph-b~zzwDw9l81s6a0CqP1rrvoN8lg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"jGInESuBn9H4","title":"LangGraph Multi- Agent Intelligence Orchestration System","content":"$4d","authors":[],"created_at":"2026-04-22T19:00:03.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Princewill Oyebanji Bello","username":"belloprincewill"},"slug":"langgraph-multi-agent-intelligence-orchestration-system","hub":{"name":"belloprincewill","handle":"belloprincewill","type":"personal"},"license":"mit","tags":[],"external_datasets":[],"external_code":[{"name":"LangGraph Multi Agent Intelligence Orchestration System","url":"https://github.com/Electrobello1/LangGraph-Multi-Agent-Intelligence-Orchestration-System"}],"stats":{"reads_count":14,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Princewill Oyebanji Bello","username":"belloprincewill"},"published_at":"2026-05-20T11:31:11.000Z","first_published_at":"2026-05-20T11:31:11.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"bNeNo9wDD0FQv3ZioHrrA","name":"github report 1.png","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/bNeNo9wDD0FQv3ZioHrrA/github%20report%201.png?versionId=UV2TWD4r9hE0KlQVEOOlN_S3GmLmHW.t&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ui5CJsAiE1Yy40hu0vKyFbV62Z4p5bxAebx3RdNbCFGF4282Sn3rV276tNxK7uZ1i3UsNnSzJZdUGSxaWhkux80M5x7qLLt6m2B8h17w~pUy72qKznauIVnXNFAt10mH7QPlsHirhF5cQ3VZjT7F-Tg3Aa76W3r6SoRnYtHDzX~Sd4FxBKxkPgwfTbnQZV9o4LNpyKDz78ad1diJo0NsNBUnii3WnKc5E573WkU96Y0zGXI6~anioFZUKXqqA0-CLkXpZiG28cgtBT-sKoeFReuqnvdsRHr6xcrsRY5G4JcoojWF-JuDXBSZzKzQCLMXX13hUXGOARC7ZBTpsdkL8w__"},{"id":"E1ZLYYE4wOq0lrTvQWjlz","name":"github report2.png","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/E1ZLYYE4wOq0lrTvQWjlz/github%20report2.png?versionId=QjpFEYH6fQ5p_9Xl55_VPshSBPe8j40h&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=QZ4idNVOek1HgbkSeFqlPrtl931MkKJ1ku68gXpMyzVM7BEaiPjBTIgat3G7fRNdGG9v2yQxBljjnREI4gjUOZDHO-Hd5Ki956GUDrOT6A5zNGmulg1BtL2lUtIG74m2UdP7juIcrn8SCWrnEAsRnUM1JKcVnqdzn74Lr9KPjLGZXUwpdTc6PH5AFG9RLB1NzApV7zC-WFNK3AA8B8fazX0p08bUu7CBGva~uzYPN2DcOd~a7Oz-k~NDxyicVgq09PuMwR4aLjyBtCWe-pE-21tKdYc89fIP5vUN6~n2E563uKxCs8gW4a5dqQSxEeOre3WCJ6KPo8LqGPIVtbYLbg__"},{"id":"QvYradmcHdWfv0fNzcM2V","name":"Multi_agent_AI_system.webp","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/QvYradmcHdWfv0fNzcM2V/Multi_agent_AI_system.webp?versionId=PgunLZ.rPyDKkA9NpFmj15omVMjqHXwV&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=wBcunaQy1lMgRFyYwW-tS9iXcrQ3zQsezv03PGTgKiX5rAbclOrg9W5d6BkYrV6eaxd-5AGmxinOukXD1Rms8G2M0JbgJRBVI~HghkLboFWdeIVMJG8Zml2GXupMoEvv7BgVh3tqfjjefiko1ASxOfoMSf1eyV63EFvVoBJilAJvKszxIFdBEchP-Xx7c~345A4sdRVip0TUYRBFe2CT-BD5eq05nJGdCd055C21PCgGbSPHQQ6AHYHDWnMyAOba~N-0dfgQ1DNPQ9wi5u6ChSAENqhUOGh6-mv1oTOqTMRQGm~XKOe5-WAUIngwvzs3sDvl8jjwD29AGxHOIi-zdw__"},{"id":"KfRuT0YEzllNPWcgUVYBp","name":"agents.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/KfRuT0YEzllNPWcgUVYBp/agents.py?versionId=lorsQALvI.zef01MDz.AlMuy9pa2VAxN&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=gc8ERRML4iQ25YFlW6U0cF-SrnbbH80FbNeVghLIZtvZlKRJbHw6zDOUFUbHOXSUbYUZ8scyACJaDDHmyEX3jzh~HzsJBt8FGYlUnIvdhMxiAdp5cREYu0AVnLzr9g~RKzy4lKqH6P-akt3QhkM8~~rkhxLx-htBdWivU~-wMRoabA6K-M0hwEsChtCbLxV9LWsTNs0Y4EyAf4QZl6ij-XeudPqhX9ywcLrdqlrGRBxgJeJYhFDG6N75DkISCv5ISr2GdupXmpYfQ3GwHKRwyz36hA37Pr7FQohAMqWjP~1YheINg1rD~LtCeWhrxM~nrLckhw3cBojqhCjJZ3Neew__"},{"id":"mpoedF3NBipRDKKrNcPRw","name":"graph.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/mpoedF3NBipRDKKrNcPRw/graph.py?versionId=dXrf7MP4ri47XmMeZIdw5_vLSRtTJask&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=tswKFXIZRkNJTtYTtTonZVjtLJUnMUB6VMbYDNuVB-3RGGgq9~QoQfBPNLq8iu0m737KvDpfogiJt-QQuSgwkrXs~4bVOqCtYNFBGbCwHLOzKaxqUt4jsEqThvHG40H12fNgUjcRuvKysmAIsW5BwnK221FBeAqE8GgFnlQ13S8cy5K9JO9xbaQyf5H9Ck6p243iU3hd4mNAh6uI-csBjXKKK060RtN9kZ3h85ptUWG3xY9lNNQspmqrnwP-mlaaR95-QgTofgvFdhFZLN5FuXfToPdblOCc0s3A9YY8Bzpkg9m4FTOYT9AV9bk5aigAQKTN16gLPHwnaFaV~PFtqQ__"},{"id":"1qze6iqiWunAuteh1ghOM","name":"Tools.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/1qze6iqiWunAuteh1ghOM/Tools.py?versionId=5zt1jIO4pAbG6uOtqYukQuT7OFCthWVb&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=zFB4QhqVhgoy5LJb8dV7Mq95j-Zk~sAhBDPFGtGWUY9e-8MIYXhbXngHqK7CGqg05nYXAovMmpe7rn2j-IR0j1kO-U-xrasvS2zDt3BevOQ5d9x0LyZ0LYF8tk6k6NIcPdrgf3V6SJS8lChSqHNt0NSrOsMmHrO9IJS8ZQ56EKnQBjO3V5xf32EwQ3g7d4IsWsQKyvr2OmyiiRd60daFgo1OEssiioY68JpC3Rz9W58DBwV3OLJ~rV8LLxsULhFSVrpsceRvBbugBl3ZBiHJF9fka~Jx0W7KpIGQ3kbM3U11ISjOfkcWC4U-JzRCCQR3062UeEzdi~5T892c0n6jkQ__"},{"id":"nGNxl0lVU43FDm4SLwJQ4","name":"state.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/nGNxl0lVU43FDm4SLwJQ4/state.py?versionId=XBTuDtjRMhAaMZNrXnEz.Ewp02a4yl2o&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=fu6a0MQUqTIWEFXTBVkg7zkhwKFTbjUh4mvTxlOvLhGFH-uhlsgDmmbPtC0WRBXsxdGnK7Erh1GVE2yq9yKlBkooW0xTc2cixy4-JwbPCLOO8r82RjIgPAcrHouY4ZQsjCWIMN5qTksbvPLG4sHNSRSByAU7I1SPVqKjSb7Yj9lyh8G5~CP1eu7RyEYMtoc6JUTWioxCP01mulm~jjiYmedkYVhLZGWCwF4adaM8fwa1p7MphXL7rfYh6lwXPtPG2~zr~SzIPl5OW8wrSBmok8BjYbsVsxrGCxo0HIE4QxJUOBlCNdZaERsTmA7YW1fF8575wamtGZiBYogqoJIMAg__"},{"id":"rmyD7V4KU1ZcvPYOON6gf","name":"main.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/rmyD7V4KU1ZcvPYOON6gf/main.py?versionId=HQUTRQBohBWubY9abNL_xoCUf2aQk7Ad&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=qhPJ5IX7ryHwSCkSaUBAu8HBeCscyN6Qld8O3D9ehr~b6qolSmQ0s5drM6DkUi22JPc9boq981ykYtXCiy5iQpnQzn0G1i8deTpbkYPabIQKKi1WXe6wJF0YLz49X3-uxNpj0Vwdriqql4G1s~nJlPE8i3jQFN51G4QsunNWxXl6UyGx2odLFIIzYoDFBRg8LppGVVKwzaXxkjv47tFrfYqZcFzOBFab0s5sJfuBa73Yn1I0mj0aMjYIfig6hFkqb1f8SE91jocYF3IhLSitxWbkWYnvYkjYjX1yyqVx3aq6o0gohceqH3Z51lb5153gScTxjNBob4ymI9i5cpW8AA__"},{"id":"iEzE13XyxnSQGNEgi7jvE","name":"requirements.txt","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/iEzE13XyxnSQGNEgi7jvE/requirements.txt?versionId=NItz9SW7rUD_sOxKfXzHXBl_hwCsEb0d&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=G3oOJp6KL2A8JV94Q9jKMzIttI0Klop0svCdxcrofeRRTBU~9LIQYAgcAbCtvqLfkx-YcPjM71CiKOIbvBVpx1SHEoo6eR4qDHE1HEngoR4bihLRk0OWk-qJQikY1lo9H0dthmNt~yrO0m3cT8eApSFe8hqWwpnpMPPRh9nvRtuEJBYntr-M3-KT2kwlavF76sN40ccQlziqOSKnr8~yLXCKNIA5uhFJmQIsr2121UDzuGCm9nB0RwxR3ccbYMlnP8qatBrHzxAuLFdk9Jx8sjLHiwcJ6ocV16sERlLnyO2TLUGEMA3iSfHfYVVICg4ttJSUFcRTZPlhtBvXugmtyg__"},{"id":"kmr586iODpIzEaQZeJg0f","name":"__init__.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/kmr586iODpIzEaQZeJg0f/__init__.py?versionId=c9cNtxYDqLvfzZ5QQ8B2gqaLiXO_CCVg&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=olWryM~L~AuCJ9ve~pKOZjL~YSFnag~kKT4YCxUbOYELiAT3PvNUhPL~I7rwOsk5KTHH2qKOK~DDVi1vO1OyamdqpPQfs~vdLP-NiW5dQHtzMaD-4R~Cu2BBlejtfYf0m7GqU2v7ZVFvSIyChRglqbkLq0hvIUONZpbwdMJxM5sONcixva-fjVS2E1MWKnkwGkJynDlk9mcfMsWRqB03BM7j40--jPrZzCcBHW9Vliios7Q6fl0pvHXCaZhQEVrZIdfu5JrPB2FCaKmESPRhLCDE5yLbZeamhnH4JNRBFnnqw0KmVJRFi3~5-iU8521f85cQo6wXKFAkHuuRFjgf4g__"},{"id":"AjvgYHBBKxtKpQlNgZdnL","name":"model.py","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/AjvgYHBBKxtKpQlNgZdnL/model.py?versionId=xiZs9_kYKo5N49Aw0vPALaXp876kT4_V&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=uJLgmanejroDlqlbnFD~YLv~GHhCsC7bBDIU1a9HI7yoM9~y92Gz3dMGUWX-hsJKChuErHYXXFSOuuTSKHdN5PGkAiifbECI09u4lb7R2TAOf4KmHQpMPLT53BI8xIFjEjC~ISWJs1Syo71~PDO2OWjp~v3xIexKydwwdqfHoInYY4gSpVEBOlQRr3tzvKoNz-4xgunDwfZPKYjVFC4U0SpkLFCHpViiaqEVEXwfMlgJwA4IZNIEK9khq-e~hEXHA7o5EaktTk3kBPJy6oqdi~Vd7BkWl0-KfBHHAn99ycaJHbDRMwCdwgWanNzFZXhGaCRMIKTJ47R0mbpTtS9nvw__"},{"id":"DxCwUkg9Ug87LFRpXn21M","name":"README.md","url":"https://app-cdn.readytensor.ai/publications/jGInESuBn9H4/files/DxCwUkg9Ug87LFRpXn21M/README.md?versionId=IJVxgaF1og1F.feG1DqSj_rFAnhqorXz&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=jeJYi5KKfti0AZx30uczLQgGDTgIktIDtys~YPkW7ZdVpygX594flIZ2fWGczfoAlNzjfZxbX9vm-Vn~FT57hJS2tZcPz4CaIoZy8atwvvRe0ZnWIFw97pHRO~bY1aCNDzbyH4dIoovyv6GTixydfXtX0ZyhHh3a1oGlT-SiCJa-ThJuBexZmwYFxg68kDp5INF337VIPuhysRpNYPOhM2DqM18ZHWr5xKB43ymOEDVKjzdTf3EuA2V~ojp7ZUAe~p2goPndB7ZuQoEd5rWnLtAb95ZPhYS17XDzJ~BBj6LTsm8liADfbuRcVQUyakB8q6s-JjH3uRzDP9t2wREqZg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"Npznjpz7AmfI","title":"🫀CardioSentinel MAS ","content":"$4e","authors":[],"created_at":"2026-04-21T12:46:46.000Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"avatar_39"},"full_name":"Ana Boset Wakeyo","username":"anawakeyo"},"slug":"cardiosentinel-mas-multi-agent-clinical-reasoning-system","hub":{"name":"anawakeyo","handle":"anawakeyo","type":"personal"},"license":"mit","tags":["# AI","# AmericanHeartAssociation","# Cardiovascular","# CV Pharmacotherapy","#EuropeanSocietyofCardiology","# HealthCare","# Medical AI","# RAG","# Treatment","#WorldHealthOrganization"],"external_datasets":[],"external_code":[{"name":"Cvd multi agent system","url":"https://github.com/anaboset/cvd-multi-agent-system"}],"stats":{"reads_count":16,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"avatar_39"},"full_name":"Ana Boset Wakeyo","username":"anawakeyo"},"published_at":"2026-04-21T16:06:58.000Z","first_published_at":"2026-04-21T16:06:58.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"6hj3Z35StKBYM6FkdxpP6","name":"multi_agent_system.zip","url":"https://app-cdn.readytensor.ai/publications/Npznjpz7AmfI/files/6hj3Z35StKBYM6FkdxpP6/multi_agent_system.zip?versionId=HtLrPzVdGaKi2mH99wmANxydvNp4OVZi&Expires=1788926983&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=L~R1TJP9WiY2YFNjFL0htILBFOJufVXyxqYJA27BPDWoY-mxfzLZx1YgkmQ05k94C9EYz-AUNwfJEfPGy3GVDdNYnkTxIkeYM7NfI3anbQtyorge09-ZBiODLVJfDndUc3BgrvBzgyrqtnOBBHgFGR3HG-tOfq2u5ZRIOrUkskjKv3cG8~RfkfxbKtTtC38~bgTcaV45KlmQcm0orM4xvKh77bOmbDO0H3OM1yj0GBo3~zxJHW1Vcb3DOklOXEIaiG4x2A8a7vBuHeAJTmU8FITqXdOSYSUBrdK6UeDrTJ0GpZ7-8XQavGftpEYcGxfs3PzjHwfCWQssN5pQ2bmCMg__"},{"id":"Cq6z1kWuYOBIspJ2sUhBw","name":"Gemini_Generated_Image_ru2eifru2eifru2e.png","url":"https://app-cdn.readytensor.ai/publications/Npznjpz7AmfI/files/Cq6z1kWuYOBIspJ2sUhBw/Gemini_Generated_Image_ru2eifru2eifru2e.png?versionId=ZtlJ4UandWpIV6EJ6bHgafN_cBPchGSx&Expires=1788926983&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=E4yEymZCTZuUJT7AdNxfN1O2WtiWHWQPGK5Qg0oweQmRANHZD8J6JC48trcaL7agmq31YIOUTS5xHj8rtToZvdhXr9wgIvoQitLJPj7Du2RAa~dKXUNbCdUl-cU9KB9ULBQdWnbQNd-suOzF7xqfDvTTcFWGjdCRyIPrGkj12-UlXwem4v~yJ92~JdUsn9yaPNLjx8OD9GDLje~U7jHVc0rPDRSRz3g01DeyLQwhNHv1StZMlu4ip4HCE~6JDBxyw-1n2~En9FH7XsprEpvpELyqnrt4Ml-RGUQNbc-Nff6SXQ~dEhfaC-Z7zFl0-4u~qEtwKowyJsJBv-o0voc6dg__"},{"id":"HBzeAifIVmKSwb6kKd3VI","name":"cardiosentinel_mas.gif","url":"https://app-cdn.readytensor.ai/publications/Npznjpz7AmfI/files/HBzeAifIVmKSwb6kKd3VI/cardiosentinel_mas.gif?versionId=7gPzDdTqq4.7Bxfy.eiY9H7lkP79lWZb&Expires=1788926983&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=PHZ56c5x1gPr6fCDY9xsj4XpgrDQ51rEPBNukdNLSXDyHEAdFdDPpfUNsGH7VQ37Ay6g8DOkt9famI-VWnaHILACL-VRJFPtnTvU2gkjgheyyqQi1xT9UxFpOVby-SK71MdKHik11LU4Ibd1aUcV4GuhBlujE3OS7YVgcIellSqQXFRr4VqJyaReP80ghfZvKq3SgF-7gvX9uZKW1-9yMPrhqnR5hbfXdTXC8KCkatbXiK-Zgf-e3q6YHjoYpmCdD-5V57thjyM3nymkb2zysTnshsMMlN-GOhIPxrr3cw1UdohBUYYLF5JYICD9rnK39o0XSvhvRcV-6iilr5SIog__"},{"id":"DQBS31hgHC0aVdAoQ7WaZ","name":"cardiosentinel_mas.png","url":"https://app-cdn.readytensor.ai/publications/Npznjpz7AmfI/files/DQBS31hgHC0aVdAoQ7WaZ/cardiosentinel_mas.png?versionId=3SRslkL9TiB9cWs7rVwwACeCj_nlAeQe&Expires=1788926983&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=hH3amcAcbkpDHa~SGKp0isMo9plI~~yoQQXqsHTGcKhUwVO61u8gt9yfBATuKGqnYUODW381TWCxZAZhhJSyxM0fOyXo-3YAVos5KQINejtLYYSGQpYqVcvYG9bZOAsSkIdrOsSSLdWjCwo8SdyDJ-m4GJ4v90jy00GuI0yGYhkvDdwLiJzHifCtqXZ~bzwNHYn12Y8fsRTGAO0BsHe6WcO5lPXLvU6dvSJmPYQsxqmv1tieAOM~6nFgdjgW-VfcMf9GgtM49aS5ixVQIdoFZLFXjAc1zyZ3n46-OrX4oEmVr46tghnz3ajiZYD9dDnoKzs3h-bGZqOljPwvYqp5Gg__"},{"id":"raCRnUQTua0VSXQ2ZiV1t","name":"cardiosentinel_hitl.png","url":"https://app-cdn.readytensor.ai/publications/Npznjpz7AmfI/files/raCRnUQTua0VSXQ2ZiV1t/cardiosentinel_hitl.png?versionId=y6mxgfJXfeBYmJIM2Izl3JEs._6ZRh1R&Expires=1788926983&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=LZF650w7XBmzDI~AhwemSkNMGm9NsIQWaUMRhvMqPe4gBsKEHrAk3~clGxv5NPx69~63N3zdLZWEyAp8MUf0dTHWjdZsUPRh9rB-s~S0IG0v7~PKa1Miv5H-p8zikHB5nZz2mQ05HwTIjgzDcC3SRatll7Y7W1rV6argaDe-NjmEJZr5ZgXB2FEvVWJT9Gve217AhZaBVuqP693UJHAehl-L84LQhLnWCpgE-rZ1rV0byeaU-ahvlbdh3lnuPzWVriBOIdcmzWsb1qf2RrmpXvwOTb0juF4p70MGZjzoDurRRVsO9ezMD23qLfaDOqXPqmdFJ088~0d7zsTIh6JGJA__"},{"id":"MAWO78344jxardMCr7UDn","name":"cardiosentinel_mas2.png","url":"https://app-cdn.readytensor.ai/publications/Npznjpz7AmfI/files/MAWO78344jxardMCr7UDn/cardiosentinel_mas2.png?versionId=q51O4wg26DAR8rpwplUDqo._.qUcv.fa&Expires=1788926983&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=MUwSMlT4eTXnpNKFftXa7LusF0k68RuqTkVHdURe300vwrUow9xMLARn2gRwO3VFh9Hol7O9wJptoG54z~lk03uKxe9HdtFdIsj8g~MJZ2vRx1AnTfyHTSofuNiBbPNeaJcmt1UHapREc6g2XqkaVfPiEQ5O~WEV6c-BVGirEK2QVTO6c4qnys7l5NHuwfZMAlF6FhfRi9Kfhxsg08~S21WE9GWGFez9fZ8G4d62BzUTR4df3YtK05~1w9~rR0bx1CaQCK142ZQlfHFnzpilEqsNYCWLOof3E5AczJeVOq~hfYMC52mONtWR4scDdo3a3gQmOj6mxHigAHGMwj99ww__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"qyIbhHOoENPT","title":"ResumeLens: An Agentic AI System for Resume Analysis, Job Matching, and ATS Optimization","content":"$4f","authors":[],"created_at":"2026-04-03T07:24:11.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"VICTOR SIMBARASHE MUNATSI","username":"vsmunatsi"},"slug":"resumelens-an-agentic-ai-system-for-resume-analysis-job-matching-and-ats-optimization","hub":{"name":"vsmunatsi","handle":"vsmunatsi","type":"personal"},"license":"mit","tags":["Agentic AI","AI Backend","Artificial Intelligence","ATS Optimization","FastAPI","Information Extraction","LangGraph","LLM Applications","Machine Learning","PostgreSQL","Resume Analysis","Streamlit"],"external_datasets":[],"external_code":[{"name":"resume-lens","url":"https://github.com/SimbaMunatsi/resume-lens"}],"stats":{"reads_count":16,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"VICTOR SIMBARASHE MUNATSI","username":"vsmunatsi"},"published_at":"2026-04-03T11:37:03.000Z","first_published_at":"2026-04-03T11:37:03.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"fcPHn3oJfuh2mh2X77KEL","name":"resume-lens flow.png","url":"https://app-cdn.readytensor.ai/publications/qyIbhHOoENPT/files/fcPHn3oJfuh2mh2X77KEL/resume-lens%20flow.png?versionId=QF_pFSQe2OjgyRLqn3MdKCzABuhJRwlx&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=FVdp5oqZg~N~OhDzM21Shx~7Kg3JQUs0rMcG1uN7Kup0Ojeqn3xfFBMmMWaK~A9oC6tF02z9F1laPYcQBXdo15kHmKc8L~filFTXcc8xHik8aIfK1Wf~dtZzApZE3DPvSoQjimUthBn2~W5BtgsaEF4XRGBOwUaJOPLVeQXsnz9RgzE7VFIULADSGx2NjnP~JmZyU8nPx~legK9xQLRRrYD4uZAxK2ZdQuwuhbkJrOU~XykY~NF80w6p2XSKRThZp3MG6M~jLSGAFcBBPQDiqOf~nS-ps5Tsp5C8D~rVI4WXLj57dNuDEDG0Yxhv5mJImoIQKyrjlJ-uoLu3aSRnRQ__"},{"id":"w6smLYBsTRk6H7QqxFr2M","name":"ResumeLens.png","url":"https://app-cdn.readytensor.ai/publications/qyIbhHOoENPT/files/w6smLYBsTRk6H7QqxFr2M/ResumeLens.png?versionId=9ZWpHIjMUEZXmPGWYRnEw5ZGNTw9PzKo&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=zj8lXHsuqaeiaLIKJzTesXniY9KrKv5suENb7zONvsp5dek8IbrlbeP~EpBcyXAkkfh3mfQvZQK5xahkgBrJ3KMWoTSgKdrQjLTAvVvWRxAeXUpXktUMnAmuH8WIzn6QYRkQNhnRO9f5dnmOBITeHTA1OvptkcmdkCWVVl5X~iBEuo6emnxOlE-59MztsmeTa6onw8sm-nh-~WCQZr~JkD6Qe-N~-cJEPG0Jnrro7l7m-gHDgE6wMgB2SRW3MxPDAM~~9yC0FbUvrin8feUT6tJlPMcyU3Nj6vIGTgXFDEnlNFe8E~QHBrm4VkYCPyckUZDzjF6zvhlNqvhMbBVpGw__"},{"id":"EXPbRKpUiMyW3GN4rWnyU","name":"tests.PNG","url":"https://app-cdn.readytensor.ai/publications/qyIbhHOoENPT/files/EXPbRKpUiMyW3GN4rWnyU/tests.PNG?versionId=iaUI6TRs_ax3kLO9yS7AgxS_Q46p6DOj&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=EeCsQWgkr2LKBml56PYeW6EkImWhC147A9wmCQ9OQG0s~5uhJp~dA3DDVHcisos44uygGMVfg4xuFltelwaJNN24tqEqGe2FIv45At7dQgryDArTQwjwnp8nGhKM2K0OEubUXEby~wrPlGljf~PKPq2p-aHIzYL3GBvpvJvmw4L-RQwPnK~VaZJP~vy~dt57aVaD23CNTPrJbbHIuyGgHVri7ewl3dT3HREYXuY8p9TxxsLECbgFWZFXMYRdB51gIdgRAKfRgmjgG4hEGj9QGhnYQjdvMuXwgD7x4Dnju~12Vd~jkTjJdf5~ZBsBgJrWT3Q89fcJqN5rI~GXbd-D~Q__"},{"id":"01j0ZWGQXfIHk6AGJxRZG","name":"profile.PNG","url":"https://app-cdn.readytensor.ai/publications/qyIbhHOoENPT/files/01j0ZWGQXfIHk6AGJxRZG/profile.PNG?versionId=0f2c6Y_pYS7cIccCyj5S.uy3KeHrkLQJ&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=L0W-Q4XY6pYUCMxtd6AA~QO-x1fyh9qNTf7a22RZGhcxBZef6Lkxyfcd4XYANXTDVNJF9BJ9gtGBuNMaJvCEHmjGZkBNxY7VjZOo2bcTPSel6LYmYS7WXtLcijn8bPC3k3US28x-KbgjlM~53dg5OQ77cNKx7dD-SmSpUMqVU6GnX7fsgWQ8IvHyEeQ4G~b3YmPaSVxcZFRQy7~Rh11kaXugjzOnlUDr8T8FuJbgJFHsSeDiNrE4nWgsXlrqu4MAywvG76~~XCpUBApebBIOeBaKQGFdv17bIpa9nDE~aD5oLPWC6ZtAR2e5~KFHW1N99jH1IbGiU6Wp5szcJ0zbYw__"},{"id":"PUeMROXwV7hRLQSn9ToPj","name":"gap_analysis.PNG","url":"https://app-cdn.readytensor.ai/publications/qyIbhHOoENPT/files/PUeMROXwV7hRLQSn9ToPj/gap_analysis.PNG?versionId=WLKXB2QllGV3ZMrsugStIvaV4eri2LAk&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=l5fLtDZSuP2-vOiTtCgC11aMj6sDw39yxG-lAlH9Ccnxg4rFhkMrmAo5luT7dSZ-VOoMrd5yWt8npbpAWxSD1jZk9PxHTpcqW0kgU-3WVEctf3mUbmdiXwUIwAJe190jlalQB9xCeIHUgjdNgXuOScs0IqIUkSRmFSkuXduNnAV2Z9W3jXbCb9F33PeBheXuLEAWHRhZAAFnB7lH1n8L7fS~iABXH0xt6MvdT9g5BBVqkq-z~x1Js4x9GJP80o0I4deWYQlbL1e-GxOU8R~KeTS3j2WumyCLX-kaMnmrSN4ruCin9JskoGDDJGuzmqwdmlSX6eSqzJC4cdrK9JJewA__"},{"id":"48sTP6FoCn2bpduUGVdWr","name":"improvement.PNG","url":"https://app-cdn.readytensor.ai/publications/qyIbhHOoENPT/files/48sTP6FoCn2bpduUGVdWr/improvement.PNG?versionId=9raye6DKVExYeCh2AbChlG9gcNNT.R.f&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=c7MGjBJoLsO4c9mTbriWcGbv68qsHJtMtXlMYeSw329JUi3czQBpN1~e~~i9YYMVI-bbJR-rHU~38Hp1~-qEiemBi85BVXfzqZMuCAiopASU6a3l0KGaAXnliHWXn2qC6Le5odhU-VkE3YpGCDtNgQ~ZJjXD6IkGesTS3xA48hwaHbzBhXp1kGIwiVd3tmWcqYTBs4RJFDpH4Nfkp8jxuYF9HVq7h-HTVbB~ud0gQeOmEsWzl7kMYupOPa5XGgEUUQNl-tolFSJ4tdxf0RrFvL4XWHZH~ocZ65wfMnawveR7bRxxbqSPPlD7kXECuZ~5TBa6CDX5DdEIRy173zMBhA__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"m7lbhgZeTsUJ","title":"AI-OS: Multi-Agent Governance for Enterprise AI Reliability","content":"$50","authors":[],"created_at":"2026-03-28T10:15:56.000Z","archived_at":null,"created_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/khEqEi5raWMiw1NuIsoD1aK9Fp513lrN/uploads/avatar-469e5be5-86d2-4a0e-99ef-5fb332745753.jpg?versionId=MEVL6Lfq7EEVZvC9nmriRZPlyR0i68d8&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=CHphLO931dkxp3fNafS3TgbWbI15YVnfgA0P7iAZQAfLdFomu4~xiHGaZFsd8Ed95VuH6xxp9mxv9fYi~KRUJ5gcbuD6Rh0vq8FND67QJsfAgTimvs85-wknTrgGo2av3hFwBAn4Une-pZhGvn9AbhUQAY1yjAno78HJIjrveWMvs6~VZk97vorkQDrmVxav4nlxrBfTD5Ocs93z-peHN8uOXST42trJTr5nl-k4832-Tux8uvfq7hof2y-9owd~redcOonKiIAx55cgfoQrOHFcPMe-vOLd-Y6x9vSTXQfvwhB43zc8Ouhp~ENyfeksfotaJaOXCMnDJ9qHPqyooA__"},"full_name":"NUR AMIRAH BINTI MOHD KAMIL","username":"nuramirahmohdkamil"},"slug":"ai-os-from-observability-to-survivability-in-enterprise-ai-systems","hub":{"name":"nuramirahmohdkamil","handle":"nuramirahmohdkamil","type":"personal"},"license":"mit","tags":["AI Deployment","AI Governance","AI Monitoring","AI Systems","Anomaly Detection","MLOps","Observability","Reliability Engineering","Stability Modeling"],"external_datasets":[{"name":"AI-OS Enterprise Stability Telemetry Dataset v1.0","url":"https://github.com/strdst7/ai-os-framework/tree/main/data"}],"external_code":[{"name":"Ai os framework","url":"https://github.com/strdst7/ai-os-framework"}],"stats":{"reads_count":31,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/khEqEi5raWMiw1NuIsoD1aK9Fp513lrN/uploads/avatar-469e5be5-86d2-4a0e-99ef-5fb332745753.jpg?versionId=MEVL6Lfq7EEVZvC9nmriRZPlyR0i68d8&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=CHphLO931dkxp3fNafS3TgbWbI15YVnfgA0P7iAZQAfLdFomu4~xiHGaZFsd8Ed95VuH6xxp9mxv9fYi~KRUJ5gcbuD6Rh0vq8FND67QJsfAgTimvs85-wknTrgGo2av3hFwBAn4Une-pZhGvn9AbhUQAY1yjAno78HJIjrveWMvs6~VZk97vorkQDrmVxav4nlxrBfTD5Ocs93z-peHN8uOXST42trJTr5nl-k4832-Tux8uvfq7hof2y-9owd~redcOonKiIAx55cgfoQrOHFcPMe-vOLd-Y6x9vSTXQfvwhB43zc8Ouhp~ENyfeksfotaJaOXCMnDJ9qHPqyooA__"},"full_name":"NUR AMIRAH BINTI MOHD KAMIL","username":"nuramirahmohdkamil"},"published_at":"2026-03-28T13:56:15.000Z","first_published_at":"2026-03-28T13:56:15.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"wc5NOrAL1fTYX2s6yNlY3","name":"cover.png.PNG","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/wc5NOrAL1fTYX2s6yNlY3/cover.png.PNG?versionId=pccEQSkosc.t_tYMDFw68RtrVLqBO1g3&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=MMOlDIW8pxMxSVd2CDzxt~JwviFUJJ4K46Rw0pw-Rfg4dHgR8SaLATOuVC3tRTUL5YvgnsR~UiiJnUmYezUmRFzlrFymxfX~q-mC77yNjfUeuYB9ufqbRwzUunSIKOwS8xSz7n76PaDYyq9DI8WXVV3K9hwh5Q7edtSRDeSltgb2kf4U8jYEI-PTckmV0fisnDfIhASnng4o~zh8kXyOmGHnD2HcetXVRiSoZ0Fmg5jycR6QPFt8fv1UaSMcbJ1vD8ABz9QscJvjj1~LagvPazb2w0TQ0yRdpuzgTROgY~aP-PMdpXcdvAaGDD75SHVQVsiig3q76x5OTlDDUDgbIw__"},{"id":"l80TlyrW3yAqKoAK58Cin","name":"AI___OS.pdf","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/l80TlyrW3yAqKoAK58Cin/AI___OS.pdf?versionId=HeEH69UvuT.hIxzflEL3pxwXvnH3h5fw&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=B1fq--vcvmhOOeZ3R8Cuq8QNjdBYmM-src2jQjh425~P3fGPENSqD8sp0gCyZCoZz0dxR2emfk-fueEldC6Jeww0ToauAUAcA28pRbk4sEETNivMJGDfvLi5z6t0tDA50b5m7-GtMRhTPq2wsfsi5uj1wlqVkPtRAXLYRYvUC~tO~9Qe9~pt4C4jed6CpMzcOH5t1zt1QlOh8npme-rqgfWzRMvlhHq8Dy5qUt79UV9Wz6udpq1NRToB~CWjO~JJyDFzSck0QifRoUKgyk6EcRt~HMcnAx3mLB47tDyn3ddHrtI0HskAxdH7RARdnSSthGlhotqN5CY0m~flZ4EUTw__"},{"id":"cMBtLQ5lpNvEIPta3vyvf","name":"ablation_study.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/cMBtLQ5lpNvEIPta3vyvf/ablation_study.png?versionId=b1lVeXQqK82XIZ.XHSf4TXbPXigQJ.TO&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=dYhnp4sk7E96dAo~JhZ6ohSOMqJ0JXRHuIAk9AU317nlidZIroTkpzjn1HKhcvtkUTHankjI-41m8Owl-gZXiTl9e1GIuDQWTYD1QPkJDl7CNY~tJFppHEB8hGSX7zPaXx-octDAZXwgvPzF5Yk~bXMyB-l-kxzx48kRi1oRzhwReVVxhmd95IVpb8kynX7qKE1MqJTG4BA2OijbaJGzaGjiKqw0isXd3SubIlcYlQunlAvj9XgfetM0xlWNjiMKsPTDszevFPBM-1wTTFF~xlA3hKTR5h0vKzjx3OePsDsF4Veo2rnrLuvp4Vk3lPHCCdsZYwKAapqW1Mekuh2FFQ__"},{"id":"zA5qpQOA8eEuhmpJpdCrW","name":"roc_curve.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/zA5qpQOA8eEuhmpJpdCrW/roc_curve.png?versionId=5kGtE8Yk5XCPEW_VQQ1jOAqKf_43C1Tq&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=UePJp1iGrw-JQl8EYA4ZOUQS1ofCpyXBkqpmyBCwO7zN~Gd8hyKGaO3bY5~y4xPH9sv0JpnWXD8qphyjzwGLFFYAUCtkl6HG7N~A-kRs6bdWQablGXKyLpbZbap5wGV4c-jPWsXPzHbIgESL9aJV7eRw7vqdssNx2rY3mzWx2jD1lojtZnVcX5pTBI1NCZ0rs8blG9nl82txrCYSSefQa-wl-mqqUAxKpOF2hcezN0tJ6vqfeBs6DwCWHzsoqHfRKbnVVonxGF4JfbCbPDACNTqHqSzY5c7db7hgdQjsGheoNCYcDXZ-k9hMN3WCONVonZQe3IW2BCWZFM8MGAV30w__"},{"id":"77GMiXWsZpj03aHQkY7xN","name":"adsi_graph.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/77GMiXWsZpj03aHQkY7xN/adsi_graph.png?versionId=s1_tMzXeBENWvtMrZ6rnmqGXKlZjHo3v&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=r84Z5okPs~KCFEGPhzE11O4qxQ974aiwJWRkCtfT49TyRGykJIlKyktPvQuRzCJvKzN5p2uGzo-NjeB8z55mMTAGv-sJcvB154IZyflXLkuuZogLE9crH~R2L0NPmO2qhffH3uz0R6reDjrmT2kGVaUoV0C7XNbzyTKFUvzUJ3KPIHV6816A-XApc3-cfc~1QRYMvC~YcRdAbagF1sr4X35Gdu6Uu6IPL33~3GeYVvd253uh7iFkH94xWwRJ99KhtJgi6Pv6WUfcetrXBI7FvTJsFd085jEmI0psyYMTjlBeDQzgEQi3vMPmTqaSnY5J14kRaQViL2ZOvMa07lBJUA__"},{"id":"OUwnJa5Kw3IX7DE2Jj3VU","name":"cost_distribution.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/OUwnJa5Kw3IX7DE2Jj3VU/cost_distribution.png?versionId=SX20PP_k2jvWQUAINvz32uX30yedZjU_&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=s8LMZEotp1yD0qJMe46Xj45FVFqNNaRY6zYaA7uO~FAXUepGqplbHQ9Ksny7-HDd5zEre0UyxkUXgQFryjnSz41bgEQYdJzRD0n85IJ-ikQkwXFnaQ9IYxGmaPu8jgshF32vn5Ai4W1xXYU-cIiHKS9kmFdZs1rFvRgEBNSbHT6sTnTcw9q6vhgM6orqSFR3A2ypruNQIOCDtrISXtOMHv3jybAUpIJuzKfhLaABNb09XOBH8sTlbkyKdppWa-uXAXKNnRuBUHThiTal3SQhLSu6qszD2Zjq~H03zVAbrdAvFgj2dE5-IJw2DWR5EM612Lh1OnUl0b811XRxOIQbCQ__"},{"id":"1egIZqvEdjLoEqhgsYj60","name":"aios_architecture.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/1egIZqvEdjLoEqhgsYj60/aios_architecture.png?versionId=rZ1kjCiEekgT9yjlrS.53WlU29vw1DtS&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=zKdqCKO6l7hmc~Pmy2Lu7AuZuBrOPKoUiGzbPr5rov3seDOCW7FsT5DJw6OS47y5~M5pWnVjV4YwXfAb8~W9FdTIpfCuLaB4OHQDHpq~~Ph8N-4GjCHXtc4CHIWvLq8OPv2T4MNfWkeFAJ~mzT34m50~6z454dRjkzuF5cZwLR9WHd6x5MlgNRhqFyOPpCRRrlppn5i~puutioL5IiqKa4YBKmsZ1ZCGVlWMafVbg1ny5FNi7N2hpNCxCScy4dzv6I4OT97tYlz97-mFZskGmw-~fOMhQEUuBkV4aq-I0jbLBZddKr-qbK4MC3LuCR1PBmNqSjxPlBFH1N94cRTGjA__"},{"id":"oQe75ckXtBpi9oqpLhod6","name":"2f19fd44-a0df-4392-9312-ebbcd7660111.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/oQe75ckXtBpi9oqpLhod6/2f19fd44-a0df-4392-9312-ebbcd7660111.png?versionId=LL4kLy.TP.x.OYlRixtOTczVWOhDtHno&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=JCyXHP~ZrhrStJuwshs6-Uf2mIOGp8jG67jGxjMpqu~LRS2~IlUFh39tNC4uJ-DFyVTdXCGsNqg4v5UDN3R0jhOLutZ-0yHdkRd3eybH7pZAx65vP6~r9EGcYKi8jbad1rTMulRWmXnYoQQRjpvkUAh133b~BfbyyEeIWfYVbprH7bAZDp5wF7gMKgeJRclQVjRBKh6ScAj1r2fMSINMjGN2PsNtgB3JplJzCE-iTWw09rbhvsTqonY72Z2yhNLjmCv6leYkKYXD3oG5G8IilakRsZ17QCwvXfyamOh9V7oeDSOD3e8kCbm3pKKceuz7nzTV3YbLcCDHuMWKtvo6WQ__"},{"id":"Ai7I1p6DI3pHe1wiCpgud","name":"fe7170ef-ef4f-4d3b-b760-b114981c59b7.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/Ai7I1p6DI3pHe1wiCpgud/fe7170ef-ef4f-4d3b-b760-b114981c59b7.png?versionId=OGtJ3lH7xY65j6D2c4uIHwoIdPe8hOce&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=aJXHn2ySjhwcqJbZbhK4u-ENPGriRxEXK~JyqwwV5vH3c8ksH-qrYHe20m1saIJg4gl9lz1yKRucWs1AvrpVZ4csOa7Rd7sUWbnrr8fXmtLUg6LJb6s9qCGDlKXcRiZ8qJ60yqThEkBL82atJCxlEdDJJBAeR59~orgwl0yaArbbY1mu~E2Mq8wYM5Mjz8Do2KDkjL6cDre7Z8uRqrrS23FIdCRIA9zjopr19oX5D2iUdQExlHGhpk1RaaLQeum1d8Rt4VxRmOqeCZbCChlbCZ0-mxXl5iy6ejp5xWU8ygvXqR56hbAXNAtxR1SZ~WLFrKwAHZ9SijT5G8G8EPXL3g__"},{"id":"OTlTyAihBMZjBwjCKj1GH","name":"13c9698b-6992-4184-adec-176f4127ccc9.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/OTlTyAihBMZjBwjCKj1GH/13c9698b-6992-4184-adec-176f4127ccc9.png?versionId=WFEMrkBEJF3zKDHBI398vh1DTFMKw3i2&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=cI9a27ywvU770RQnV7Ojdo0x7ByNws4ZatTgGffAnKtp2slh66J~J1GHMavOTtZ0XyJsc-4sqHEhrIJRRJMNkkCCdKNd~0g74wHwwv-acKJsMen6J0WCGVixytdipcgQWedQx5SILZwQTTzlMafiPHy9vR825noFRbL9FRj7B5ByHnt2hXxhM9rL1ibsw34PLNhScyJbH6WjQkaXXUdgnYggJ1Z8n7rGKRpHdEjodrEdnMpLCf~h6W1ktq7-WiXZddxIJ3exMr5CuX9y-LlIXrprJQ2lFCmT0sDw2SECyqLVNXxxemjmtJtDtzgJw3ZuX2QJyfL0vSw-lkF3GEF1NA__"},{"id":"WmaNPvQEHld7R3yXFos3p","name":"13c9698b-6992-4184-adec-176f4127ccc9.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/WmaNPvQEHld7R3yXFos3p/13c9698b-6992-4184-adec-176f4127ccc9.png?versionId=8rkjjVzCeitl5acciHo48aVaPfWg.HnF&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=WfPflUp5jUPyleD-NfBNllx7ps80z0Fei0YsJNkiUoUhwPz2NJ1ubtjIWa7wdQxCW8fDEA7lLpKCNs-VQEGtN-IKzOyuRSW7LpsxDhEMGpABOn5d4-vJlJBD1Fu82q6Seh15sSbZREcV5k8gGYkywbzseIlVg0JdelCCc38UjF5b07h0Zg83k2EnVfgRLjHDi5xnEIDRmBRoQPtp2RByjLcDyXEJr3CCOCzJP9asF2gblz0lszEaEI0oMSu216C-1Zay3OT~su3dFU9OQppnf1Ce7~2BEU3R1m46sBXxrXP6Ux~dpPtcKZixDHgSfv-zxqWGSWyq7~7NHISRzJiAKw__"},{"id":"ZmUT2Asc34wB9bXDpYA7Y","name":"bac3f29b-c93f-41b4-9cc8-541a07bd57e7.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/ZmUT2Asc34wB9bXDpYA7Y/bac3f29b-c93f-41b4-9cc8-541a07bd57e7.png?versionId=XsVQpZMowAeTEVCU3aoXY80HDy5jiy0Y&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=GlUOPk-dcuc~eAMq0ixdXdUIMCpeYXAJUTVKuguVCE40-31-8c4UehkOuL4D24hEo8H55tonxKJtUORMJHBLOVkYLt~jXy3bsexl0j2wYIDgc7LSKt9LdiwPhX~7lfq15ureFM~fzVKQ0PZnhSJQpNhvAqW76EzYwRmWjDIxDupRPDXx9vobqEGgfRWOjctHV-3BV6sykixqEiVV1DlZPTu-zNnuBGiIpd2QRrRSo0k0Rxc6zSNYyX1XPH-L4y~UfT~fiLIzN9JrYOJYKpTD~tcKla62-fUT9HAU5iatBz6ZlNrvAIqoLmfExOzOUkx1Rt0IP30T05zbbELh2RqYfA__"},{"id":"Mv8VkdVXSVAFGd1j6iq9Y","name":"hero.png","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/Mv8VkdVXSVAFGd1j6iq9Y/hero.png?versionId=Mt9DGbT_HpkTc7zvA.QVjQGjZf2x6VOw&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=Gs0BPMqgLYEmApEvhqh7Ma8dz7tV5lXvMnGylJCRcPVYELw1NO1XtoRB7UDZNhdo2yj4jMnoj-XJuvTcMIK2vs9D5f50yRn5DHA1ajjveB~DImA1578AZ4cn8WcrkZ-RpQ8B1PqAsFIchT16WSYKaqJjUOX4haAldzEyOIms6A5kJMSsPAxbWz-d3P-XwcaiyxROmrVyCY3z-n6vqIHhf2bcDE3IaCZdICAHuGq9OUioLeqBMaW4~72h-lq2h4W5BQ~RYNAP7srw75uXTrEqQGBwVjMcj62UxXrwNzjpkY2v5CEMnakZB0Pb3MRVSAWGRiLYX7iiM56YG3eOiZT9BA__"},{"id":"HNMEysoibEl53nFE4ufwF","name":"methodology.md","url":"https://app-cdn.readytensor.ai/publications/m7lbhgZeTsUJ/files/HNMEysoibEl53nFE4ufwF/methodology.md?versionId=zYPMB3DUoFnfDQHpG1BcKdMZRNXoCmMQ&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=WMiiS8uNuJZ0GS9816bd00T3UO8ff3SfdVX0mRxpS36X2Azgjw7Yl5LiedQKGN7b-adJ1xG-XdhrAmEdKFdPwsWKcTl1flAXOMMbCP8k3HqMatkn~9S2lEwoAC3NchDsa39CVcHAq2k70Zgr8boYRhSTow2sqN~8Sgt6fcGQVpDhQxXsM6TZlXlygjaD811e~vNdYFoLAl4I~mnWcsW1zuvBeh~87hYSX8AWd1slhI2Q0VoBiDVPuim336R0Dqq3xwKdjtR998qfyHiCdmuLf3fNzFM9a~fH8596qbIJgwIAzzTsbONhLJ3BwA84Izjr6w6puOlHUvxBW5GL7UOSFg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"XIchnYORLCF0","title":"Multi-Agent Pipeline for Seismic Data","content":"$51","authors":[],"created_at":"2026-03-24T09:38:56.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Rosaria Daniela Scattarella","username":"daniela.scattarella"},"slug":"quake-knowledge-graph","hub":{"name":"daniela.scattarella","handle":"daniela.scattarella","type":"personal"},"license":"cc-by","tags":["agentic AI","human-in-the-loop","multi-agent systems","scientific reporting","seismology","semantic search","vector database"],"external_datasets":[{"name":"Terremoti.ingv.it","url":"https://terremoti.ingv.it/"}],"external_code":[{"name":"Quake Knowledge Graph","url":"https://github.com/danielaScattarella/Quake-Knowledge-Graph"}],"stats":{"reads_count":27,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Rosaria Daniela Scattarella","username":"daniela.scattarella"},"published_at":"2026-03-24T12:40:59.000Z","first_published_at":"2026-03-24T12:40:59.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"vqOmejr0Uef8K2gjcJScQ","name":"Quake Knowledge Graph mi fai un immagine che descr (1).png","url":"https://app-cdn.readytensor.ai/publications/XIchnYORLCF0/files/vqOmejr0Uef8K2gjcJScQ/Quake%20Knowledge%20Graph%20mi%20fai%20un%20immagine%20che%20descr%20(1).png?versionId=rzbqQ1l1COekK7SXjILfILrGt465Z6mh&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=YuCrM1~XmWR8Ft6AfmbX23eZENIoVU~EWZG5oxD-rum7~d3RICR1ivEfPeswhvmX1UopjQB89B2vrVE5WHJxuxdwh~8BDmowJYVWYdW1FkQlMepAIusRFCB81tSs7psK9kHON7Jl9Clt9PESDdepUZzpx4Djutb407~8RWo5GFOwCPmeUz4N6VoyI0mb49YXGm9hrGPqSDmZ4i7nzeWaS3Ll5fYHUKKKRcxr-M0XbueXQQ~fvDRYrHSoA9Avh-hrpyzQzloHAKBGjKeD2~vsacX6TRzYKhkvoT~ppuO6toOkfUgJOsKUkju79LNDu62MNZn4jSodzT8fhwrHPzZg8w__"},{"id":"yvDdZeylSBDjxhIebAWHp","name":"architettura multi agente.png","url":"https://app-cdn.readytensor.ai/publications/XIchnYORLCF0/files/yvDdZeylSBDjxhIebAWHp/architettura%20multi%20agente.png?versionId=5GvlprayuladxIhmRIRfs4TpJeRSvzp7&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=wa-11epU-MH9Xy0fdJb40V-yxUx9mP~4rgDFgNQ22YLTw6NeL-CnhZ3hRUqBVjIZOXQL5dhCglB1-zVCyyW0oM6VOo0nxpyS6ArIPu3E4kc737-DP5FZzzjSzUkJ1sYeBi3CmZ~xl-GsMUoOd1PZmlbSdXmbk7uEijvECoMHQ3n~LTrRQxaeJgJtZiOtqhIy2lZKrMkDHz7zws-yh-LgT0T6dZDJd1-XxQwiilG6zMyhYI~O2WVBg7xlo8ioQhnRd1jqkgMKOk4FJsi8qnHlEHjJYqPCr~AxV1azrJRwBj3xDtA10E~W8ynYT3Crznh2iAf94qMGGKk5i3o-rBzyvg__"},{"id":"pHHEKOeMhloeqsAl2yoB3","name":"Pipline.png","url":"https://app-cdn.readytensor.ai/publications/XIchnYORLCF0/files/pHHEKOeMhloeqsAl2yoB3/Pipline.png?versionId=xmfr.8ROMRcj8jwiF7qGsiroC2EVrcdP&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=t~T-K7E2d9e6qZ6bm5X~Q-ZnvmTbm1BI9Sflg8UsvgXpQWd3IKz8zbtPBMAlUjHTO0Aa2thEYaburQpJ95Jk42mzvcTuc8f2nZN9w4o44iiey7zUDkhFJfOKdp056bHmC2~FIp7h7Jh9aSC-hsp24myuzG38TbYMEU3~EF0dgLW6zvX54-QBEcQVRjjNQqw9wM1Pa2GVi~8iI8o2W5GGJMn7DbfxvOXfRJNPXzT2WhwuupXJ3059vqbHwTqmwDI1eQl0a24wui5kNQn~WRmNXutlmpr3ZKNM~nJ3l9MCFWTebZPm6KFfWA~hoDGc~nfsWKlDw-7gjYInuGlBkyVfNw__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"iXwxlS3KDKnS","title":"Multi-Agent Researcher","content":"$52","authors":[],"created_at":"2026-03-23T14:42:12.000Z","archived_at":null,"created_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/hXwdQsKEqVKrbOLSuIZe1lUiHQ3dbzoC/uploads/avatar-09da0bfe-0136-4e7b-a472-de2868a1217e.jpeg?versionId=6eUDT.ytsQWDnLK2Yfu2ts6aMNTyHqKH&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ghrPH0rMjxAGmVGZQ64hWuBSZhPtLJaLiA5tfIkZOFHTUfyzXcf9PhxFFnzbn7o0mY40MNtuRgBdShIa3-O1hjC4KJ0vaFS8H-MaYuB8uWvNlc29u98t0baY~5FuiT~pyFX0Er208yhvbyqyGCWvlY983dWFND1Il0ccleJH8h9H4bytghfUxJRipSlgq4Qlx9WAPOBj0EOwmWqdGSBRzJWRYZW7cQqpdQb4x1cbSGXpmrHIOA2RdWDfp9x5fxngo2sKJZ4rHVD77Wxzm7r3pEf8jnPSgFt~5KO~mkPzZ0c2fvU2Ila4xIelDqEpsrENcpvBakSL3H2v8kECR0ZhAg__"},"full_name":"Haydara Othman","username":"haydara.othmen"},"slug":"multi-agent-researcher","hub":{"name":"haydara.othmen","handle":"haydara.othmen","type":"personal"},"license":"cc-by-nc-sa","tags":["Multi-Agent System"],"external_datasets":[],"external_code":[{"name":"Mastering AI Agents Project","url":"https://github.com/Haydara-Othman/Mastering_AI_Agents_Project"}],"stats":{"reads_count":21,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/hXwdQsKEqVKrbOLSuIZe1lUiHQ3dbzoC/uploads/avatar-09da0bfe-0136-4e7b-a472-de2868a1217e.jpeg?versionId=6eUDT.ytsQWDnLK2Yfu2ts6aMNTyHqKH&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ghrPH0rMjxAGmVGZQ64hWuBSZhPtLJaLiA5tfIkZOFHTUfyzXcf9PhxFFnzbn7o0mY40MNtuRgBdShIa3-O1hjC4KJ0vaFS8H-MaYuB8uWvNlc29u98t0baY~5FuiT~pyFX0Er208yhvbyqyGCWvlY983dWFND1Il0ccleJH8h9H4bytghfUxJRipSlgq4Qlx9WAPOBj0EOwmWqdGSBRzJWRYZW7cQqpdQb4x1cbSGXpmrHIOA2RdWDfp9x5fxngo2sKJZ4rHVD77Wxzm7r3pEf8jnPSgFt~5KO~mkPzZ0c2fvU2Ila4xIelDqEpsrENcpvBakSL3H2v8kECR0ZhAg__"},"full_name":"Haydara Othman","username":"haydara.othmen"},"published_at":"2026-03-26T04:34:23.000Z","first_published_at":"2026-03-26T04:34:23.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"UOjIgTkk169U0x9YctZJp","name":"Multi-Agent System Architecture.png","url":"https://app-cdn.readytensor.ai/publications/iXwxlS3KDKnS/files/UOjIgTkk169U0x9YctZJp/Multi-Agent%20System%20Architecture.png?versionId=WN36iVpjdJA3EPMISuJnDnYska5X.Lr4&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ghE55fnIrsR13926mbgs4K6NKjRjFyfkUiQHan1oXtR-ZREsyblcobXXMyXWZyuwWtICaY8tWMPAwtmpTi9JFGf4q4dMVRoGF6rTf2xHtn5cP2VJt~EEy3m6EYfQw~Eshkpbnjx3kvifEROt1SjGB-qg8fL47BAqglHtxz0egGZOmJGhgEp9fzphiP61w3HHi5eOwrvGjXq5FyRY6oCF0eM9sf0QwCJ~JGvqLBSz8uPVBlmvIHpt4yCiqXnTN7uO5yE-o8kKlTO71Oi5g78wS27olJuOitjmjDIQxzeo79qXN9Nhou8RbR3ABcVBjA-a7iSz69PxH0xbNghyTHh7DA__"},{"id":"MLKrwB6aHPXUxjEMDOzzO","name":"Summarizer-Critic Loop.png","url":"https://app-cdn.readytensor.ai/publications/iXwxlS3KDKnS/files/MLKrwB6aHPXUxjEMDOzzO/Summarizer-Critic%20Loop.png?versionId=OotV12lXVAEDtqTcoDlqxFavUhDhgB3R&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=IlpyfbgSD6TpOfklDz5Tz0Vw5Fv0zHDbGJ-~grZJrpSlb3ijiHYxo6yO4wnQCNmqfLVkeHaNVpGMxKWbr8wL1lx02YSChQ4Fb6lFdNZ9RzuP6Uj~~0Tbr~KvFSnV2Vfn8X0yUv6s0QvOLfua2colIkJJG9OrGebanKOnGNokO0ocmw3AIqchUXiqyopiiM7Z3A-mqL4RL2W78LqelD~SRLDI72ZZwQNxJC3iBvkAi-y0Yh40aA3RKiZopd~avZ8~hJrO7CdZjmpwR59ACYu5srXn74q-5N9idhYQMpXV6Ja5-Dy5vROUtKuViTG5LMKXbBGaCwAM8RDzk-AJfy48gw__"},{"id":"DtE5gKv01yUhICdtAzK21","name":"istockphoto-1495008087-612x612.jpg","url":"https://app-cdn.readytensor.ai/publications/iXwxlS3KDKnS/files/DtE5gKv01yUhICdtAzK21/istockphoto-1495008087-612x612.jpg?versionId=TzkfZDpnN_Rm7rNWlAUYkGaHDnVM48I2&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=icOZWm3z1ZzxD23~nQx-fMQRrkxcsfNJqdXrff70-GtnfMinqqxA98MAQxpfm3xt58ZJwSrYfs6lsVAhF8Znv0Pfyd5eFA9WBAaecaSDpFwrQjHsNZO0J5gZxSi-0etbjMdnn1Iv5gl10JHIpQnEXg9Ug9~LSEzWjiwDzBY0bZbrM8WP8CHbC~HSBJxn7XEWW73lbtZ1DFS4fuwZsVz17hZWZ-ZaFqK~Fn8xOslcgoW7BglkwhPmttVo5ryhvBTDXGxxjy48fARAJxGtjQZPSU2VU20vBX-2X-GuBdK5ybwQXEL8F~TzQN-zBDxsJqa1gOlGs-ArhytPDeq9iDzoNw__"},{"id":"xwwqG6jMH9zSVcpB6KRr4","name":"writer.png","url":"https://app-cdn.readytensor.ai/publications/iXwxlS3KDKnS/files/xwwqG6jMH9zSVcpB6KRr4/writer.png?versionId=OlN8.ePa5LlMQlY6jIad5WieCeZ3PXXV&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=PQSL5KVlXEWB-4fqWjVt7X0Zo6P4aRTe4zfLcUl9ZSgry-2Gwu~CdMqJRdAjcgtm0lpNHgBrBrtduncXh2IvTUocA8B2axFOoZ0D51l56e3QpsjIhE3qgTGo7pwnOeXczT1TrljmkzUBBprIhYxP5YO4oBbvONV-zjicobjGGWp~SreDBAf5ME1DbpbDydpPRZBU9-8pLJeRF891oZ0djad1bsKhY1dumlrxTX~Hzo028K6mnulhQbrUtGO8mbvF6szBwpOFIX0NRH9HZPEtfDjVCftinj5myO0aI9QbeFS~1sifTvvFUEFCII4~FU-RpdilP7urlwhcyF1rvH4Rkw__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"XimePcQqROwr","title":"ApplyAI: A Multi-Agent Job Matching Assistant Built with LangGraph","content":"$53","authors":[],"created_at":"2026-03-15T11:31:03.000Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"--avatar-bg-6"},"full_name":"Fahiye Sadyq Muhammad","username":"fahiye"},"slug":"applyai-a-multi-agent-job-matching-assistant-built-with-langgraph","hub":{"name":"fahiye","handle":"fahiye","type":"personal"},"license":"","tags":["agentic-ai","graph-based-agents","langchain","langgraph","multi-agent-system","orchestration","Python"],"external_datasets":[],"external_code":[{"name":"Job application agent.git","url":"https://github.com/fahiyemuhammad/job-application-agent.git"}],"stats":{"reads_count":34,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"--avatar-bg-6"},"full_name":"Fahiye Sadyq Muhammad","username":"fahiye"},"published_at":"2026-03-15T11:52:39.000Z","first_published_at":"2026-03-15T11:52:39.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"FxABrqWvh3S6zGkdL1Fol","name":"multi-agent-system-image.jpg","url":"https://app-cdn.readytensor.ai/publications/XimePcQqROwr/files/FxABrqWvh3S6zGkdL1Fol/multi-agent-system-image.jpg?versionId=KKCzZWaDZeUvQeq_KmWfKLFmNv27Tybu&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=mnmfRpYVSywqPu0OOc9vtrDdRlqXhIC-AxIlhzvrCD6IR~P~jc7p-KPMg9IoDMPn2u9M6cDXpjcvRWyZtA6MVZewGH0tToGoEOoqKtw~30mmbEPOdVBV16HX1zu~sHD5as52DU3aJV-5R~IXhNZU8a9L5~ycloHdC9E49RvJN~X0XhoglI0UmatGveaKQTP-eTaJ4fwrUQvR4iv40T~PGVf2uk9AA5d7y6Cz0GpFku4nP~lIuFP0yOzTMXw-9pmAe2SH9c5l-CeY10E2v4b8hsuDJ7k2DciFk5MXGxiu5udhe0-7QeFUDz7m0YabYYXI9mKxh08f8EteC1iFKPdHYQ__"},{"id":"kQAWPQ4WN9p5JIobx0iWK","name":"Screenshot from 2026-04-13 16-42-35.png","url":"https://app-cdn.readytensor.ai/publications/XimePcQqROwr/files/kQAWPQ4WN9p5JIobx0iWK/Screenshot%20from%202026-04-13%2016-42-35.png?versionId=1hgYDjSue.DgJTT0453p.mw5sNs5pEAY&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=D5M0TygxmQNERZQ23tI8uE27rFYKFK-BFAhSeHGyV8n~9AsZ2hKY-v1Hm6MjqDy5FZRIcSpa7nadQ1~X9tdR0e6kJ9dAw0seGIvD3-19RKIYxmSuYqglBeAtex9xkuUSUNigv2OfUqkuEeBXCR9i1tzbqHgndsfvHFl4-9~OO-WkCMH67vKnxIhRn7H8CIBRNbqjDFni5IajxxSrO3yM9yrLEzge4KtyN2LhRyG9R-zKiW~qHZXNIjmSIFyIXPBvNKfEDylM~yso5rNxT8aXT6bp3XVPqYJ7mtKKarbL~Qyr5bVgfwl-PmOtFqZQHFCZ-4bpKEjswjNkPV13dm2NDw__"},{"id":"z7GuNxez5LSo1cUPjhszL","name":"Screenshot from 2026-04-13 16-48-21.png","url":"https://app-cdn.readytensor.ai/publications/XimePcQqROwr/files/z7GuNxez5LSo1cUPjhszL/Screenshot%20from%202026-04-13%2016-48-21.png?versionId=j1TSdpP5BdVRi62wUZtSLFlrh1S56arW&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=N0FxbGkxRll7xb9fFk1Akp0InJE-Cb1NGHmx2Y7gWh5u4z9pBJmgM15pKkdEvIAp8sAzlSgraBvXklxfEcQAT~Q5HDgxgYUg2OxgfDNmhWt8sq9WdNGzP8eCbZFs-eTs7yKAbqOZ6cc3Lz4I4N~-ZbRv70EKT-xTrIh5lHfG9F-cMYf03wbhj9dkuPWaro6JLda~Gv7THPQAGczzBEih1qhI2YjeeDcMxMW1AEsYJBvS8bsbUoQAOmeVKtcqlb9rapLkZY0zNxVJVvV3zDPraN-qoDN38imuCUCAh1u--gD4lBaUDqdjbqA5xM0PEAGKdaXTt2zMacI71E5uBrmjbg__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"HEqIdW3FgxtA","title":"Multi-Agent RAG Research Assistant: Reducing LLM Hallucinations with a Three-Stage CrewAI Pipeline","content":"$54","authors":[],"created_at":"2026-03-05T03:14:32.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Samrat Kar","username":"samratkar"},"slug":"multi-agent-system","hub":{"name":"samratkar","handle":"samratkar","type":"personal"},"license":"cc-by-nc-sa","tags":[],"external_datasets":[],"external_code":[{"name":"Rag research assistant","url":"https://github.com/samrat-kar/rag-research-assistant"}],"stats":{"reads_count":32,"likes_count":1},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Samrat Kar","username":"samratkar"},"published_at":"2026-03-05T03:16:44.000Z","first_published_at":"2026-03-05T03:16:44.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"EntHxPgvYgV03xvuehM3f","name":"publication_banner.png","url":"https://app-cdn.readytensor.ai/publications/HEqIdW3FgxtA/files/EntHxPgvYgV03xvuehM3f/publication_banner.png?versionId=BPetc_hqhDNzQs3qe.5mj1yUj3mL82CS&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=kOHa2JxD-9leXSxPBME0rVeAb0MFUM52Qh41vFeCm9Kw2F1R5G7Ghnn-6Jxm7ACjoZu677dWcb7xcecK2xqWpJkbQPspbhvTZHtdFgc9UL0pGhMKPG2eQ5mvaCt0LDJCjm0f15Sw5cm26MabShlioJKjMsc7lF2DZA6V0Laf9uiYGdIoaOG2kRkAupLEVbkUAoJ1qRv6IK3ZQAu7DemqjAQZLAP9RPnpRcZKzmnScH7k5jCXDpvwpOksOEHqwkU4in7RCsO-wsYXN2qF3KQbQLTmLdX9ELkk-3nkrzVsOMaxGrHpY2wnu2Yf7OvAk6Oh4dyZz-onLXWEDUFe1R8syw__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"skCsZjSyT79D","title":"SwiftAudit ","content":"$55","authors":[],"created_at":"2026-03-02T15:22:10.000Z","archived_at":null,"created_by":{"avatar":null,"full_name":"Joseph Mutua","username":"joseph"},"slug":"swiftaudit","hub":{"name":"joseph","handle":"joseph","type":"personal"},"license":"mit","tags":[],"external_datasets":[],"external_code":[],"stats":{"reads_count":33,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":null,"full_name":"Joseph Mutua","username":"joseph"},"published_at":"2026-03-02T16:24:01.000Z","first_published_at":"2026-03-02T16:24:01.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"jY2ApCSrPrZjHi2jEU28K","name":"Generated Image March 02, 2026 - 6_36PM.png","url":"https://app-cdn.readytensor.ai/publications/skCsZjSyT79D/files/jY2ApCSrPrZjHi2jEU28K/Generated%20Image%20March%2002%2C%202026%20-%206_36PM.png?versionId=0.3vpXAKDATYb7kslP9vGTPhiY3pY7iN&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=dD3A-h5rKQC166lI07ODzaQYT6lcIO8LJE5wSU9B2JYsYvV2moIBPbJgUuuqwgOofxMKQTB3V-bbi3tJaiGsqu8AfnEKe9x9TFunrHYrN6n7TMnImDWeZazW44l9mu5piqsvvsZQn6DjZbebkhT7FNP14y-3wrFmF-E5gfhyzntechFsmzuOff8vu8ficj2zLey9AiMl~wqYbvaHETiVc9M0gJ-SUm9-YXNtG7Uq0n3IZoByRItv4Ng0-8F8HvF5gFeYzTSbiv6Gyp~DYd3oomsGUVIKbesShKsLLKJEvHA1-SrdOXirp5O21potuUA-Z7gnQeTkn93QXnivNSLNbQ__"},{"id":"7tMapEFpvST9QzI6I8Qub","name":"Generated Image March 02, 2026 - 6_40PM.png","url":"https://app-cdn.readytensor.ai/publications/skCsZjSyT79D/files/7tMapEFpvST9QzI6I8Qub/Generated%20Image%20March%2002%2C%202026%20-%206_40PM.png?versionId=vXq4gCqrhb1q6HXuJAu9OCraZhAItiKv&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=OsO4p56ZdkkA8hgjGCcwoEPI7qVbY85I65MfdQ43FJo0oebSRIlZmaIJwzxnKoDWYKBzl3IKYi~3Ph498vs0x51EJgeVEe3Un2qFhSFV-KJybMzYcXszPvJFfUwMEaILXEHTeT6jZNv4vbQ~xrlIOfo2-jTJPbfXUHEK1n0mSDcQ~QNBLbCTQCVb2mjOd95EX6-cl96REKxJFtyYJkdG9ZE3TSIjcOgybalpc8ViSuwfDXGXKU6646jWh4fBJs72xJwPapHYAPrbb77oHMD-COqMOn-6CpDg5G25uBZ3OMJe30mI7KLNodwKaksYz6fwXBgdNh2mcfXHLBKAUI6jyw__"},{"id":"87GuqKjUBjQpyT9ORH5Tw","name":"Generated Image March 02, 2026 - 6_45PM.png","url":"https://app-cdn.readytensor.ai/publications/skCsZjSyT79D/files/87GuqKjUBjQpyT9ORH5Tw/Generated%20Image%20March%2002%2C%202026%20-%206_45PM.png?versionId=R93Nm3ebnTYFTf.rU3QZllz4vhNt.C4o&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=JO~kdqsXCYUpsKs1KpSD3N~OSMJi5SzRJCa8vlqsezZgqxmdDAiaxGw0Tk0lywcOxKP6mlrhwkhMbvfbUfCGfbd5RFrwr8nA72y-qVOB-36gL95Od9f9EVxmXhi13OdmfpbjKshGvTab0YnUQ3sq5Hvr2fGCXZBlqAWyzwKspJ9gqWuF9h4QPm8LxeGaUwhqZcweFT5bPK4rBz5jgax6rbzR2k9u8qX~zfByyKeTCGcd3l1xzVkkMZHVgoiIN9XDxsH~UugImX3foCxp1omdwU119niBkDy1-QLgp~o-9E6d~KzvdtjVd4SkAoEpgW2d992YHc3lYniW-wXVyXaPig__"},{"id":"o0FFtmpjbqZknrIj4hU8K","name":"Generated Image March 02, 2026 - 6_52PM.png","url":"https://app-cdn.readytensor.ai/publications/skCsZjSyT79D/files/o0FFtmpjbqZknrIj4hU8K/Generated%20Image%20March%2002%2C%202026%20-%206_52PM.png?versionId=f.POQK1xxkGBPO_RCjoxzN4uH2iQ3evf&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=vltPcHDsGt2kwJusyApobrl3w637qxA2UXxsJP93rYVTlg~qsRMRTc7cCsbo5FLhcrnlLIIO5vU9sI3iPddpX8pv~6f3xPyAamF0nz3EZwRch-XUJWOm3B0JMyIPPtcet6An-g7141rBEzY3G8ZRN05zDmzBWWy1S-RTBN8J1a2ikphi9yAh9CjheuCqSPH~ojwEi0ifGbJJ0Vppze77uoZOie1XLApu6k2F474TUX1rWAhXofEKeEga0-v3LDW-eG5uwodiMeqW4QlHr-AFIe2xFXHsP30SmKP6SGzVvwHrPT0y0itTzUMO3TIl3rGvrPQV9tNPFxZTgCECWqaHeg__"},{"id":"lWnhCKWhDg1oc4DnYKo74","name":"Generated Image March 02, 2026 - 6_54PM.png","url":"https://app-cdn.readytensor.ai/publications/skCsZjSyT79D/files/lWnhCKWhDg1oc4DnYKo74/Generated%20Image%20March%2002%2C%202026%20-%206_54PM.png?versionId=E7MXL9V2kRbfGAAj4zy1d6WxpTo4zJY0&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=FamAEdYgV2IU94A~iLRG3nDLZaM1g-ryRKNOMvhkmo5qdL8BltkGejG4Vnx-tyFYl0w9uX789u-yMbXKsUd2GBn5aOrXnmVyASswans5gmoJZJf8ZNDAl5VPAxBwxeAbH7TX1aIMarSL0hqnC8cE-RdMA31R7Z37dLuKBxVkHjUsevEB4xiz0nYBfu6VrmyauFa~RLY3q~ZBGHCB83QLAvt9lC2RhYXbXZ0MSseEUwSqsts5WlKZtgheo22IGrGUnjTwPg9ydoNVdZChpHhfIvwYf6LM2NtVns4kEdi-IErkp9EcZ-DWEXJ5d-2~dY0MvMCPPZ-dOQQSfbGPfKr39g__"},{"id":"tT6eX9EUtAqbQhFdVbjew","name":"Generated Image March 02, 2026 - 6_59PM.png","url":"https://app-cdn.readytensor.ai/publications/skCsZjSyT79D/files/tT6eX9EUtAqbQhFdVbjew/Generated%20Image%20March%2002%2C%202026%20-%206_59PM.png?versionId=XQckmZgR4ItAVgEMi7cv7x4FGoYtiqtv&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=vXG0nco8~tcz8XoPZXk5OhRvPexymlxzzGxMdtru7Bo~kS0d5jACjEvGrMR3MXH04Ij0O0wISrodaa~U1aMbTjYEPr64M1Rn0nW7YKoQrx3T8S8B-pzpt8BXpeNwosWRaCY0xTyL-aJgLJreXV7J2IHxX5dygZdXY5oihd7sb4e05NMB0GqOlbKv~PsyBPOeVerItm6DeBcs0vI3B3t1-6yVDp9wJthXuxuzbV6ozNX3XBiFte8oH~81yYi2M8kF0HKAH2Tu3sOjSF4MbD~Yuu3J05wE8N0~4lc0RcsS7Mn6jdEd2HvhvbZVQEdXtcoEw0dCFZivDONKHt4EhKwJug__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"BeO79d8XbBSi","title":" Multi-Agent Systems |Digital court room","content":"$56","authors":[],"created_at":"2026-03-01T08:55:22.000Z","archived_at":null,"created_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/YW5zolUgyY2t9ctO4nJoWIuLdm4xRTHJ/uploads/avatar-9612241f-d6d4-4278-a572-2d55fb2589f7.jpeg?versionId=nRawTyT9.CViHLUkcUrriDoBmEU9dU_B&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=C4~RZKT3pq5Kym7N8KQuHedtpPk-XMZR6VIjltFIQYirWMg8izemEpKUuR95IpTewvyfrpJ-PrcaUe~~e~cDT320rP4nY4hhsZhxUB6aHk0dPdoM5wgcw61rw7l~G1Xx4yJdg7~V-9oqZX4qk1aUxB1xbrX1vUuvwNiSNtpD6611wRttbgg3CDRhJO73q27ZtSlxc8hInOyKr2trJQTTGJbxBCuyffZKCjr4oi24Puap6ySXTgAT~Xvyh7HI7J1dyxywsj-X7d9mizFYAT1rPU~uP4ctkdBsh7iVuVe5XVPpWv2QxnKv4j-LJLizOg~KUu4CyhKL9ffR9Ss-QMVmTw__"},"full_name":"Kidist Demessie","username":"kidist"},"slug":"multi-agent-systems-digital-court-room","hub":{"name":"Ready Tensor Academy","handle":"ready_tensor_academy","type":"public"},"license":"","tags":["#AdversarialReasoning","#AIGovernance","#ASTParsing","#DigitalCourtroom","#ForensicAuditing","#LangGraph","#Metacognition","#MultiAgentSystems","#PydanticV2"],"external_datasets":[],"external_code":[{"name":"Forensic swarm auditor.git","url":"https://github.com/hydropython/forensic-swarm-auditor.git"}],"stats":{"reads_count":37,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"url","url":"https://app-cdn.readytensor.ai/users/YW5zolUgyY2t9ctO4nJoWIuLdm4xRTHJ/uploads/avatar-9612241f-d6d4-4278-a572-2d55fb2589f7.jpeg?versionId=nRawTyT9.CViHLUkcUrriDoBmEU9dU_B&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=C4~RZKT3pq5Kym7N8KQuHedtpPk-XMZR6VIjltFIQYirWMg8izemEpKUuR95IpTewvyfrpJ-PrcaUe~~e~cDT320rP4nY4hhsZhxUB6aHk0dPdoM5wgcw61rw7l~G1Xx4yJdg7~V-9oqZX4qk1aUxB1xbrX1vUuvwNiSNtpD6611wRttbgg3CDRhJO73q27ZtSlxc8hInOyKr2trJQTTGJbxBCuyffZKCjr4oi24Puap6ySXTgAT~Xvyh7HI7J1dyxywsj-X7d9mizFYAT1rPU~uP4ctkdBsh7iVuVe5XVPpWv2QxnKv4j-LJLizOg~KUu4CyhKL9ffR9Ss-QMVmTw__"},"full_name":"Kidist Demessie","username":"kidist"},"published_at":"2026-03-02T07:10:05.000Z","first_published_at":"2026-03-02T07:10:05.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"OeqV5Z0gDV3hPsEly4bb3","name":"ChatGPT Image Feb 26, 2026, 08_53_11 AM.png","url":"https://app-cdn.readytensor.ai/publications/BeO79d8XbBSi/files/OeqV5Z0gDV3hPsEly4bb3/ChatGPT%20Image%20Feb%2026%2C%202026%2C%2008_53_11%20AM.png?versionId=x5rBEkFpVy9ww5jkQopPatH50a54k92l&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ypE~mnIQt0wyc4sJiSYEQPk9W4X8lkP~g~7q-Qr847Gv3B-PVJaY3SuoPWdQB9jcGwkinM52mxzQXQodIv970CUzjr4c0tT8WBFQhck2zAZ3qp2zjpjXkWzb16P5a81~cWcnEFiizhGtLv5Hczp6mB64SrtG1pE5Jowj4M~DZWVF8xSTjR31X5K4u01suOelNLlhb-9OLbaWkL6RNqcgmmY0otpOqDjF7~kmrNqOaw3QOL9vlXmDWO-iGvs5WkAfysI6yAum4qP~vk4NyZhB3ehrewpwv0e2wl-BJgYh~nwkBBJdizQp5~ShNhs8k-vHGPiC--w6xiX-KtoxpD-elw__"},{"id":"cgPdYFcM2QRsXSgkWvvLV","name":"Untitled diagram-2026-03-01-091219.png","url":"https://app-cdn.readytensor.ai/publications/BeO79d8XbBSi/files/cgPdYFcM2QRsXSgkWvvLV/Untitled%20diagram-2026-03-01-091219.png?versionId=mrS8JbfDh1UazScTws76CfM58QXXTKXC&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=m7wdrA3YwdAQtcZz8sjjClJolIlvgz4-UxsWIT-KBlYGqQHdXWlIP6hUtlCzo1QPMzNwizCv3xR7lhVHHaMHiSlMwFxomwza6IsDUqKF75RuVLeDpb4ZGQnBvJMurX4rtjYkf81k4yQJ691SlcdNXSUyP4SPnD1WaEcBVthMOjAE5XPVnk7fcX1O3HNI-FITtZpkSJeQavkj4ma0eCw2DINRPL47WA2FBMbbFVTzQqBJJmAoYkBmxfAFoyPGemAwykzno9dyzmAHqGK5k6JljM42sJK5-eotqfQItyLat5uJqQ1RDFmRduM~nXSV056b8bH3ubQ1JVYX6CAr~pcBxQ__"},{"id":"pHJ1Cc1RIgeb5uxfEyx9k","name":"dd.jpg","url":"https://app-cdn.readytensor.ai/publications/BeO79d8XbBSi/files/pHJ1Cc1RIgeb5uxfEyx9k/dd.jpg?versionId=Tj7KSojedrzkJBlerfemnv08onZENdKD&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=0Mi5VcEQOgOcwM0jFWiwhPVCYMVzQMrgPfIk206iXtkvX6m5qtPG8SBeRKrLOk8Oc-n1BAh51FvxzwKF6qYE-csNcJxR77gtGxvOL4b5u030veIPPjXCWXuz5Huzjc1r1Ik5mivESIxpei6otAVJ1YPc41AH6SgrAZrcpru2ljlNpkWsIhL1Fh8MoXUs7XW7PUY09y1TKZT09UYYnlZuRbSYvnZ729lE2OdbT6V-dTAbvCrnpMKTYREGtne21pTudhrj4duMM6VfxOOT5mSELNpZ7sKi6-KdQGddyvkGwGSp2Z-gpnCpC6ppew9iMjZvHbiZ5VYqESWKwqxRNy9XbA__"},{"id":"cLZ1yjW2SRBQsLxVgugYQ","name":"nn.jpg","url":"https://app-cdn.readytensor.ai/publications/BeO79d8XbBSi/files/cLZ1yjW2SRBQsLxVgugYQ/nn.jpg?versionId=LBfmK6GLmGuLL0lcw6rNLhr8Nui1fvwl&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=tf7kNsR83zYkEEyRaBIjI~F7IbVYHrXMoYRZo20bj1XcrljDyYZvATYobKcrUWKl8kTVg48aKoQSLSzfdQDfIOO4iLluDnBPphMQp5WhmLeVzkgm1pTaa3c6njDny8xZdTkFNAAanFygW8eCTefEbWk6Mhs5kaE-Ox4RhK3aPGHLvOr7aYGTnAuEjvrbyVjhm5CHQ7DTNyjv7p6DOz5EHj0ktYxsTcRSvvi2cvzDj-lU20t5b7EKtbDXOFe8ioJt1T2CEao1W0QbGKf~erYRqnAjHIhwbkHs9Ei103fevCv5f-AacOi5LrYHEmUhzN2LvPbAXtfxsp4LEEtmxf5p4Q__"},{"id":"PRTJLRYjPcRQKzJl1idNU","name":"Gemini_Generated_Image_iycjxfiycjxfiycj (1).png","url":"https://app-cdn.readytensor.ai/publications/BeO79d8XbBSi/files/PRTJLRYjPcRQKzJl1idNU/Gemini_Generated_Image_iycjxfiycjxfiycj%20(1).png?versionId=3jaxFod5urDcJpUlOd8751r98VoqwYbW&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=gEJJjc17DZF27f49OtnyRosnktP4PqbeLAjJm3ucJgbjLV6Q4vA--R7x-AR-Lyv9nFtQXo4r4-I3NjALn8wL5l4B79dxL53-NjqbHOlACvuz8~plZnuQGySE8Onjyol82c~8tjNKDTkDR51-WD2-dd-UFJS3SeIznvqT8WApIKaJXZdEiujBn1VIFhWJuqmHNkC-91azr5OU1mWlBzDNennZT5U-Hh2kUQjHHeLXTvxaBk4ntHOqEYyelOTXqTSwS7W48mLwazDU25bs--3P3us2YmOU~ODquODynfpMaMMcRQMxGJCEYY3SSaevMQPrf~y16hraLofV9sWqVBOGRQ__"},{"id":"MQbtSb66XNLItmBjtzRi9","name":"ChatGPT Image Mar 1, 2026, 06_17_01 PM.png","url":"https://app-cdn.readytensor.ai/publications/BeO79d8XbBSi/files/MQbtSb66XNLItmBjtzRi9/ChatGPT%20Image%20Mar%201%2C%202026%2C%2006_17_01%20PM.png?versionId=w20fjTmaBgBA7zN3K64gsVWQCdW0m2uh&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=GXbqUIDVDaMV8fjfZ-vNt2O9Ic2f-n5fWV~HnjKyQzcW9ihFdOQprjZF2IFtODrmQ8quRYJ11NoQQva~6YJ20A~5VrY4c9EF51ympru8XF0Mts2ivU2muSoD5gKMvNT1GGlboVvkHbD~WctF-K028gnxdnXE7Y2vo2v1FwQPb3YxiSBUnHliHB7dZ49-mvrxBtHmjWWs2UPmmuTCtp9~Q5sMwaRPzeuEhQ9EU9b3Hbh5pPstY5NXiE2WWXXxBQ1i~Tn8k1pQ8YVXMx3GZkHW7ZA9ymXHhnYIJjBn8Kkx7B7hclFzaQPXtiC6zdnR8Gp~2ng0UsrCHi3C9ox6L2b1uQ__"}],"is_flagged":false,"is_completed_program_submission":true},{"id":"1GiH57XcQCHz","title":"Autonomous Multi-Agent Research Report Generation System","content":"$57","authors":[],"created_at":"2026-02-27T08:47:12.000Z","archived_at":null,"created_by":{"avatar":{"type":"static","key":"--avatar-bg-7"},"full_name":"Raghul S","username":"raghul"},"slug":"autonomous-multi-agent-research-report-generation-system","hub":{"name":"raghul","handle":"raghul","type":"personal"},"license":"mit","tags":["#AgenticAI","#AIEngineering","#AIResearch","#AutonomousAI","#EvidenceBasedAI","#LangGraph","#LLMArchitecture","#MultiAgentSystems","#RAG","#RetrievalAugmentedGeneration"],"external_datasets":[],"external_code":[{"name":"Multi Agent Research Evidence Based Report Generator","url":"https://github.com/Raghul-S-Coder/Multi-Agent-Research-Evidence-Based-Report-Generator"}],"stats":{"reads_count":53,"likes_count":0},"is_liked_by_user":false,"publish_info":{"published_by":{"avatar":{"type":"static","key":"--avatar-bg-7"},"full_name":"Raghul S","username":"raghul"},"published_at":"2026-03-27T15:18:28.000Z","first_published_at":"2026-03-27T15:18:28.000Z"},"original_language":"en","translation_info":null,"files":[{"id":"KquRWa2lauVcGhg8MpjpD","name":"src 1.PNG","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/KquRWa2lauVcGhg8MpjpD/src%201.PNG?versionId=CKTxiir80EZ3MlUlAMf9flbrobjmsBKV&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=B9Fx8~v5C1k7WHcoSuRCq6afXrzrWZO-CW8yNB5gs1uQXWUqoiwIjpnoZrtemkrxenj6RaXmOzBJzPwqRpMOLtFIKkIREagBhC6Wj3Cv9F~0Bm4sbXJE0Hn0BkDxXv68aT7ERUcdjYMGahTSkJUA9NoMqcs1PZx0UNcw2IiARC~ukuyIbDAdCMehYNd7KFAlZ930bhcoVc6cLYslNtkTuMUMXnbS9S9bfT8lKd8duvj~-9u2-0i~C3OLvbreXXmsazDsKSkBF8rKhmMlCylUsrgleTlhzoDGtHCWRyarY3wHczAb7b3scOhRIz400cywzaHiOnB-rYUx2BE2oSkvSw__"},{"id":"cRj7N9LMBEUDd4qe6nJF7","name":"src 2.PNG","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/cRj7N9LMBEUDd4qe6nJF7/src%202.PNG?versionId=5pdBXShPD3yLGuMsD8BuQ7PSa1qEa0JC&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=fZ9dzHp3js8k6~7qaswCy0YtkS28S-KZaOhefdLRKc7oHuQt8~f7ty7BvXATSiG-5ejnGqTWMJPi-QnVMMO4liD7q4ibqihZQHlQN0NsO4yry40yQjSCXOSv-2kfaVkbGKRujVdjS8pl9SY2QKvdYP3fR8zJ1dKI1nn4r-Jv062WlX1MgYjjDDw3SHtqT7WZfhCVJgGN4O7vg~8d8jT0Xt~7gicofsthTh8oneA5843brw4wtQHsLFHLNXOw8GxDsrG8RcpJet4eE~~cx21KhDbfb9Cb8MMVrF0slaneK1LIvHC8vgOIwLZlSw2A~c3eGi0S0YFgR~104LzU6TuzXw__"},{"id":"NqxiGJhzI5pySusVMnsXf","name":"src 3.PNG","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/NqxiGJhzI5pySusVMnsXf/src%203.PNG?versionId=F0islMyEP3TVyyDJTwtE5ucWhdTtJxLY&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=xXmtpBAp-TheNnhtwTaXS3wfd9RXykNXPUuBS~5EKVeChgNHPSZ4cLmGYtv1-TdPu04iUlSiEtb02EM17Lfm0HDzTOAhDPlusTAIca1yJR9FbD2rFWa-Od80gbjotpDVIMci1KROvzB2G8J98TjLBcK9JqWMFn-KDyALGEY4K9dZpbnELiKYG5xTFV3ZVssBg7CiRKK~QOCbVT0TXuLe9kfjca47bmwl~RFb3a4hYjujRIrAnJC9LuHKlewZ4i7UTvaR4FaOTWn7LF9TtYOiHiJRTwcr3endX~g9Nd-9LeqDE4gFLvBnp5lxteFq0HjzboaGtp~LhbU2ozGZbtxyew__"},{"id":"jhQgXtR9qDq1h2AnPSh8T","name":"src 4.PNG","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/jhQgXtR9qDq1h2AnPSh8T/src%204.PNG?versionId=Ek8KY7bLRr4SD81zYPg18VvYU7nHxODm&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=Xcuq6NQbDCZapxFEN-8dDXIvXjaByd0wehXbNo~W3hMPB9l0~j33F1X6kA5GjMH-Qk73gmSKRVv3Q2jX1K4~cj9SBOdf~0uv2B7bBvllJd67DkM8ABzezgNM~vP0FCxsKKX45c1al~lx2P~YrEnC0PWq0KGheucgmp1zlkf6xOo9mYf8DXi5xkV4IeyRycrFMBhDURTlW2q4OqBlIfqnCrSlfO0OtjndOTNk0tNvcqo0Ab1DFSTJV9Nc6B03d1c1sD4VsXbpfj5~NEVeQ28h39inmqpWq0xN9yKzfqeiMWCMFCBL2uPG43eakQLSDv5RimgF4w829pPme8rJkEnV2A__"},{"id":"DqejKXXBvzQBkWo9nk3cx","name":"src 5.PNG","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/DqejKXXBvzQBkWo9nk3cx/src%205.PNG?versionId=KMZcCRdJevxM8170.jnWpZPw3neeCjuY&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=XXADmIDNpv2kmdiFhUuPnuzkUklEj0ePGkq1~NEVeHNa7un9PHfKgxNrI9iB-VgAGdsDVMuLL3DpjlPTG1TGU6uGfrqAh4y7noVRKNUVeGL1e0nf5Zv3VmqzdKDmG0EO5LkdWk9POMk7Jz6r1j1zKr-j~bbB001slbGmgE-26vvmPrMNOidsnJvL51CcmBhUyxIZOg1v0PrL4jWFDOphLXRRB1iAdHclzUOy2xf7c-TyS3JUilxaRU0D5mWPo8-AgOpQJfrzGpcf99JaDQdRh04GeuVXgKIQ8g2Ywb2hc7gUuh--h7602KrnaYREilW4OWyBkezOLZFwAKAQh3rWxA__"},{"id":"x0wWBJpN8KTpkJUvMvaym","name":"Multi-Agent-Research-Evidence-Based-Report-Generator-main.zip","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/x0wWBJpN8KTpkJUvMvaym/Multi-Agent-Research-Evidence-Based-Report-Generator-main.zip?versionId=9zH4dbVHkfogRMdp7JfFuexsMMmLx2Qi&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=jXm1Fl-Y5sWC1RsQX6q86vM-IBYw0UM8BvMYZ7qX1UdLInBhUZT2bfRfkoOeALBDn6~Cs5nF646CqN1caeBJIylACNnIUQfecyaVwmq5umHkiVEKxS1LhNfRTB5u4olYDjXFyJPXMjH7~X8fcWB1CFZVbTG1RSW7EmEY1WrtvYu6HJzAV9wsTpkipD~3l16HxFYIbXT7mA7lltBGh5j8z9R4wL6VA72aOG6yKMAmR83wvATKsfnX8MZGCW6UJabwSwS~iF2XCeDDc-u-rSKQUHvQZNDIgaaTql2cU3j0eSPV8mTjezSpQcQzMrDH17ODxtRXGYGWeZSASsxvRtGi3w__"},{"id":"C8ECk8pIEBNy7H9nOYJgo","name":"image.jpg","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/C8ECk8pIEBNy7H9nOYJgo/image.jpg?versionId=kMojC6GusSW.YEa6dlZup9uEXiNrkylz&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=ofrZO-UDt~S-xUPS4hec-D2485Yv8jH9XzlO0uNpUlvMzhg~TKVZFu-Ie2gr0Tbz-7HJoRZ8pR-mBuq9pt41e9xXUxiXqIADIeW8XtUJsefN9rQVebo3o3JLgGNWAMif1lcxslRWvad6uoVcykBzslS~A2RDprqqJyfEjc0vVFWgCiu~3tE0N1LOnldldtQf4JGYVMm8HgrEEa3LU4zVIGCEa6xr0go2w0pfKUXEOyK5xUsT1gn-n6YluaCAulWWhwlMjRi2aaFXgs8jfCao8C~W~~3S51EWpPSRPn1YRDAdmr-Fc5wDfhwag3CvdaCE0hsWPXDj8JwRnTvVOKDrEw__"},{"id":"41B2Fgwv1Z2TWlJLs34dI","name":"cover photo.png","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/41B2Fgwv1Z2TWlJLs34dI/cover%20photo.png?versionId=fqOKN2gz4DEM2rBZBZ.BDElhqt1s8T8p&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=jaxh2ZEDPSmRpvGjVD2Vq6uFzsbpFqx2tViCS4VyzgFah04urCmt5fWhqrE3qZAotbXsmco0sPJia4onD6RhK3IZ~ivbWXS0ix1Y-6nJVPYW2AbTLpG6qEKbKcWir8rO20j92-BL~HxsBM09KPqOO~i0dpF9xa0nmfoDGMeKhwhw9LK9DU5KLpVRAb~4A85nG822J8DxPzEnJzxa717AuSQ5WMNXM1UyQ4~l3IJDWXjhfUmDA66fQ2XR7S2C8P4eUN6HGFo~aWXHC1xoVwof97YG6N5HLUKmOqOqUJramRifsaHESgFuamVtuHPMuu59nmuvSJSnKrutNl5F-P8M1Q__"},{"id":"HMS2a6qjf947qbeG3o5IP","name":"resercher-graph.png","url":"https://app-cdn.readytensor.ai/publications/1GiH57XcQCHz/files/HMS2a6qjf947qbeG3o5IP/resercher-graph.png?versionId=S59Bm54zZglBbtGWcKg32Qu7vYbXnEj_&Expires=1788926992&Key-Pair-Id=K3EVG0QTJR4SK0&Signature=BKc6YHKkbBwMmeDtdQmQdVBavbH48~m0rERy3xxHYuxrFOXWhG3D7dYnv~Tu6xhTYpdI21GVGx0K8I60Go1zJ0XdA19g5BQ~nii7Eneew2-FadT0VZWS3GazMLEdTCqRqjJDRJCzG6UHOA4ZeEvosk663PgeO3RJ~X~3GdFEKMMgBrjPuS93TZqkJGp-96b23luCIaQniMXgB5rB~LC1MKsFRQhNr67nViAHPjHIDYRf4aeWW6l4sfMFW7kd7wimNifCQbr2duYTrCtlVnJ4FqmvPSMWNmQkvQZ-PKPODSyHVW2lT4I4ZMYVHym0N4ACc1wesVuRSn4LuvQCxCSb~A__"}],"is_flagged":false,"is_completed_program_submission":true}]}]}]]}]]}]