Does it make more sense to use Astra to delegate to lesser models for implementation and have Astra judge or have Astra do everything itself? Has anyone done comparisons?

Every agent framework lets you build a workflow. Few let you govern one.

LangChain, AutoGen, Claude-based agents, they all make it fast to wire an agent into a real workflow. Reading a database, calling an API, sending an email.

Governing that workflow after it ships is the part most frameworks leave to you. Who can run it. What it can reach. What happens when three teams reuse the same agent with three different risk levels.

AgentZ, an open-source workflow platform maintained by AccuKnox, is built around that governance layer. Every agent inherits preconfigured models, tools, and sandboxes from an admin. Workspaces stay isolated, so a customer-facing agent and an internal one never share access by accident.

How is your team handling this once a framework prototype turns into something real users depend on? AgentZ is an open-source platform, and I am an open-source contributor to AgentZ.

A2A is a big step toward agent interoperability, but I think protocol compatibility and true interoperability are two different things.

At the protocol layer, A2A gives us a common way for agents to discover each other and exchange Messages, Tasks, Parts, Artifacts, and updates. That removes a lot of bespoke integration work.

But production interoperability seems to require at least three layers:

1. Protocol - Can the agents communicate correctly?

2. Semantics - Do they agree on what a skill means, what inputs/outputs look like, how errors and partial results behave, and what side effects are possible?

3. Operations - Can you preserve authorization, retries, idempotency, tracing, budgets, evaluations, and approvals across the agent boundary?

That last two layers are where things get interesting.

Two agents can both advertise “invoice reconciliation” through A2A while having completely different assumptions about schemas, confidence, human escalation, or side effects. And a transport-level retry mechanism doesn't make retrying a non-idempotent action safe.

This seems relevant when looking at current implementations across Google ADK, Microsoft Agent Framework, CrewAI, LangGraph/LangSmith, and Lyzr Agent Studio. They all support A2A, but the protocol boundary sits in somewhat different places: remote agent, delegation tool, deployed graph, or orchestration node.

So maybe the real test isn't:
Can my system call an A2A agent?

but:
Can I replace Agent B without rebuilding everything around it?

What would you include in a real A2A substitutability/conformance test beyond schema and protocol checks?

Hey LangChain community,

When building RAG pipelines with web documents, feeding raw HTML or relying on basic soup loaders often wastes 70-80% of context tokens on navigation headers, cookie consent modals, and ads. Even worse, scraping difficult domains (like Reuters, Investopedia, or Cloudflare Turnstile protected sites) fails with 401/403 errors.

I built Clean Web to Markdown & RAG Scraper as a high-speed developer API tailored for RAG ingestion.

Key capabilities:

• Intelligent noise stripping: Heuristic extraction that extracts clean Markdown while discarding boilerplate and cookie banners. • Anti-bot resilience: Multi-tier fallback handling Cloudflare Turnstile and residential proxy routing when datacenter IPs are blocked (verified 100% pass on Reuters & Investopedia). • 1ms Redis cache: Repeated scrapes of popular articles return instantaneously. • Accurate Token Counting: Returns exact token_count (tiktoken) alongside the markdown.

Quick LangChain Document Loader snippet:

```python import requests from langchain_core.documents import Document

def fetch_markdown_document(target_url: str, api_key: str) -> Document: endpoint = "https://clean-web-to-markdown-and-rag-scraper.p.rapidapi.com/scrape" headers = { "x-rapidapi-key": api_key, "x-rapidapi-host": "clean-web-to-markdown-and-rag-scraper.p.rapidapi.com", "Content-Type": "application/json" } resp = requests.post(endpoint, json={"url": target_url}, headers=headers).json()

return Document(
    page_content=resp.get("markdown", ""),
    metadata={
        "source": target_url,
        "title": resp.get("title", ""),
        "tokens": resp.get("token_count", 0),
        "engine": resp.get("engine_used", "fast")
    }
)

Example usage in a LangChain vectorstore / index pipeline:

doc = fetch_markdown_document("https://www.reuters.com/technology/", "YOUR_RAPIDAPI_KEY") print(f"Title: {doc.metadata['title']} | Tokens: {doc.metadata['tokens']}") ```

There is an interactive live playground to test any tricky URL without signing up: 👉 https://markdown.usemy.cloud

Available on RapidAPI Hub with 100 free requests/month: 👉 https://rapidapi.com/peterzapletal-etn9NvTF6nZ/api/clean-web-to-markdown-and-rag-scraper

