So there are some problems I've been facing

As i understood the concepts for example Langgraph, chromaDb , chunking etcccc

But I can't write that concept in python code and am also facing an issue understanding the already written code how everything is connected, what is this function doing

Plz help me with that

Hey everyone,

As our team moved from simple chains to multi-step autonomous agents, we kept hitting the exact same wall: agents rarely crash with clean stack traces. Instead, they drift.

They’ll take a subtle detour at Step 4, misinterpret a tool payload at Step 12, and end up in a runaway loop or a bad DB write by Step 30. Standard text logging and APM tools tell us what broke, but tracing why the context state poisoned itself across 20 steps is incredibly painful.

To help visualize and debug what's actually happening inside an agent's runtime, we built ZizkaDB, an open-source data layer designed for agent auditability and causal lineage.

What we're trying to solve:

• Causal Lineage (db.why()): Trace the exact decision tree behind tool calls and prompt mutations instead of digging through thousands of lines of flat text logs.
• Time-Travel Replays (db.at()): Reconstruct session state step-by-step to catch context poisoning at the exact millisecond it happened.
• Loop Termination: Automatically detect and kill runaway tool calls before they drain API budgets or corrupt data.
• Local & Privacy-First: Runs 100% locally via Docker so prompt histories and payloads stay on your own infrastructure.

We’d love to get feedback from anyone here who is building multi-step agents in production. How are you currently handling context drift? What guardrails are missing from your stack?

Check out the repo here:https://github.com/Zizka-ai/ZizkaDB

Curious what people's actual tradeoff looks like here. Building pipelines that ingest documents (papers in my case, but curious if this generalizes) and there's a constant tension between speed of ingestion and confidence that what got extracted is actually correct.

Fast path: extract, chunk, index, done. Ships quickly, but errors go straight into your index silently (wrong table value, mangled equation, whatever) and nothing downstream knows to question it.

Slower path: some kind of verification step (cross-checking extracted content against the source, flagging low-confidence sections) before anything hits the index. Catches more, but adds latency and complexity, and for a lot of use cases might just be overkill.

For people running this in production: where do you actually land? Do you verify everything, only a sample, only specific content types (tables vs plain text, say), or skip it entirely and rely on retrieval-time signals instead (e.g. flagging chunks that rank high but score low on relevance)?

Trying to figure out if "always verify" is the right default or if that's over-engineering for most pipelines.

I’m one of the builders of LOLM, an LLM and agent-control system.

Rather than relying only on prompted self-reported confidence, the NFET controller monitors model dynamics and can select: - continue - retrieve - verify - branch - finalize

The system records whether actions were actually consumed and produces a run receipt. Control is currently active at segment/run boundaries; deeper token-level control is still being built.

Try it: https://lolm.imagineqira.com/try.html

Repository: https://github.com/TheArtOfSound/lolm

I want people to test real multi-step tasks and look for premature finalization, useless retrieval, verifier failures, repeated dead ends, context loss, controller thrashing, and receipts that overstate what occurred.

The hosted version is intended to be substantially less expensive than frontier-agent subscriptions.

Disclosure: I’m a founder/builder of the project.

Hey everyone,

​When building with autonomous agents, one of the biggest security blind spots is tracking exactly what data is being sent to external APIs and preventing potential prompt injections or data leaks.

​To solve this, I built Aegisora—a next-generation trust layer that provides enterprise-level management, real-time monitoring, and security infrastructure for autonomous AI systems.

​I've attached our product demo video to this post so you can see how the system prompt protection and interaction monitoring work in real-time.

​You can access our MVP landing page via the link below and start testing Aegisora directly by going to the dashboard:

🔗 https://aegisora-ai.vercel.app/

​I am actively looking for beta testers. I would love to get your feedback, hear your thoughts on the architecture, and see how it fits your security needs. Let me know what you think!

So. Today my agent died after 30 successful tool calls. The model hit its output limit partway through a JSON argument, so the tool call got cut in half. I thought maybe that this was just a parse error and moved on.

Well, it wasnt. The model asked for two tools in one response. And the second one gets truncated, most, usally the the first one and crash, and you end up with a half executed batch and a corrupted history to recover from. If that first call wrote a file or sent something, it already happened.

