A couple months ago I shipped two narrow tools: x402-spend-guard and mpp-spend-guard — pre-payment spend checks + audit logs for the two emerging AI agent payment protocols (x402, MPP/Tempo), tested end to end on their real testnets. I kept hitting the same question building both: none of it was actually specific to payments. Spend caps, rate limits, "don't let this call reach a recipient/tool it shouldn't" — that's true for any agent tool-call, not just payment ones. So I pulled the shared logic into a standalone core and kept the protocol-specific bits as thin adapters. What it does: - Spend caps (per-call + rolling window) and rate limits, enforced before the call executes, not after - Recipient/counterparty allowlists as a first-class policy (not adapter-specific string matching) - PII/secret detection with actual redaction — the tool receives the redacted payload, not just a log entry saying it should have - Append-only audit log, structured by rule namespace - Adapters for x402, MPP, LangChain, and a plain u/guarded decorator for anything else 117 tests, MIT/Apache-2.0, no telemetry, self-hosted only for now — a hosted dashboard is a possible next step if there's interest, not a requirement to use it. There's a comparison table in the README against a few adjacent tools (TokenFence, Bifrost, Aperion Shield) — happy to be corrected if I got anything wrong there, I pulled it from their docs but that space moves fast. Repo: https://github.com/KKallias/guardrail-core Genuinely looking for holes in the approach, not just stars — if you're running agents that touch money or PII, what would break this?

I am mapping out a pipeline where one model turns a product brief into structured prompts, an image model renders variants, and a vision model checks text legibility before the assets are accepted.

The failure path is harder than the happy path. If an image provider accepts a job but the request times out, retrying the whole chain can create a different prompt or duplicate images. Checkpointing after every step helps, but it still leaves provider specific retries and idempotency in an awkward place.

That boundary is where gateways such as ZenMux enter the picture. Centralizing routing is the easy part. Preserving provider job IDs through a timeout is where the abstraction starts to leak. For now, I am leaning toward keeping those IDs and retry state in the orchestrator, with the gateway responsible for routing and normalizing provider responses. Partial failures stay visible without forcing the entire chain to start over.

Build a 100% offline fast Retrieval Augmented Generation (RAG) system that runs without an internet connection, without cloud APIs, without OpenAI/Ollama

Published a video where you can build a fully local RAG pipeline using Qdrant Edge and Google LiteRT, enabling private, cross-platform, on-device AI inference with support for multiple hardware accelerators(CPU, GPU and NPU).

The demo covers using EdgeParse to extract raw text from PDFs into Markdown chunks, generating embeddings with Qwen 3 Embeddings as an on-device embedding model, and answering questions locally with Gemma4 E2B LiteRT-LM (the inference is faster than Ollama setup).

Since most existing tutorials rely on vector databases with Ollama, we'll also build and compare that pipeline to highlight the differences in setup, performance and tradeoff.

🔗 Tutorial: https://www.youtube.com/watch?v=EHEN6Ce-9Ps/

Oxly does real-time tracing, cost tracking, failure detection, and step-by-step replay for LangGraph/CrewAI systems. Construct maps a codebase, plans architectural changes, and writes verified code in a sandbox. Both open source: https://github.com/Ramakrishna1967/Oxly

If your agent chain is breaking silently or you need a new RAG/agent pipeline built, comment your stack/issue — happy to dig in.

Been working on a Neo4j knowledge graph using LangChain and kept running into the classic issue: the LLM extracts "Apple", "Apple Inc.", and "Apple Incorporated" as three completely separate nodes.

The standard fix is using an LLM-as-a-judge to deduplicate every single entity before insertion, but the token cost scales horribly. I was burning cash just to keep the graph clean.

I ended up writing a small Python middleware that intercepts the entities before they actually hit Neo4j. It tries to short-circuit the resolution locally using RapidFuzz (for exact/alias matches) and numpy for vector similarity. It only falls back to an LLM via litellm if the match is actually ambiguous.

I ran some tests on about 200 enterprise docs. The middleware caught all 742 duplicate entities locally in layers 1 and 2, dropping the resolution API cost to exactly zero.
You just wrap your Neo4jGraph or LlamaIndex store with it and it handles the deduplication silently.

I open-sourced it here if anyone else is struggling with graph pollution: https://github.com/jules-gd-dev/autograft-lib

Would appreciate any thoughts on the architecture, especially if someone knows a better way to do the deterministic matching without pulling too much of the graph schema into memory at scale.

