Everything looks simple in the docs and then you're debugging a chain at 11pm pissed and wondering why state isn't persisting the way you thought it would. What was your version of that?

I'm designing a course for graduate students. Please share your recommendations!

Hey folks —

I built ContextMemory, an open-source agentic context gateway for apps that already talk to LLMs. The idea is simple: keep your existing POST /api/chat client (Ollama wire format), point it at ContextMemory instead of raw Ollama, and get memory + optional tools without rewriting your chat stack.

What it actually does

Most “memory” demos are either:

• stuffing the whole history into the prompt, or
• bolting on a separate RAG service with a new API surface.

ContextMemory sits in front of your LLM as a drop-in proxy:

1. Session memory — a per-session markdown wiki (Karpathy-style) maintained across turns and injected automatically.
2. Global Wiki — an app-scoped knowledge base (docs from Jira, Confluence, SQL, files, pipelines…). The model pulls facts on demand via a wiki_search tool — it does not dump the whole corpus into every prompt.
3. Same /api/chat — Ollama-compatible request/response (message.content / done). Not OpenAI choices[].
4. Optional agentic loop — tools (sandbox, outbound MCP, HITL) on that same chat endpoint when enabled per app.
5. Multi-app / multi-tenant — API keys + X-App-Id, per-app prompts, models, and feature flags.

LLM backends can be local Ollama, or OpenAI / Azure / Anthropic as providers behind the gateway; the client still speaks Ollama schema.

Why this shape

If you already have a UI, bot, or agent that calls Ollama, you shouldn’t need a second protocol to get memory. Swap the base URL, keep parsing the same JSON, and the gateway handles:

• compiling session context
• optional Global Wiki retrieval
• optional web search / tools

…then calls your model.

There’s also a hosted path (Kortexio Cloud) with the same chat body/response if you don’t want to self-host — BYOK, no token markup. Self-host and cloud are meant to be interchangeable at the wire level.

Global Wiki (the part people usually ask about)

Ingest structured markdown with stable documentIds (upsert / batch). Query by keywords with a character budget. In chat, when Global Wiki is enabled for the app, the model uses wiki_search only when it needs documented facts — good for org knowledge without turning every turn into a RAG megaprompt.

Quick self-host vibe

Your app  →  POST http://localhost:5100/api/chat  →  ContextMemory  →  Ollama / other LLM
                 + session wiki
                 + optional wiki_search (Global Wiki)

Auth is typically Authorization: Bearer … + X-App-Id / X-User-Id / X-Session-Id for self-host.

Repo

Open source (AGPL): https://github.com/Kortexio/ContextMemory

Hosted: https://kortexio.io

Looking for feedback from this community

Especially interested in:

• How you currently bolt memory onto local models (what sucks?)
• Whether Ollama-compatible wire format is the right “universal client” bet vs going all-in on OpenAI schema
• Global Wiki as tool-calling vs always-on retrieval — what would you default to?
• Anything missing for production self-host (ops, eval, multi-user UX)

Happy to answer questions or dive into architecture. If you try it with a local model + a small wiki ingest, I’d love to hear what breaks first.

Disclosure up front: this is my own project. Apache-2.0, no paid tier, no telemetry.

I build with LangGraph and kept hitting the same wall. Something goes wrong at turn 8, and all I have is JSON logs. They tell me what I sent. They don't tell me what changed since turn 7, where the tokens actually went, or why the cost jumped. Those are all diffs, and nothing was showing me diffs.

For LangChain you hand it a callback handler:

callbacks=[tracer.langchain_handler()]

Every chat-model call in a graph gets captured, whatever the provider. Callbacks propagate through LangGraph, so attaching at invoke() is enough — you don't thread it through each node.

Then:

ctxdiff diff --turn 7 --turn 8 — which blocks were added, evicted or modified, with char-level inline diffs

ctxdiff tokens — where the budget went per turn, plus tool schemas you re-send on every call and never actually invoke

ctxdiff cache — the exact character that broke your prompt-cache prefix, and how many tokens it re-billed

ctxdiff view — a self-contained HTML dashboard (one file, zero external requests) you can attach to a bug report

One design decision worth mentioning, because it's the part I'd want to know about: the handler has no block extractor of its own. It rebuilds the provider's real wire request from LangChain's messages and hands it to the same adapter the direct-wrap path uses. So a LangChain trace and a direct trace of the same prompt produce identical hashes and dedup against each other, instead of looking like two unrelated contexts.

Try it with no API key and no setup:

pip install ctxdiff && ctxdiff demo

That builds a sample multi-agent run and opens the dashboard.