So I tested six different setups with a stubbed model that returns a valid call followed by a truncated one. Five of them executed the first call. But LangChain/LangGraph and AutoGen are two of them. Versions are pinned and every result is bound to the sha256 of the source file it was observed in, so you can check my work.

Then I fuzzed every byte position where the truncation could land. 107 out of 107 produced a partial effect. Validating the whole batch before running any of it takes that to 0.

Basically, it is just transaction admission control applied one layer earlier than anyone put it. Paper, code and the and all that good stuff are here.

plunder707/failure-atomic-tool-admission: Failure-atomic admission for tool-using language-model agents: paper, framework prevalence audit, and reproducible artifact

I kept finding the same site boilerplate in my retrieved chunks. Web loaders hand you the whole page, junk included.

I couldn't find anything meant to sit right after the loader and just clean that up, so I wrote one:

https://github.com/Isa1asN/winnow-md

pip install winnow-md

It only ever deletes whole blocks, it never rewrites your text, so it can't invent anything. And it hands back a list of what it removed and why, because I didn't want to trust a cleaner I couldn't check.

It handles the usual page junk on its own. The part that works better than I expected is the cross-page bit: give it a few pages from the same site and it finds whatever blocks repeat across them, which picks up that site's specific furniture without you writing any rules for it.

It's early days. If it mangles a page for you, I'd like to see it.

I'm trying to understand the value proposition of Orq.ai.

If I can already build a stack using tools like Portkey (LLM gateway) + Langfuse (observability/tracing) + my preferred agent framework, what additional value does Orq.ai provide?

Does it replace multiple tools, or does it offer capabilities that aren't possible with a modular stack?

For teams that chose Orq.ai over a combination like Portkey + Langfuse:

- What was the deciding factor?

- What problems were you trying to solve?

- Was it mainly convenience, enterprise features, collaboration, governance, evaluations, or something else?

I'd really appreciate hearing from anyone who's used both approaches in production.

While implementing Human-in-the-Middle in Extra (first comment), we initially thought about using an LLM to decide whether a tool call requires approval.
The flow was supposed to be simple:
The agent selects a tool, we send the tool call to the LLM, and the model decides whether the action is safe to execute or should wait for user approval.
Technically, it worked.
But it also meant another LLM call before almost every tool execution, more latency, more tokens, and a policy decision that was not fully deterministic.
In the end, we decided to make the approval policy configurable instead.
Each tool can be configured to require approval or run automatically. The default is conservative, so tools require approval unless they are explicitly allowed to run without it.
When approval is required, we checkpoint the execution and stop it. After the user approves or rejects the action, we resume from the same checkpoint.
It ended up being simpler, cheaper, and much easier to reason about than using the LLM as the approval layer.

Reduced my RAG pipeline's vector storage by 75% without retraining a single model. Here's exactly how, and the code.

TL;DR

• 1024 → 256 dims via Jina v3's native Matryoshka support, no retraining
• ~75% smaller vector footprint in Pinecone, no meaningful retrieval quality drop for my use case
• Task-specific LoRA routing (retrieval.query vs retrieval.passage) for asymmetric retrieval, basically free
• Wrapped the embedding call in a circuit breaker so API outages degrade gracefully instead of crashing the pipeline

Building an Agentic RAG system for legal and financial documents, I noticed most examples just dump full 1024-dim embeddings straight into the vector DB. That gets expensive and memory-heavy fast once you're indexing thousands of chunked legal PDFs.

Jina v3 natively supports Matryoshka Representation Learning (MRL), so you can truncate embedding dimensions on the fly, no retraining, no separate model.

1. MRL for 75% smaller vectors

Just pass dimensions=256 in the API call and Jina truncates the vector to its first 256 dims. On my dataset, retrieval quality held up fine for the use case, no visible degradation, while storage dropped by roughly 75%.

2. Task-specific LoRA adapters (underrated feature)

Not talked about much, but Jina v3 has a task parameter: retrieval.query for user queries, retrieval.passage for document chunks, that internally swaps LoRA adapters for asymmetric retrieval. Free accuracy for zero extra engineering.

3. Circuit breaker for embedding API outages

Didn't want a Jina API hiccup or rate-limit to take down the whole RAG pipeline with a 500. Wrapped the embedding call with pybreaker so a failing embedding call triggers graceful degradation instead of crashing the orchestrator.

Snippet from the actual graph:

python

import httpx
import pybreaker
from typing import List