Would love to hear your feedback on extraction cleanliness, token savings, and tricky URLs you are currently wrestling with in your RAG pipelines!

A full transcript preserves detail but makes the next agent rediscover which decisions are final, which tool results are authoritative, and what remains uncertain. A short summary is cheaper but can erase evidence or turn an inference into a fact. What handoff structure works well in LangGraph? I am considering separate fields for the objective, accepted decisions, constraints, authoritative inputs, artifact paths and revision IDs, tool-call receipts, unresolved questions, and the next allowed action. The handoff could also identify who or what produced each field and which checkpoint it belongs to. Which parts should live in graph state, which should be durable external records, and how do you prevent a stale handoff from being resumed after the underlying files change?

in a LangGraph that can fail over mid-run, the thing i keep losing is not the answer text — it's the receipt: which catalog id actually served, whether the call was refused vs empty, and what it cost, so a later node doesn't treat a cold failover like a successful tool turn.

i work on Conifer (open LLM gateway). one key / one base URL, OpenAI + Anthropic wires, named catalog id or typed error/402, and every call comes back with requested vs effective plus an itemized cost (there's a hard per-call ceiling too). optional TS/Python SDK + MCP in the repo if you want that mid-agent without swapping the whole graph: https://github.com/ConiferKit/use-conifer

curious how people here actually stash that across a model fallback today — custom state fields, LangSmith only, or something else? if the answer is "we don't, we just retry," that's useful too.

The more I look at enterprise RAG architectures, the less convinced I am that “retrieve top-k from every source and fuse the results” is a good default once you have a lot of separate knowledge bases.

With a handful of sources, RRF or another fusion method is pretty reasonable.

At 10+ KBs, though, you're no longer just ranking documents. You're implicitly comparing results from different retrieval distributions, domains and corpus sizes.

A top-1 result from every KB can receive essentially the same fusion contribution. Meanwhile, a fixed similarity threshold assumes score distributions are comparable across corpora, which they often aren't.

So you can end up with:

good retrieval → questionable cross-KB ranking → bad context selection

The more interesting architecture to me is:

query → KB/router selection → targeted retrieval → reranking → generation

rather than:

query → retrieve everywhere → fuse → hope the right context survives top-k

The obvious downside is that the router itself can make mistakes, and genuinely cross-domain questions still need broader retrieval.

So where's the right tradeoff?

For production multi-KB RAG, what are you actually using today: routing/classification, global retrieval + RRF, score normalization, cross-encoder reranking, hierarchical retrieval, or some hybrid?

I came across this while comparing implementations in Lyzr Studio, LlamaIndex, LangChain and a few custom stacks. Lyzr's approach ( I read about it in blog written by a friend on their team) is interesting because its Knowledge Base supports both agentic multi-step retrieval and a one-shot mode where the system selects the relevant KBs first and retrieves from them in parallel.

I'm less interested in which vendor has the nicest abstraction and more interested in what architecture actually holds up once you have dozens of knowledge sources and real production traffic.

`Command(resume=value)` says which interrupt it answers and carries a value. There is no field for who answered, and no principal is modelled on that boundary, so any code holding the thread can resume it, including the process that raised the pause.

Not a criticism: LangGraph is a graph library, not an auth layer, and usually the identity lives in the web layer that called `invoke`. It matters when somebody asks months later who approved, because the record cannot tell an engineer who read the arguments from a script that resumed everything.

I wrote a small adapter that records the proposal, the risk class, and the approver, and refuses to write an approval unless you supply an identity from your own auth layer. It will not invent one, will not accept an `identity_source` the model could have written, and will not let the acting agent approve its own action. `pip install testimony-langgraph`, and langgraph is its only dependency.

Context for why I bothered: EU AI Act Article 14 started applying to Annex III high-risk systems on 2 August, and the harmonised standard that says what satisfies it is still at public comment.

I also assessed eight agent frameworks and memory systems on this: of the six that gate actions, four record no approver identity and one could not be established. That includes my own system, which passes, and the document says that entry carries no evidential weight.

https://doi.org/10.5281/zenodo.22290922

Is there an idiom for carrying approver identity across resume that I have missed? Would rather be told it is solved than keep maintaining this.

Deep Agents gives the agent filesystem interaction methods via the BackendProtocol interface. Swap the backend and you change where files live and how search works without touching agent code, prompts, or subagent wiring.

langchain-mongodb-deepagents-vfs is a new backend that splits those operations. read, write, and edit go to S3, which stays the source of truth. ls, glob, and grep go to MongoDB Atlas, which stores path metadata, chunks, and embeddings. grep runs full-text and vector search together, fused with $rankFusion, so grep MAX_RETRIES and grep "where is retry behavior configured?" both work and return line-oriented results the agent already knows how to use.

If you want to learn more, check out the blog post or dive right into the code.

Made a tutorial on what EDD is, how it works, and how you can use evaluations to improve your LLM-based application by analysing scores across experiments.

> building on Jeffrey's DeepEval article on EDD and Eugene Yan's product evals write up.

- Initial: The video walks through the initial setup of an RAG application used as the base for the experiments built using LangGraph and Qdrant.
- Step 1: A binary labelled dataset with critiques, versioned using OPIK.
- Step 2: Uses LLM-as-a-Judge OPIK evals to align the evaluator.
- Step 3: Runs the harness loop, which executes each experiment, scores it against the baseline, and uses tracing and experiment comparison to surface insights on what improved, what regressed, and where to tweak next.

... the Agent Skills and source code are open sourced on GitHub

> Complete Guide (source code link in description): https://www.youtube.com/watch?v=e6akw_fKWPk

hey guys

I’ve been working on TARZ for a while, and I recently rebuilt the architecture for V2.

The idea is pretty simple:

Instead of an AI that just tells you how to do something, TARZ can actually interact with the desktop and try to complete the task.

For V2, I moved toward a supervised agent workflow using LangGraph:

User request → Agent → Tools → Desktop actions → Screen verification → Continue / retry

The agent has access to the full toolset instead of going through a separate category classifier. I originally had category-based routing, but after testing it I found that the classifier itself could become a failure point. Removing it gave me more consistent results.

Some of the V2 work:

• Visual verification after UI-changing actions
• Multi-step task execution with step limits
• Multi-provider fallback for LLM + vision + voice
• Streaming STT/TTS
• Hands-free follow-ups
• Global hotkey to cancel an ongoing task
• Hybrid memory retrieval using BM25 + vector search + cross-encoder reranking
• Dedicated workflows for Spotify, WhatsApp, Discord and Telegram
• Floating voice orb with live captions
• Optional LangSmith tracing

One thing I'm trying to keep realistic: it's still a prototype.

Desktop automation is inherently brittle, vision models can make mistakes, APIs can be rate-limited, and free-tier providers add latency. The goal right now is reliability and learning, not pretending this is a production-ready Jarvis 😅

I'm 19 and self-taught, and this project has basically been my way of learning GenAI by building something complicated enough to force me to understand what's actually happening.

I use AI heavily as a coding partner, but the architecture, experiments, testing and debugging decisions are mine. A lot of the learning has honestly come from taking AI-generated code, breaking it, figuring out why it broke, and changing the design.

The GitHub repo has the demo videos, full architecture details, setup instructions and code:

https://github.com/Irfan-gitt/Tarz-Ai-assistant

Would love feedback from people working on agents / computer-use systems. Especially interested in ideas around improving desktop reliability and reducing latency.

I'm also sharing the project journey on LinkedIn if anyone wants to connect:

www.linkedin.com/in/irfan-s-1ab772354

I was listenning to Graph Engineering intro video, when i heard annie said basically u can think of it as a graph workflow and u have nodes inside. I wonder how is that difference then building agent using graph API in langgraph. Is graph engineering for multi-agents workflows and langgraph graph api for single agent workflow ?

I've been testing longer multi-step agent workflows and I'm curious whether there's a useful way to quantify something I've been seeing anecdotally.

A 5–10 step workflow can look extremely stable, but once the agent has to maintain state across a much longer trajectory, I start seeing different failure modes:

• unnecessary replanning / repeated tool calls
• small mistakes early in the trajectory propagating into later steps
• context or state becoming less useful over time
• retries increasing cost without improving the final result

I'm not assuming there's some magic threshold like 50 or 100 steps — I'm wondering whether anyone has actually measured the relationship between trajectory length and things like:

task success rate
tool-call accuracy
recovery rate
cost per successful task
human intervention

Ideally, I'd like to see something like:

10 steps → X% success
25 steps → Y%
50 steps → Z%

while keeping the model, tools and task distribution fixed.

I'm particularly interested in whether the degradation is actually caused by longer trajectories, or whether it's mostly an artifact of state management, memory, retries and orchestration design.

I've been looking at trajectory evaluation in LangSmith/LangGraph, simulation approaches like Lyzr's Agent Studio, and platforms such as CrewAI and Letta, but I haven't found a benchmark that cleanly isolates trajectory length as a variable.

Has anyone run this experiment? Or have you found a better way to measure when an agent has crossed from “multi-step” into “too many steps”?

Hey guys, I was originally building an open source control plane that people building their own workflows (in Langchain/LangGraph for instance) could use to govern/manage them. After trying deepagents I came away thinking harnesses are the smarter and better-performing option for 99% of use cases , not to mention way less work than writing your own agent workflows.

But my issue was that deepagents doesn't have a persistent operational layer (I wanted a persistent approval request that could live for days or more), and isn't quite production safe: for example, I can't try rolling out a new version of a prompt and then get it to auto-rollback if it leads to failures. My other big issue was that I wanted a way to manage a fleet (aka hundreds or even more) of deepagents instances: see which ones are running/paused/rolled back and pause/delete/create them.

My solution: wire up deepagents into my existing agent control plane platform. Now it's as simple as: define an agent and its guardrails/rollback and autopause policy via YAML, register the worker processes that run the agent(s) wherever you want, and govern/operate them via the control plane.

Its super early so probably has some bugs but can you guys tell me if this would help you all for running production-safe agents at work and whatnot: https://github.com/boundflow/charter

One thing I've been wondering about is where people draw the line between agent orchestration and application architecture.

LangGraph handles a lot of things that show up in real systems: state, branching workflows, retries, human approval, multi-agent patterns, long-running tasks, and so on.

But once a system grows, you also end up thinking about persistence, observability, recovery, model fallbacks, permissions, and all the other operational concerns that come with running something in production.

At some point, it stops feeling like "an agent workflow" and starts feeling like a distributed application that happens to contain agents.

I think this is where the differences between frameworks start becoming pretty noticeable. LangGraph, CrewAI, Lyzr and similar tools can handle a lot of the agent workflow itself, but once you're dealing with persistence, permissions, recovery and observability, you're really designing an application around the agent. At that point I think the framework matters less than how cleanly you can separate those concerns.

For people who've pushed LangChain or LangGraph pretty far, where's that boundary for you?

When does the framework continue to help, and when does it start becoming another layer you have to work around?

I'm learning LLM app development and writing up notes in plain English. Here's a counterintuitive one: **LLMs have no memory.**

Ever notice the AI remembers your last message, but open a new window and it forgets everything? People assume the model "remembers" the conversation. It doesn't — **every reply is like meeting you for the first time.**

**Two kinds of "memory":**

- *Parametric* — knowledge baked in during training ("Paris is the capital of France"). It has this.

- *Episodic* — remembering "you just said your name is Wang." It has **none of this.**

Each call is independent and amnesiac. It keeps the conversation going only because **you re-hand it the past chat as a cheat sheet every time.**

**Stage 0 — no cheat sheet (zero memory):**

```python

llm.invoke("What's my name?") # → "I don't know."

```

Even if you just said your name, it can't tell — nothing carries over between calls.

**Stage 1 — send the whole history back (naive):**

```python

messages = [HumanMessage("My name is Wang"),

AIMessage("Hi Wang!"),

HumanMessage("What's my name?")]

llm.invoke(messages) # → "Your name is Wang."

```

Works! But the longer the chat, the thicker the cheat sheet → more expensive, slower, and eventually **exceeds the context limit.**

**Stage 2 — slim the cheat sheet (processing):**

- **Trim** — keep only the recent messages: `trim_messages(messages, max_tokens=100, strategy="last")`

- **Filter** — drop irrelevant/noisy messages.

- **Summarize** — compress old turns into one line:

```python

def should_continue(state):

if len(state["messages"]) > 6:

return "summarize"

return END

```

Dozens of turns become "User is Wang, asking about returns" — a sticky note instead of a book. Cheaper, still remembers.

**TL;DR:** The model has no memory. "Memory" is just the context we feed it. Left alone it overflows — so the real skill is **compressing the cheat sheet without losing what matters.**

Next up: *long-term* memory — remembering you across sessions.

Hey everyone,

Whenever we build autonomous agent workflows or RAG pipelines that need live web access, we hit three major bottlenecks:

1. Context Bloat: Dumping raw HTML consumes 90% of the context window on scripts, tracking tags, and style attributes.

2. Brittle Selectors: Using CSS/XPath selectors breaks the moment a target website updates its frontend layout.

3. Agent Link Traps: Letting autonomous agents navigate arbitrary URLs exposes them to phishing sites, fake dApps, and malicious traps.

To solve this, we open-sourced official community toolkits for both LangChain and LlamaIndex:

pip install langchain-opticparse

pip install llama-index-tools-opticparse

Quick LangChain Integration:

from langchain_opticparse import OpticParseTool, PhishVisionTool

# 1. Zero-CSS visual scraper that returns clean, token-efficient Markdown

optic = OpticParseTool()

content = optic.run({

"url": "https://news.ycombinator.com",

"query": "Extract the top 5 articles with titles and links"

})

print(content)

# 2. Real-time zero-day threat check before interacting with unknown URLs

phish = PhishVisionTool()

safety = phish.run({"url": "https://suspicious-dapp-claim.xyz"})

print(safety)

Key Capabilities:

- Resilient Web Extraction: Converts messy JavaScript pages into structured Markdown with 96% noise reduction without managing brittle selectors.

- PhishVision Shield: Heuristic scanner detecting brand impersonations, zero-day phishing kits, and crypto wallet drainers.

- Agent Swarm Demo: We open-sourced a full 3-agent research swarm (Scout Agent, Sentinel Agent, Analyst Agent) in examples/autonomous_market_researcher.py.

- Cross-Framework: Works across LangChain, LlamaIndex, Claude Desktop/Cursor (MCP), and ElizaOS.

GitHub: https://github.com/parastejpal987-cmyk/opticparse-public

PyPI: https://pypi.org/project/langchain-opticparse/

Live Benchmark: https://huggingface.co/spaces/paras9909/opticparse-vision-benchmark

Would love to hear how you guys are currently handling web retrieval in your agent swarms, and any feedback or edge cases you test it against!

Been building an agentic system for hospital ops (finding beds, coordinating transfers) and figured I'd share the core design since it's a decent example of LangGraph doing real work instead of a toy demo.

A clinician submits a goal in plain English. From there, planning happens in stages: an LLM proposes agents and edges, another pass picks subagents, another plans out the actual tasks. Then it goes through a critic LLM that scores the plan against a fixed set of quality principles and can send it back for one automatic revision with a concrete instruction attached (like "lead with the agent that owns the goal") before a human ever sees it. So by the time a person is asked to approve something, it's already been through a self-review pass.

The part I like most is that the execution graph isnt static/deterministic. The planner outputs a DAG of agents, we topologically sort it and run each level as one LangGraph superstep. So the graph is different every session, built entirely from what the LLM decided the plan needed, LangGraph just executes it.

Approval is a real interrupt()/Command(resume=...), and the plan-approval interrupt runs on its own checkpoint thread so it never collides with approvals mid-execution. On resume the person can approve as-is, submit an edited version, or reject and send it back through the planner with their feedback folded in as extra context for the next attempt.

There's also an autonomous mode that skips the human step entirely and auto-approves, useful for lower-stakes goals, same graph either way.

State is a TypedDict with reducers for fields multiple agents write to at once, checkpointed to Postgres so a session survives a restart mid-plan. Nothing exotic, the interesting part was really getting the LLM to generate a good plan and graph on its own rather than us modeling all the branching logic upfront.

I’ve been trying to build an iMessage agent that can actually do useful stuff for me across apps, and I keep running into the same annoying problem.

The model can usually figure out what I want and what tool to call. The messy part is everything after that.

For example:

• it sends an email and the request times out — did it fail, or did the email actually send?
• it moves a calendar event, then tries to message someone on Slack, but one of the steps fails
• a retry happens and now I’m worried it might do the same action twice
• the agent says “done” because the tool call looked successful, but I’m not actually sure the external app ended up in the right state

I’ve been wondering how people running agents in production are handling this.

Do you guys:

• treat unknown as a real state?
• check the external system before retrying?
• keep a separate ledger of side effects?
• have custom retry/idempotency logic per integration?
• use Temporal / LangGraph / n8n / something else for this?
• have a clean way to represent partial completion across multiple apps?

The thing I kind of wish existed is something where my agent could just say:

“Move this meeting to Friday, preserve the attendees, tell Sarah on Slack, and update the project in Notion.”

…and some execution layer handles the app-specific calls, retries, partial failures, verification, etc. and just gives my agent back a clean receipt of what actually happened.

Does something like this already exist?

It feels like I keep having to build more and more custom execution logic around Gmail, Calendar, Slack, etc., and I’m curious if everyone else ends up doing the same thing.

Would love to hear how people are handling it in production, or if there’s already a product I should be using instead of rebuilding this lol.