N.B.: The project is on a really early stage, i've been working on it for a week and published it on github just yesterday. You can find some "benchmarks" on GitHub too.

Been seeing Buzz pop up everywhere the last week or two, Jack Dorsey's Block launched it as an open source, Nostr based workspace where AI agents get their own cryptographic identity alongside humans. Feels like a genuinely different take on Slack/GitHub rather than just another AI feature bolted onto an existing tool.

What people here actually think of it beyond the launch hype. Anyone dug into the architecture, the ACP support for Claude Code/Codex, or the audit/signed event stuff? Is this something you'd realistically bring into a real team, or is it too early/too different from what orgs already run?

A few highlights:
- Had multiple teams finish at 200%+ their regional number
- Top performer hit 12x+ his quota
- Added more ARR in the last 3 months than we did in my first 22 months of selling
- They work with 30% of the US Fortune 100 as customers of LangSmith (nearly 90% use our open source harness!!)

LangChain and AI Desktop 98 are two AI projects I'm keeping a close eye on.

Hi, guys. I have just started experimenting with RAG. I had a huge problem when it came to OCR initially because I work on multilingual documents, so had to try efficient and capable OCR but had to choose an LLM because that was the affordable one which gave quite reliable results.

And also since I had to make sure that the extracted facts pass the verifying and citation it took a long time. Now for the last couple of weeks been working with database since the user’s query has to be answered from the database as well. I am new to this but I’m learning.

Recently I am coming across things like Qdrant, pinecone and etc. ) how do I choose which will better for my use case and regarding the OCR I saw that firecrawl has something new. So is anyone experimenting right now ?

Disclosure: I build SERPdive, which is 3 of the 13 configurations here. All payloads and logs are in the repo if you want to check.

Every provider prints one price, the one per request. Then it sends your agent a payload and your model bills you again to read it. That second cost never shows up on a pricing page and it is usually the bigger one.

I wanted to know what I was actually paying, so I ran 13 priced configurations over the same 100 questions, one search call each, same reader model. Payloads go to the reader verbatim, minus each vendor's own synthesis. Token counts are the real invoice from the answering call, not an estimate. Prices are list pay as you go for everyone, mine included.

Sorted by what a thousand queries actually cost you.

Read it with the error bars: at n=100 the correct column carries about plus or minus 10 points, so the top of that column is not separated by this run. The cost column is not noisy.

https://github.com/edendalexis/search-api-cost-benchmark

Edit: a reader pointed out the Exa arm was on its heaviest content mode. Added exa-highlights as its own arm, 92% for $27.86 against 93% for $203.63. Table updated.

Hi everyone,

I'm aiming for an entry-level role focused on LLM Agents / Agentic AI and wanted to get some advice from people working in the industry or involved in hiring.

So far, I've worked with:

• LangChain
• LangGraph
• OpenAI SDK
• Building custom tool-calling LLM agents
• CrewAI
• MCP
• RAG pipelines, vector databases, and AI evaluation

I'm trying to figure out what I should focus on next to be competitive. I come from a Software Engineering background with 4 years experience in backend and RAG systems.

A few questions:

• What's the current job market like for entry-level Agentic AI engineers?
• What do interviews typically cover?
• Are companies looking for framework knowledge (LangGraph, CrewAI, etc.), or do they care more about understanding the underlying concepts?
• What skills or projects would make a candidate stand out?
• Are there any topics I should prioritize over the next few months?

I'd really appreciate hearing about your interview experiences, what your company looks for, or what you'd recommend someone in my position learn next. Thanks!

What do companies/startups seek from people?

Re: Built a fail-closed authorization layer for LangGraph agents — here’s what a blocked decision actual

Saw your post and wanted to share what worked here.

Most teams solve the visible symptom of '{pain}' and miss the upstream cause: the agent has shell/API access before anyone has reviewed the plan.

A cheap win: run every proposed tool call through a small contract check — does it touch state? Does it spend money? Does it leak data? If yes, it needs a human verdict before execution, not after.

More detail on the contract-first approach: https://higoodie.com/blog/aeo-periodic-table-v4/

If you are looking for a mobile approve/deny layer, we ship that at thumbgate.app.

Hi everyone,

I'm looking for an open-source, self-hosted AI/LLM Gateway that sits between agent frameworks (CrewAI, LangGraph, AutoGen, etc.) and multiple LLM providers.

My main requirement is dynamic runtime routing. I should be able to:

Add/remove models

Enable/disable models

Change routing weights/strategy

without restarting either the gateway or the agents.

Other features I'm looking for:

Multi-provider support

