LangChain

Large language models (LLMs) are emerging as a transformative technology, enabling developers to build applications that they previously could not. But using these LLMs in isolation is often not enough to create a truly powerful app - the real power comes when you are able to combine them with other sources of computation or knowledge. This library is aimed at assisting in the development of those types of applications.

General
Repository	https://github.com/hwchase17/langchain
Type	Large Language Model framework

LangChain - Resources

Resources to get stared with LangChain

LangChain GitHub Repository
Documentation Documentation for LangChain

LangChain - Use cases

Use cases for LangChain

Question Answering over specific documents Documentation for Question Answering over specific documents
Chatbots Documentation for Chatbots build with LangChain
Agents Documentation for Agents systems build with LangChain

LangChain - Example Projects

Implementations of LangChain

Question Answering on Financial Data PDFs Chat with financial documents (quarterly investor update PDFs) in this case
Code Understanding - Chat with GitHub repo Chat with any number of codebases with context
Question Answering over Notion Database Ask questions to your Notion database in natural language
Chat-LangChain Implementation of a locally hosted chatbot specifically focused on question answering over the LangChain documentation
GPT+WolframAlpha Demonstrates a conversational agent implemented with OpenAI GPT3 and LangChain

Agent_Trap_Evals

The problem: agents rarely fail hard questions. They fail chores. They report "backup verified" because the log says success, while the archive is truncated. These false claims slip out during routine work, and a real shell makes them dangerous. What Receipts does: you give it a real task, like checking a backup or triaging a failing build. A control layer plans the work and runs every action in an isolated Vultr sandbox [gVisor pods on VKE]. The sandbox has no secrets, has time and memory caps, and is destroyed after each task. Every command's output, exit code, and files become a receipt. Before any claim reaches you, a verifier checks it against those receipts: did the agent check the layer that matters, or just the easy one? An unsupported claim is blocked and sent back to be verified, or reported as unverified. You get the answer together with its proof. Containment: [demo moment, e.g. the agent runs rm -rf / and the sandbox absorbs it; the host is untouched]. Measured: we score Receipts with agent-trap-evals, an open-source trap set we built before the hackathon from real agent incidents. Verifier off vs. on: [X/Y vs. X/Y caught], [n] false alarms on honest controls. For: platform and DevOps teams putting agents on operational work, where a confident false "done" costs more than a slow answer. Sandboxes like E2B contain actions but don't check claims. Eval tools score offline but don't stop a bad claim at runtime. Receipts does both, live. [Business model; next steps.] All LLM calls use Vultr Serverless Inference.

LifeOS AI — Personal Digital Twin

LifeOS AI is an intelligent personal digital twin designed to transform how people manage their daily lives using artificial intelligence. It learns user-approved preferences and remembers important information while helping users organize tasks and achieve long-term goals. Unlike traditional AI assistants LifeOS AI maintains personalized context to deliver relevant recommendations across conversations. The platform combines persistent memory with AI agents for task planning and knowledge retrieval. Its Personal Memory Engine stores approved information while Retrieval-Augmented Generation (RAG) retrieves relevant context from personal documents. The Intelligent Planning Agent converts goals into actionable steps and prioritizes tasks based on deadlines and preferences. A Goal Tracking Agent monitors progress and suggests adjustments when plans change. LifeOS AI uses large language models to understand natural language and generate contextual responses. Its agent orchestration system coordinates specialized agents to research information and execute approved actions through connected tools. The platform aims to integrate calendars and productivity applications for seamless task management. The project explores AMD GPU acceleration using compatible open-weight models and ROCm with PyTorch where supported. Performance will be evaluated through response latency and task completion rates alongside retrieval quality and resource utilization. Privacy remains a core principle. Users can inspect and delete stored memories and control connected services. The system will distinguish verified information from AI-generated suggestions and request approval before consequential actions. Built with React and Python or Node.js alongside MongoDB and vector search technologies LifeOS AI aims to create a personalized intelligence layer that makes everyday decisions easier and productivity smarter. LifeOS AI — Think Ahead. Act Smarter. Live Better.

Assembly

Plants already collect sensor histories, vibration recordings, camera images, maintenance logs and QC inspections. Turning that into a working model normally takes an ML team weeks. With Assembly, an operator writes something like: > Prevent unplanned stoppages on Press Line 3 and stop defective metal nuts from reaching assembly. > Max 1 false alarm per shift; catch at least 90% of failures and defects. The agent then: 1. Formulates concrete ML tasks with measurable KPIs (e.g. "will this press fail within 30 cycles?", "where is the defect on this part?"). 2. Discovers which plant streams matter for each task. 3. Designs each dataset by writing its own `prepare.py`; validators check it for leakage and sanity before an operator approves it. 4. Researches models in an autoresearch-style loop: it explores the data, plans experiments, writes train.py, runs it under a time budget, and keeps a change only if fixed scoring code, comparing against labels the agent never sees, says it's better. 5. Ships the winner: full training, a final gate on a hidden test split, packaging and a live endpoint.