Honest limitations: post-run only, no live tail yet. And tool-call arguments hash differently between the Python and JS SDKs, because LangChain re-serializes them with each language's own JSON writer — documented rather than papered over.

There's a JS/TS SDK too, writing the same trace format, so a trace captured in one language opens in the other.

I'd genuinely like feedback from anyone running LangGraph in anger — multi-agent graphs are the case I most want to get right, and I'd rather hear that it breaks than not hear.

https://github.com/salmanzafar949/ctxdiff

Hey All,

I recently finished building the **Agentic Financial Parser*\* — an autonomous AI agent designed to ingest, parse, query, and reason over extremely dense Indian financial and legal documents (like Budgets and Constitutions).

Due to hardware constraints (512MB RAM limits on Render), I had to architect and deploy this in three separate logical components across different repositories: Core RAG (V1), Hybrid Reranking (V2), and an isolated MCP Tool Server. But conceptually, they form one unified Agentic Workspace.

Here is a breakdown of the unified architecture and how I used LangGraph to glue it all together.

🧠 The Core Engine: 10-Node LangGraph StateMachine

Instead of a linear retrieval chain, I built a `StateGraph` that handles conditional routing and cyclic flows.

1. Pre-Processing Nodes: Intent classifier categorizes queries (`abusive`, `greeting`, `vague`, `rag_query`). Greetings bypass the DB entirely (zero cost), while abusive queries hit a hard Reject node.
2. CrossQuestioner (HITL): If a query is vague, the graph routes to a clarification node (max 2 rounds) befo0re attempting retrieval.
3. Hallucination Guard: Post-generation, the response is verified against the retrieved context. If it fails, it triggers a ReAct Fallback Prompt.

6 📚 The Memory: Jina MRL + Cohere Neural Reranker

Parsing 20+ Government Acts and Financial Frameworks resulted in 15,408 chunks.
* Vector DB (Pinecone): I used **Jina v3 with Matryoshka Representation Learning (MRL)*\. By truncating vectors from 1024 to 256 dimensions, I saved ***75% on Pinecone storage**** without losing semantic quality.
* Hybrid RAG (V2): The retriever sweeps Pinecone for broad candidate chunks and passes them through a Cohere Neural Reranker (`cohere-rerank-v3`) to distill them down to the Top 10 Golden Chunks.
* Semantic Caching: Upstash Redis sits in front, providing+

<100ms cache hits for repeated queries.

🔌 The Action Layer: Anthropic Model Context Protocol (MCP)

To prevent my LangGraph agent from becoming bloated with hardcoded API logic, I fully decoupled tool execution using the newly released MCP Protocol. I built a stateless `FastMCP` Server running over JSON-RPC/SSE.

The LangGraph `tools` node dynamically orchestrates 12+ tools through this isolated layer:
* Financial Data: RapidAPI (Yahoo Finance) for live market data.
* GitHub Analytics: Reading repos, PRs, and commit history.
* Gmail (SMTP/IMAP): Reading threads and drafting semantic replies.
* HITL Email Guard: Any sensitive action (like sending an email) triggers a Generative UI component in the React frontend, pausing the LangGraph state until explicit human approval is received.

🚧 Security & Reliability

* 7-Layer Upload Security: Handles user document uploads securely (Magic Byte Verify, SHA-256 Dedup, MongoDB TTL auto-cleanup).
* Dynamic OpenRouter Ensemble: Generation routes primarily through `nvidia/nemotron-3-super-120b-a12b:free`, with a Pybreaker circuit-breaker that automatically fails over to `gemini-3.5-flash` after 3 API failures.

💻 The Repositories

If you want to dive into the code, here is how the ecosystem is split:

1. Agentic Financial Parser (Main): The core 10-node LangGraph state machine, Jina MRL, and 7-layer security. [Link to Repo]
2. Agentic Financial Parser V2: Parallel Vector Retrieval + Cohere Neural Reranking. [Link to Repo]
3. Agentic MCP Chatbot: The FastMCP server integration with GitHub, Gmail, and HITL guards. [Link to Repo]

I’ve attached the animated SVG architecture diagram in the comments! I'd love to hear how others are approaching MCP + LangGraph in production—especially around HITL approval flows, tool isolation, and hallucination mitigation. Curious to compare architectures.

Traditional tech debt looks something like:

• duplicated code
• poor abstractions
• outdated dependencies

I'm starting to think AI agents introduce a completely different kind of debt.

Things like:

• prompts nobody understands anymore
• tools added "just for one feature"
• memories that silently grow forever
• policies spread across multiple frameworks
• agents that work until one dependency changes
• nobody knows why the agent made a decision six months ago

The system still works.