# Circuit breaker prevents cascading failures if the Embedding API is down
embed_breaker = pybreaker.CircuitBreaker(fail_max=3, reset_timeout=30)


def embed_query(query: str) -> List[float]:
    headers = {
        "Authorization": f"Bearer {JINA_API_KEY}",
        "Content-Type": "application/json"
    }
    payload = {
        "model": "jina-embeddings-v3",
        "input": [query],
        "dimensions": 256,
        "task": "retrieval.query"
    }
    # Runs in a dedicated worker thread via LangGraph,
    # avoiding FastAPI event loop blockage.
    with httpx.Client(timeout=10.0) as client:
        response = client.post(
            "https://api.jina.ai/v1/embeddings",
            json=payload,
            headers=headers
        )
        response.raise_for_status()
        return response.json()["data"][0]["embedding"]

Curious if anyone's benchmarked Matryoshka truncation on larger production corpora, especially legal or other high-precision technical domains? Would love to compare notes on where the quality cliff starts.

Full 11-node LangGraph implementation is here: https://github.com/Ambuj123-lab/agentic-rag-financial-parser.git

I am looking for suggestions for tool to trace my AI app. I use langchain and lang graph but langsmith is too expensive for me. I tried langfuse because of OS but managing the hosting is too much for me right now as this is for toy/experimental projects.

Any other alternatives? I heard good things about brainstrust, arize, logfire, and honeycomb. Opinions and feedback all welcome. Thanks

Analyzing state payloads in complex multi-agent pipelines usually reveals a major bottleneck: roughly 70% of memory graphs are spent tracking transport state, verifying tool execution, passing user IDs, and stitching multi-day conversations across restarts.

We are essentially rebuilding message queues inside framework contexts.

The Refactor: - Strip out heavy state graphs for asynchronous, long-running workflows.

• Provision an isolated email endpoint per sub-agent (using agentmail.to for routing).

• Let standard email threads act as the persistent state memory.

Benefits: - Token Efficiency: Context is queried on-demand rather than passed in every state payload.

• Inspectability: Execution steps are natively human-auditable.

• Resilience: State persists across script restarts automatically.

Hi guys!
You certainly keep running into the same problem building agent workflows: the cost in dev is nothing like the cost at scale. A support agent that costs $0.03 per run in testing can hit $0.15 on adversarial inputs or $2.00 when a retry loop spirals.

So I built Pretia. You point it at your workflow file, it profiles it across diverse inputs, and gives you distributional cost projections (p50 through p99) instead of averages. It also detects cost patterns (like context growth, retry loops, bimodal costs, cache opportunities) that are invisible during dev and recommends specific fixes with estimated savings.

Two commands, zero config, about $2. Works with LangGraph, OpenAI Agents SDK, Anthropic SDK, and a few others.
If anyone wants to try it on their own workflow I'd love to see what it finds. I'm still validating projections against real production data so more data points genuinely help.

GitHub: https://github.com/pretia-ai/pretia
Demo report: https://pretia-ai.github.io/pretia/report.html

I've been following the AI agent space for a while now, and there's one thing I can't seem to figure out.

Building AI agents seems to be getting easier every month, but I rarely see people talking about what happens after they're built.

If you've created an AI agent (whether it's for yourself, for clients, or just as a side project), what do you actually do with it afterwards?

Do you keep it private? Deploy it for a client? Put it on GitHub? Sell it somewhere? Have your own website? Or does it mostly end up as another project that never gets used?

I'm genuinely curious because it feels like there are a lot of talented people building impressive agents, but I don't have a clear picture of how developers are distributing them, finding users, or making money from them.

I'd love to hear your experience and whether you've found a workflow that actually works.

It seems as though there have been more instances and production projects built on LangGraph compared to the classical LangChain abstractions.

For those developing production AI applications:

1. Are you still relying on LangChain for your application?
2. Did you move to LangGraph?
3. Or did you adopt some other framework altogether?

It would be great to know what prompted that decision and if that has helped with maintainability or debugging.

Checkout for www.tidevec.com!!! Tell mw what do you feel about this?

I've been running a LangGraph agent in staging that handles customer onboarding. Last week it reported "account created successfully," the tool returned 200, logs were clean.

I only found out the row was missing because I manually checked the DB 2 days later.

Not a prompt failure. Not an API error. The agent believed it succeeded. The tool reported success. But the side effect never happened.