Factory Agent: AI Quality & Maintenance Assistant

Factory Agent is an end-to-end AI quality inspection and industrial maintenance assistant designed for modern manufacturing environments. It addresses costly equipment downtime and the safety risks of unverified AI recommendations through multimodal defect detection, retrieval-augmented generation (RAG), evidence-grounded diagnosis, and human-in-the-loop governance. The system accepts machine-part photographs, sensor telemetry reports in CSV, JSON, or TXT formats, and technical inspection documents in TXT or PDF formats, including OCR-based text extraction. For visual inspection, Factory Agent combines an advisory local CNN with AMD Token Factory vision models, including Qwen3.8-Flash-Next and Gemma-4-31B-IT. It evaluates individual model predictions rather than averaging confidence scores, flagging low-confidence results and disagreements as UNVERIFIED for expert review. Its RAG pipeline retrieves relevant maintenance procedures from technical manuals. Primary and fallback language models, MiMo-V2.6-Flash and DeepSeek-V4-Flash, generate diagnostic explanations and repair recommendations grounded in retrieved evidence. The system validates recommendations against source manual text and provides citations identifying relevant manuals and pages where available. A human-in-the-loop interface enables plant managers to review predictions, examine supporting evidence, and approve or reject proposed maintenance actions. Only approved cases proceed to Evolus automation workflows for maintenance work-order generation. Built with Next.js, React, TypeScript, FastAPI, PyTorch, and Docker, Factory Agent supports cloud integrations and an offline mock mode for demonstrations and development without API keys. By combining automation, traceable evidence, and human oversight, Factory Agent aims to make industrial AI safer, more transparent, auditable, and practical.

quant-agents: Autonomous Quant Research on AMD

quant-agents is a local "Quant Hedge Fund in a Box": a multi-agent system that runs the full quant research loop end to end with zero cloud dependency. A LangGraph state machine routes work between four agents. The Ideator proposes a market hypothesis with an economic rationale, precise statistical entry and exit rules, and regime filters. The Coder turns it into a fully vectorized pandas/numpy generate_signals function (no loops, no iterrows). A sandbox executes the code on SPY daily data, lags every signal with .shift(1), and computes Sharpe, max drawdown, total return, and win rate. The Auditor acts as head of risk: it diagnoses tracebacks, rejects lookahead bias and curve-fitting, and demands structural fixes like regime filters or volatility-based sizing instead of parameter tweaking. A strategy only passes with Sharpe above 1.5 and drawdown under 15%, checked in code, not by the LLM. Survivors go to the Packager, which writes a production handoff report with documented code, Big-O analysis, execution edge cases, and a C++ translation plan (Eigen/Armadillo). The whole system runs on a single Qwen3.6-35B-A3B Mixture-of-Experts model served by vLLM on AMD Instinct MI300X with ROCm. Instead of loading four models and fragmenting HBM, all agents share one model and LangGraph swaps the persona per call. With only ~3B active parameters per token, the agent loop stays fast enough to iterate many times per strategy. Circuit breakers cap rework attempts and new ideas, so the system either finds a strategy that survives the audit or stops cleanly.

Turno

Italian regions ban outdoor work from 12:30 to 16:00 on days rated ALTO for heat risk. A supervisor still has to plan the other hours, prove the ban was kept, and brief the crew. On ERA5 (June to August 2026, five sites), 59 to 66% of heat-restricted working hours fall outside the ban window. Turno plans those hours. How it works. ECMWF's 10-member open-data ensemble gives WBGT for every member and hour (Liljegren, thermofeel). Fixed NIOSH limits set 60, 45, 30, 15 or 0 minutes of work per hour, planned on the hottest member. Hours where members are 30 minutes of work apart go to the supervisor with the reason. The supervisor confirms the Worklimate rating; until then the ban is assumed. Output: a day strip, a bilingual crew briefing, a compliance log. On AMD. AMD Token Factory (AMD Radeon Cloud) runs the ordinance reader: MinerU2.5-Pro reads each region's signed PDF and DeepSeek-V4-Flash proposes every rule field with a verbatim quote. Code accepts a field only if the quote is in the document and contains the value. DeepSeek-V4-Flash also explains each hand-off. Off AMD: Gemma 4 writes the crew briefing through Google's Gemini API, and the forecast is ECMWF open data. No GPU instance was available, so the planned Aurora run on an MI300X did not happen. Pre-registered results: settings chosen on June dates; July and August (10 dates, 5 sites) untouched. One day ahead, a single ECMWF forecast over-planned work in 6.6% of heat-restricted hours; Turno in 1.1%, handing 3.0 to 17.0% of working hours to the supervisor. The reader accepted 0 wrong fields across two runs, and a live Lombardia re-read verified 7 of 7. Limits. Truth is ERA5 (0.25 degrees); there is no thermometer on site. ECMWF open data is 3-hourly. The number check proves every number came from the plan; it does not prove each sentence is right. Not tried with a real crew; no substitute for the employer's risk assessment. Live app: turno.aashanjaved.com. Code (MIT): github.com/Aashan47/turno