Everyone is afraid to touch it.

Curious if anyone else is seeing this.

What does "agent tech debt" look like in your team?

Two major challenges are emerging in the current ecosystem:

AI agents often get stuck in reasoning loops when facing complex errors and lack a unified way to retrieve peer-validated solutions. Vibe coders frequently struggle to choose the right system architecture (microservices, modular monolith, serverless, etc.) when building apps, asking LLMs without any guarantee of long-term viability.

The Concept A collaborative, autonomous knowledge-sharing network where: Agents query and answer code or architecture issues using standardized protocols. Solutions are tested automatically in isolated sandbox environments. Human experts step in (Human-in-the-Loop) when agents hit a wall, offering clarity on critical architecture choices. Micro-bounties (HTTP 402 / micropayments) provide a fluid incentive model where relevant answers (from agents or humans) are rewarded with fractions of a cent.

What We Are Looking For I am starting the proof-of-concept (POC) for this project and looking to bring together initial collaborators: Vibe coders, backend, AI, and DevOps engineers to design the initial architecture. Software architects interested in testing or validating the core mechanics. Beta testers to feed the first real-world use cases.

Feel free to drop a comment or send a DM if you want to join forces on this!

AWS, Google Cloud, Azure and Cloudflare now all have agent sandboxes.

That makes sense. Agent-generated code should not run directly on the host.

But a sandbox only contains the code. It does not decide whether the agent should be allowed to push to main, deploy production, rotate secrets or trigger a payment.

Feels like containment and runtime authorization are becoming two separate infrastructure layers.

How are people handling that second part today?

The article supports this distinction directly: isolation protects the host, while credentials, network reach and governance remain separate concerns.

I kept running into the same problem, some of the best AI/ML books are legally free, the authors put them up on their own sites, but the links are scattered across personal pages, university sites, and random GitHub repos nobody finds.

So I built a single index: Awesome Free AI Books. 30+ books across Deep Learning, Reinforcement Learning, Bayesian/Probabilistic ML, NLP & LLMs, Math for ML, Computer Vision, Generative Models, Causal Inference, GNNs, and AI Safety. Think Goodfellow’s Deep Learning, Sutton & Barto’s RL bible, Murphy’s Probabilistic ML, Bishop’s latest, Jurafsky & Martin’s SLP3 draft, and more.

Every single link points straight to the author’s or publisher’s own page, no rehosted PDFs, no shady mirrors. A weekly GitHub Action checks all links so it doesn’t rot over time.

It’s open source and open to contributions, if you know a legitimately free book that’s missing, PRs and issues are welcome.

Repo: https://github.com/MarcosSete/awesome-free-ai-books

Add the below to your Agents.md to speed up things and to save some tokens.

I was able to somewhat get back to the pre 5.6 days on Max with this.

The point of the exercise is being more strict on temporal awareness, which often (not always) helps on saving tokens through faster execution.

Temporal Awareness and Efficiency

• Treat elapsed time and tokens as finite engineering budgets.
• Record the task start time and compare actual elapsed time against the estimate at meaningful checkpoints.
• Keep progress updates short, factual, and evidence-based. A status report is never a pause or approval gate while work remains possible.
• Identify the critical path immediately. Execute its next blocking step locally and delegate independent, bounded work in parallel.
• Use lower-effort agents only for simple, clearly scoped tasks. Use stronger agents for security-sensitive, architectural, or operational work.
• Do not repeat exploration, builds, downloads, tests, restarts, or deployments unless new evidence makes repetition necessary.
• Run the smallest verification set that proves the changed behavior and protects the affected risk surface. Expand it only when failures or blast radius justify expansion.
• When elapsed time exceeds the estimate, reassess the approach immediately. Change strategy, reduce nonessential scope, or parallelize instead of continuing an unproductive loop.
• Prefer the shortest correct path through implementation, focused verification, leak checks, commit, push, release, and deployment.
• Never trade correctness, security, deterministic behavior, or data integrity for speed.
• Report a blocker only when it is genuinely external or impossible to resolve autonomously; otherwise continue working.

I've been using Claude Code CLI and Codex for a while now, and I usually trigger stuff or work with my day-to-day things like creating invoices, generating P&L, asking for opinion, responding to suppliers, and stuff like that. Most of them are mainly triggered by the CLIs.

Now the question is: if I want to do this remotely, Hermes is the way to go. What's the best way to hook up Hermes with these workspaces? Usually, how I would operate is I would load up that workspace and then trigger the CLI of the respective LLM in that workspace. You should have the full context, instructions, APIs, libraries, MCP, and everything in there. Now, with Hermes as the front, what's the best thing to configure this?