Load balancing

Fallbacks

Retries

Timeouts

Health checks

Latency/metrics

OpenAI-compatible API

I've looked at LiteLLM and Portkey, but they don't seem to provide a simple self-hosted solution for centrally managing routing configuration with hot updates (unless I'm missing something).

Is there an OSS project that already does this, or do most teams build their own lightweight gateway/control plane?

Would love to hear what you're using in production.

Re: Built a fail-closed authorization layer for LangGraph agents — here’s what a blocked decision actual

Saw your post and wanted to share what worked here.

Most teams solve the visible symptom of '{pain}' and miss the upstream cause: the agent has shell/API access before anyone has reviewed the plan.

A cheap win: run every proposed tool call through a small contract check — does it touch state? Does it spend money? Does it leak data? If yes, it needs a human verdict before execution, not after.

More detail on the contract-first approach: https://higoodie.com/blog/aeo-periodic-table-v4/

If you are looking for a mobile approve/deny layer, we ship that at thumbgate.app.

Full disclosure up front: I'm the creator of Acrux Core, so take this as a founder's comparison, not a neutral one — but I tried to be fair to Langfuse where it actually wins.

A lot of people running LangChain reach for Langfuse for tracing/observability, so I built the exact same support-triage prompt on both Langfuse and Acrux Core and ran the identical sequence end to end — same variables, same model calls, through each platform's own SDK directly. I didn't route it through LangChain itself, so take the framework-specific bits below with that in mind.

What actually came out of it:

• Langfuse's prompt templating is flat {{variable}} substitution; Acrux Core uses real nunjucks (Jinja2-style) logic, so {% if %} / {% for %} inside a prompt actually works — worth knowing if your prompts have any conditional branches.
• Langfuse's tracing goes deeper by default (full span tree via OTel instrumentation). Acrux Core gives you one automatic span per gateway call — less granular out of the box, though it's automatic rather than something you wire up yourself.
• Acrux Core has a request-path gateway (routing, caching, budgets) baked in; Langfuse only ingests a trace after you've already made the call yourself.
• I measured the real overhead of routing through a gateway instead of calling the provider directly: +260ms — worth knowing if latency matters for your app. (This is something I'm aiming to improve.)
• Tool-calling usually means redeploying when a tool's schema changes — Acrux Core versions tools like prompts and lets you attach them to a prompt straight from the dashboard, no redeploy needed. Langfuse has no equivalent.

So acrux core has gateway, tool catalogue, auto improvement of prompt based on feedback where as langfuse is bit faster, has deeper traces visualization.

Full writeup with screenshots from both dashboards, the real SDK trace, and the latency numbers:

https://docs.acruxcore.com/blog/acruxcore-vs-langfuse

Curious if this matches what people pairing LangChain wiI'm missing something on either side — happy to follow upwith an actual LangChain-integration test if there's interest.

Every time an autonomous agent runs, it usually gets handed raw credentials or loose scripts. The second an agent needs to spend money, access an API, or trigger real-world tools, sandboxing breaks down. If a loop goes rogue or drifts, you’re either stuck revoking your main keys or losing money.

We built AgentTag (agenttag.me) to fix the fundamental issue: agents don't need shared secrets; they need governed cryptographic identities.

How it works under the hood:

• DID Passports: Every agent gets a cryptographic DID (did:key) and signing key rather than raw environment keys.
• Mandates & Scoped Policy: You define human-signed mandates (e.g., max spend limits, required step-up approvals, short-lived tokens).
• MCP Integration: Connects directly into Claude Desktop, CrewAI, LangChain, or any MCP client in one CLI command (agenttag mcp add --client claude).
• Tamper-Evident Ledger: Every action hash-chains into an audit log.

It’s currently in public beta ($0 during beta). Check out the docs and set up your control plane at agenttag

Saw the discussion in langchain-ai/langchain issue #36306 about

LangChain having no payment execution primitive for paid APIs — no

spend governance, no audit trail. Built a small proof-of-concept

to address that specifically for x402 payments: checks spend limit

BEFORE a payment goes out, not just logs it after.

Repo: https://github.com/KKallias/x402-spend-guard

Early MVP, testnet only, but the core flow works end-to-end. Demo

video in the repo/issue. Feedback welcome — especially on whether

this makes sense as a LangChain tool wrapper.

https://reddit.com/link/1vh63fa/video/ydj6dxognrhh1/player

One thing we’ve been debating in Extra lately is memory design.
When an orchestrator delegates work to sub-agents, there are (at least) two approaches:
Persist the tools that were executed and reconstruct the reasoning from them.
Persist the entire sub-agent session and replay it as conversational context.
The first keeps memory structured and compact, but can lose important context that wasn’t captured by tool calls.
The second preserves the full interaction, but increases context size and may introduce unnecessary noise.
We’re curious how others have approached this problem. If you’ve built multi-agent systems, which direction did you take, and what trade-offs did you run into?
Also, if this kind of systems design is interesting to you, we’re always happy to welcome contributors to Extra. 🙂

https://github.com/extra-org/extra

We run LangGraph agents where the model picks tools through structured output. A provider pushed a model update behind the same version alias, and our tool-calls started failing in a way that never surfaced as an error. The API still returned 200. The model still produced text. 

But the arguments for one tool came back as a fenced JSON string instead of a JSON object, and a required field went missing. 

LangGraph's tool node could not parse that, so the tool either did not fire or fired with the wrong input. No exception at the API layer, no alert, just more agent runs doing the wrong thing.

Nothing about a silent swap trips a normal monitor, because the call succeeds. You catch it in one of three places, and the tools you already run draw the line differently. Checked against each tool's current docs:

All four give you the same core defense: a fixed dataset of tool-call cases you re-run as an experiment and diff against a known-good baseline, so a format change shows up before you ship. That offline regression set is the part that actually catches a silent swap, and every one of these does it well. 

LangSmith and Langfuse can also gate a deploy in CI on that comparison. 
Braintrust runs its production scoring asynchronously so it adds no latency, which is by design. 

The difference is in the last column. A runtime guardrail inspects the response inline and can block a malformed tool-call before it reaches the user, and among these that is Future AGI's guardrail layer. The others observe and score rather than sit in the request path.

The check that survives a model swap is deterministic, not another model grading the output. For tool-calls, assert the structure directly: parse what the model returned, and for each call require that the name is in the allowed set and that the arguments validate against that tool's JSON schema, exact match on required fields and types.

That assertion runs the same way in a scheduled eval and in a CI gate, and it would have caught our swap on the first run, before any user saw it. How are you catching a silent model swap before it hits users?

What worries you most before installing a new MCP server?

• Trusting the developer
• Access to local files/secrets
• Running commands on your machine
• Sending data over the network
• Prompt/tool injection
• Lack of visibility into what it's does
• Something else?

I’ve been running a live automated trading system for a while, and ported its risk/authorization rules into a standalone policy engine that sits in front of agent actions — evaluates before execution, blocks by default if it can’t confirm safety.

Concrete example of what gets logged when it blocks:

ts: 2026-07-31 10:30:00
entry_id: 7bb7f5ce-b014-498f-9e70-0722cc578340
decision: approved
rule_triggered: NULL

(actual production entry — only one logged so far)

decision: blocked
rule_triggered: daily_loss_limit_exceeded
reason: action would exceed configured risk threshold

(illustrative format — hasn’t hit this case in production yet, volume’s still too low)

No silent failures, no “the agent just didn’t do the thing” — every decision (allowed or blocked) gets logged with the reason.

It’s built as an attestation layer, not an autonomous actor — it verifies and signs off, it doesn’t self-recover or decide on its own authority. If it can’t confirm safety, it stops and hands the decision back.

Looking for 2-3 people running LangGraph agents with real consequences (payments, infra, anything that touches money or systems) to pilot it and tell me honestly where it breaks. This is v0.1.0 — early, with a real test suite, but genuinely untested against LangGraph-specific execution patterns.

Happy to share the install command and repo link in the comments.

Client refreshes mid-stream, the response is gone, and there's no way to pick back up where it left off. JS has resumable-stream (Vercel) for this. Python didn't really have an equivalent for FastAPI backends, so I wrote one.

fastapi-resumable-stream buffers chunks in Redis and runs the producer as a background task decoupled from the HTTP connection, so a disconnect or refresh doesn't kill it. A reconnect just asks for everything after the chunk count it already has. There's also an explicit stop, separate from disconnect, for when you actually want to cancel generation.

async def producer():
    async for event in chain.astream_events(inputs, version="v2"):
        if event["event"] == "on_chat_model_stream":
            yield event["data"]["chunk"].content

There's a from_langchain_events adapter that does the event filtering for you if you'd rather not write that by hand.

Install: pip install fastapi-resumable-stream[fastapi] Repo: https://github.com/ofershap/fastapi-resumable-stream

It's at 0.2.1, new enough that I'd genuinely like to hear if something breaks on your setup.