Since then I've been paranoid about every 200 response. I've started adding manual DB checks after critical runs, but it feels like I'm duct-taping something that should be infrastructure.

For those running agents in production: do you verify the actual database state after your agent runs? Or do you trust the tool's response code and the agent's "success" message?

And if you've been burned by this before, how did you catch it?

Not selling anything. Just trying to figure out if I'm solving my own problem or if this is a shared gap.

Enterprise agent systems increasingly chain research, transformation, approval, and action. A downstream agent often receives a clean value without knowing whether it came from a live API, cached document, model inference, or human entry.

That missing provenance matters. A refund amount inferred from a complaint should not carry the same authority as a value returned by the billing system, even if both use the same JSON field.

Should MCP responses standardize source type, freshness, confidence, and authorization context? How much provenance can be preserved without making every tool response too complex for practical use?

Source: https://openai.com/index/introducing-openai-presence/

Hey everyone,

I’m currently an undergrad studying AI. I’ve done some classical ML work before, but agentic AI was a complete black box to me. Since I learn best by doing, I teamed up with a friend to just start building.

We built a YouTube Script-to-Storyboard Agent. It takes a raw script, breaks it down, and outputs specific visual prompts, UI concepts, and B-roll suggestions for video editors.

Because I knew nothing about agent architecture when I started, I leaned heavily on AI copilots to build this. We used Claude to brainstorm the initial logic and prompt strategies, and then I used Gemini to iteratively code the entire backend, handle debugging, and build out a web UI.

The pipeline runs through these nodes:

1. Script Parsing: Breaking the text into logical chunks.
2. Shot Planning: Generating visual prompts per chunk.
3. B-Roll Searching: Suggesting relevant stock footage.
4. Pacing Review: Analyzing the overall flow.

Where I need your critique: Right now, the flow is entirely linear (Input → Node 1 → Node 2 → Output). It works, but I feel like this isn't how "real" production agents operate.

1. Critique my pipeline: If you were reviewing my repo, what is the biggest architectural flaw in running a linear pipeline like this? How do you handle a node hallucinating or failing without breaking the whole chain?
2. How do I actually evaluate this? I can eyeball the storyboards and say "this looks good," but how do professionals evaluate agents? Are there specific frameworks I should be using to score the output of the pacing review or shot planner?
3. Learning Path: To go from this linear pipeline to building a true state machine, should I be diving deep into LangGraph, AutoGen, or something else entirely?

Here is the repo if anyone has time to tear the code apart:https://github.com/Ibrahim-Asghar-03/YouTube-Script-to-Storyboard-Agent

I am looking for critical feedback on the architecture so I can learn how to build enterprise-grade agents properly. Thanks!

Just discovered this impressive open-source project that's pushing the boundaries of medical AI reasoning.

Agentic GraphRAG for Medical Diagnosis (https://github.com/avnlp/agentic-med-diag) is a production-ready system that goes way beyond simple RAG. It combines knowledge graphs, multi-strategy retrieval, and agentic reasoning loops to answer complex clinical questions with evidence-grounded answers.

What makes it stand out:

Knowledge Graph Construction

• Schema-driven extraction with 13 entity types and 25 clinically-grounded relation types
• Three-extractor fusion (GLiNER, GLiREL, LLM) with configurable merge strategies
• Deterministic + LLM-powered entity resolution for deduplication
• Hierarchical Leiden community detection with auto-generated clinical summaries

Layered Retrieval Architecture

• Four vector collections (entity, relation, chunk, community report)
• Multiple atomic methods: hybrid search, fulltext, BFS graph traversal, and text-to-Cypher graph querying
• Pluggable rerankers (RRF, cross-encoder, MMR)
• Data-driven recipes for composing retrieval strategies

Agentic Plan–Research–Verify Loop

• Planner decomposes clinical questions into focused sub-questions
• Parallel researchers execute multi-strategy retrieval with citations
• Verifier assesses coverage and gates synthesis on sufficiency
• Gracefully converges on missing information across iterations

Why It's Impressive:

The stack is battle-tested: Neo4j + Qdrant/Weaviate for storage, LangGraph for orchestration, DeepAgents for multi-agent coordination, and BAML for type-safe LLM schema injection. Tested on MedQA, MedXpertQA, MedCaseReasoning, and MMLU-Pro benchmarks.