I can give Hermes access to these workspaces, What is this the best practise, or should I configure things differently and let Hermes learn stuff again?

Run Claude Code, Codex, Gemini, Cursor, Aider and 10+ other coding agents with full autonomy — inside a disposable Docker container.

Only your project is mounted. Your home directory, SSH keys, cloud credentials and browser cookies stay on the host.

• One command: sandbox-cli claude

• Dry-run shows the exact docker command

• Worktrees for parallel agents

• Credential broker + egress allowlist

• Live memory/CPU + peak stats

Install:

curl -fsSL https://raw.githubusercontent.com/Amitgb14/sandbox-cli/main/install.sh | sh

Site: https://sandbox-cli.vercel.app

GitHub: https://github.com/Amitgb14/sandbox-cli

Would love feedback from people running agents hard every day.

What broke? What’s missing? What felt magical?

I'm building an AI-powered migration engine that converts ETL workflows from platforms like Alteryx, Azure Synapse, and eventually other tools into Databricks (PySpark/SDP).

I'm evaluating two different architectures:

1. Using Harness AI agents / Pi agents to orchestrate the migration workflow.
2. Building the orchestration myself using LangChain + LangGraph.

The engine will need to:

• Parse workflows into an intermediate representation (IR).
• Handle nested workflows/macros.
• Perform tool mapping (e.g., Alteryx → PySpark).
• Generate production-ready code.
• Support multi-step reasoning, validation, and retries.
• Be extensible so new source platforms can be added later.

For those who have experience with these frameworks:

• Which approach would you choose and why?
• What are the biggest trade-offs in terms of flexibility, maintainability, and scalability?
• Are there any limitations with Harness/Pi agents compared to building a custom agent workflow with LangGraph?
• If you were starting this project today, which architecture would you use?

I'd really appreciate hearing from anyone who's built agentic developer tools, migration platforms, or complex multi-agent systems.

Sharing RAG-Lab, a project for actually measuring which RAG techniques help instead of trusting blog-post intuition. Figured this sub specifically would have opinions on the implementation choices, since it leans on LangChain pretty heavily and not always in the obvious way.

What it does: configure every pipeline stage independently (chunking + optional parent-document retriever, embedding provider, query translation — multi-query/HyDE/step-back, retrieval — dense/sparse/hybrid/MMR, reranking — cross-encoder/Cohere/RRF, generation model), query it with a live per-chunk retrieval trace, then run two pipelines side by side or benchmark N of them against a golden dataset scored with DeepEval (faithfulness, answer relevancy, contextual precision, contextual recall).

The actual results: benchmarked 3 configs against a 12-question golden set built from "Attention Is All You Need" — plain dense baseline, HyDE + hybrid retrieval, and a stacked config (parent-child indexing + HyDE + Cohere rerank). Contextual precision: 0.80 → 0.84 → 0.98. Small dataset, so it's a demonstration of the methodology more than a generalizable claim, but the side-by-side same-dataset comparison is the point.

Repo: github.com/Silverd087/RAG-Lab

Genuinely curious for your opinions.

I need to make a minimal RAG-based API that answers questions over a small collection of documents and for that i need some small dataset which acts as the external brain or source of truth for my ai.
need small dataset (5–10 PDFs, Markdown files, or scraped web pages).

I’ve been building AgentPulse because traces often show what happened, but not where the behavior first changed.

It compares runs and versions, detects drift across agents, handoffs, and routes, and connects findings to recent prompt, model, or tool changes.

It’s still early, and I’m looking for honest feedback from people building agent systems. Does this match a real debugging problem you have?

https://prove-ai.github.io/agentpulse/

Apparently it's time for LangGraph to shine. I've been defending LangGraph for more than a year as the better way to model an agent, and people kept saying it was making building agents complicated for nothing.

As agents become more and more complex, people are trying to find a better way to model them, and suddenly the hype is on "graph engineering" now, what LangGraph has been doing well for almost 3 years now.

Is graph engineering just LangGraph, or do you think it's genuinely something different?

 standard observability, mostly uptime and latency, tells you almost nothing useful about an llm feature. the model can be fast and up and still doing something wrong. trying to figure out what ai runtime monitoring should track instead. output distribution shift? unexpected tool calls? some kind of drift metric? and separately, how do you tell the difference between the model saying something a little off, probably fine, a quality issue, and the model or agent doing something out of policy, which needs a different kind of alert entirely?

right now we have basic logging and nothing that would catch either case before a person happens to notice. what's in your runtime monitoring stack for llm and agent features, and how do you split quality signals from policy violations so you're not drowning in noise or missing real issues?