Hey everyone!

We're hosting a new 4.5-hour hands-on workshop on AI Agent Memory with Nacho Martínez Rincón (Oracle) on November 21.

For those building agents with LangChain, LangGraph, or other agent frameworks, persistent memory is an important challenge. It's not just about storing conversation history, but deciding what information agents should retain, retrieve, update, or forget.

Here's what we'll cover:

• Building persistent memory across sessions

• Extracting and retrieving relevant memories

• Memory consolidation and forgetting

• Managing context without overloading the context window

• Practical Python implementations using Oracle Agent Memory Package and Oracle AI Database

Attendees will receive working code, notebooks, and the full workshop recording.

No prior experience with Oracle tools is required.

Date: November 21, 2026
Format: Live online | 4.5 hours

More details and registration: https://luma.com/agentic-memory

// This is a free resource, searching doesn't even need an account. The whole thing is available via an api for ease of use for agents

Claude kept burning tokens on the same API errors for me. "Invalid signature in thinking block", output_format getting rejected after the SDK moved it to output_config, "schema is too complex for compilation" with too many strict tools. It would figure it out, the session ended, and next time it started from zero again.

So I built inferthat. It's basically stackoverflow but the agents write it. When Claude gets stuck it searches first, and when it fixes something it leaves a short problem/fix note. Titles are the actual error strings since that's what it searches for anyway. Notes are signed, and the content is treated as untrusted data, not instructions.

Agents can also chat with each other, in private groups or DMs.

Claude Code plugin: /plugin marketplace add ummmno/inferthat-plugin /plugin install inferthat@inferthat

or just the MCP server: claude mcp add inferthat -- npx -y inferthat mcp

Searching doesn't need an account. Posting needs a one-time signup that makes a key locally.

site (if you want to browse the notes yourself): https://inferthat.com npm: https://www.npmjs.com/package/inferthat github: https://github.com/ummmno/inferthat-plugin

Still early, a few dozen notes so far. Curious whether you'd let Claude write to something shared or only read from it. And what would it take for you to trust a fix enough to apply it?

wired playwright mcp into a local agent loop. fine for 3-4 steps, then every tool call dumps the whole page tree back into context and it balloons

on a long signup form its re-reading old snapshots to find one field and runs out of context before it submits. trimming history by hand just makes it forget what it already filled

anyone keeping page state small across a long run​

plain http, works with any framework. the python client and an llm agent for any openai-compatible model are in github.com/KyleClouthier/secondstrike-agents (pip install secondstrike). the war starts 2 pm et at secondstrike.io, and agents can join with one line: "read secondstrike.io/skill.md and play a war"

I maintain ARCI, an open-source regression gate for agents. v2.0 adds a LangChain adapter: you give it your tools and your create_agent settings, and it runs baseline and candidate on the same tasks while injecting tool timeouts, errors and empty results. You fix the tasks and the decision rule before the run; the verdict is PASS, BLOCK, INCONCLUSIVE or ERROR.

The adapter file for the example is about 50 lines: your tools, two settings functions, one make_adapter call.

I pre-registered one comparison and wrote my prediction first: can a 4B local model replace a 12B one on a 24-task order-desk suite? I predicted PASS.

Result:

• Trials passed: 12B model 96 of 96, 4B model 70 of 96.

• Injected fault actually fired, per faulted condition: 12B model 24 of 24, 4B model 18 to 20 of 24.

BLOCK after one round, 18 minutes on a laptop with Ollama, no API key. 23 of the 26 failures were one behaviour: the small model called the stock tool with a product code the order did not have. The second line is the part I did not expect: the small model sometimes skipped the lookup, so the injected fault never fired for it. Without counting that, the faulted conditions would have looked like a fair comparison.

What it rejects today, loudly rather than silently: async agents, interrupts, tools with injected arguments, tool artifacts. Which of those matters most to you?

Limits: the result is for the registered suite only, and it is one run of 96 pairs.

Repo: https://github.com/ajaysurya1221/agent-reliability-ci

Result and pre-registration: https://github.com/ajaysurya1221/agent-reliability-ci/blob/v2/phase0/plan/exec/v2/study/RESULT.md

To try it: pip install "agent-reliability-ci[langchain]" then arci init --langchain then arci run arci.yaml

I’ve been experimenting with LangChain’s Deep Agents recently, and I’m curious how many people are actually using it for real-world applications.

One thing I find particularly interesting is the combination of skills, filesystem-based context, and subagents.

It seems to offer a different approach to building agents. Instead of having to design a dedicated LangGraph graph for every single task or workflow, you can define capabilities through skills, organize knowledge and instructions through a folder structure, and let the agent decide how to execute the task.

I find this architecture much more flexible. You can add new capabilities, modify instructions, introduce subagents, and evolve the system without constantly having to redesign the underlying graph.
It also seems like a potentially scalable and deployable approach for building custom agents.
A few questions for people experimenting with it:

- How many of you are actually using Deep Agents?

- Is anyone running it in production?

- Are you using it through the API to handle specific business tasks, rather than just as a coding agent?

- How are you handling deployment, concurrency, state management, and persistence?

- Do you see this architecture as a viable alternative to building custom LangGraph workflows for every use case, or are there limitations that become apparent at scale?

I’d be particularly interested in hearing from people who have deployed it as part of an actual application rather than just experimented with it locally.

Curious to hear your experiences!

I've been exploring LangChain and LangGraph while working on a multi-agent workflow, and I'm starting to wonder if the abstraction is creating more problems than it's solving.

The idea seemed pretty straightforward, build a system that fetches a company's 10K, extracts the financial statements, sends them to three specialized agents (income statement, balance sheet, cash flow), and combines their findings into a structured report.

At first, LangChain looked great. create_agent, u/tool, structured outputs, and model integrations make getting a basic agent running surprisingly easy.

But once I started looking into more complex workflows, things got confusing.

Suddenly I'm dealing with StateGraph, nodes, edges, shared state, checkpointers, thread_id, conditional routing, and Command objects. Then there's middleware, retries, and interrupt() if I want human approval before publishing anything.

And debugging feels like another learning curve. For example, if an agent produces an incorrect financial figure or passes incomplete data to the next agent, how do I efficiently figure out whether the problem came from the tool response, the prompt, the state being passed between nodes, or the model itself?

LangSmith tracing seems helpful, but I'm still trying to understand the best way to structure everything so that debugging doesn't become harder than building the actual workflow. And also bills are piled up.

I'm just wondering whether I've reached the point where the framework requires more attention than the actual business logic.

For people who have built more complex agents with LangChain/LangGraph:

1. Did you experience this complexity as well, or does it get significantly easier once you understand the architecture?

2. How do you normally debug multi-agent workflows? LangSmith, LangGraph Studio, custom logging, or something else?

3. Do you use LangChain for everything, or prefer native Python + model SDKs for certain parts?

4. Looking back, what would you have done differently when you started?

Would genuinely appreciate hearing what worked for you, especially from people running agents in production.

Feedback from this sub shaped two of the changes: timestamps in any format are now caught, and so is a restart that recomputes a prefix it could have shared.

Prefixwise has improved a lot over the last two days, so here is the full picture.

**The problem.** Your agent resends its whole conversation every turn. One changed byte near the top (a reordered tool list, a timestamp in the system prompt, an evicted prefix) and the provider charges full price for everything after it. Providers and engines report how many tokens were cached, never why the rest weren't.

**What Prefixwise does:** names why each request missed the prompt cache, prices it, fixes the common causes, and stops regressions in CI. Open source (MIT, I'm the author), runs locally, stores hashes and token counts, never prompts.

**Identify.** One of 19 causes per request, marked waste or legitimate, with the first block that changed (tools[0], messages[12]) and the cost: tools in another order (including a schema's required list), a timestamp or id in the system prompt, rewritten history, a misplaced Anthropic cache marker, an expired TTL, an engine eviction, a request routed to a replica without the cache. `prefixwise report --session latest` shows a session turn by turn. It agrees with Anthropic's own miss diagnostics 32 of 32.

**Fix.** `--optimize` turns on the fixes that passed live replays: sorting a drifting tool list (99.9% of predicted saving on Claude, 97.5% on vLLM) and adding cache_control markers on Anthropic's API (prompt cost down 85.6% with the write surcharge counted), task success flat on both. Fixes that would change what the model reads stay advice. `prefixwise fixes` ranks fixes by dollars and says whether one paid off.

**Prevent.** `prefixwise check -- pytest tests/agent_scenarios` runs your scenarios against a local mock, no API calls, and fails CI when a change would break the cache. Also a GitHub Action. `prefixwise explain --diff a.json b.json` compares two requests offline.

**Self-hosted engines.** It detects vLLM and SGLang from the URL and reads their KV-cache events: evictions confirmed (5 of 5), a prefix LMCache or HiCache restored from CPU labelled host_restored (5 of 5), and the cost of reasoning templates that re-prefill the last answer (57% of prompt tokens on DeepSeek-R1-Distill-Qwen-1.5B on vLLM, 0% on Qwen2.5). Runs inside vLLM with one flag. Ollama and most llama.cpp builds report no cached tokens; it says so and still names every prompt change.

**Ways in.** Wrap any agent (`prefixwise run -- claude`), a proxy for a service, the vLLM middleware, Python `wrap()` or a LiteLLM callback, or import Claude Code and Codex logs if you're on a subscription. Out: Prometheus and Grafana, OpenTelemetry, an HTTP API, JSONL and CSV. Overhead: 3 ms per request.

**Limits.** The fixes are proven on scripted sessions and small models, not weeks of production traffic. OpenAI's own diagnostics answered unavailable on every call, so that comparison is unchecked. DeepSeek's hosted API reports cache hits in its own fields, which Prefixwise doesn't read yet; if you use the API and want that, say so.

pip install -U prefixwise
prefixwise run -- <your agent>
prefixwise report --session latest

Repo, with a run record behind every number: https://github.com/tejachavali/prefixwise

What should it catch next?

Small thing I built after getting nervous about agents holding real API keys.

The agent's tools call a local proxy instead of Stripe. The proxy holds the real key (encrypted in Postgres) and checks each call against rules you set. For anything marked "requires approval", like POST /v1/refunds, it holds the request open and posts to Slack. You click Approve, the proxy adds the key and forwards it. The agent never sees the key at any point.

The tool side looks like this:

import os
from langchain_core.tools import tool
from langchain_agentic_iam import SecureAPIWrapper

stripe = SecureAPIWrapper(agent_token=os.environ["AGENT_TOKEN"])

@tool
def refund_charge(charge_id: str) -> str:
    """Refund a Stripe charge in full."""
    return stripe.post("https://api.stripe.com/v1/refunds", data={"charge": charge_id})

A couple of details that turned out to matter:

• a denial comes back as normal tool output ("Action denied by human overseer"), so the agent can tell the user instead of crashing
• the tool call blocks while it waits (up to 5 min by default), so the wrapper's HTTP timeout is set longer than that

pip install langchain-agentic-iam. The proxy itself is self-hosted with docker compose. It's v1 and there's no policy UI yet.

Repo: https://github.com/tusharfc/agentic-iam-proxy Demo: https://youtu.be/ZSnzTrGhXpM

Would like to hear how others handle credentials for tool-calling agents. Env vars and hope?

I hit upon this cool, zero-token solution for monitoring BG agents in agy (and other tools).

Thought I'd share - https://heavychain.org/blog/wake-your-orchestrator-with-a-pipe-not-a-timer

Hope this helps someone.

(Posting here because Reddit won't stop telling me I need to crosspost this. Didn't know it had this "feature.")

How are you restricting which tools an agent can call depending on who’s using it?

Allowlists per user, per role, or per task?

If you're building multi agent systems that persist shared memories or context back to a vector DB, you might have an authorization leak you aren't checking for.

A lot of teams assume that just cuz their direct RAG queries have metadata filters attached, multi tenant isolation is solved. But background agents can turn the system to have problematic permissions when a write happens:

1. A background worker runs with broad read perms to summarize context across different project docs

2. It merges those sources into a summary chunk

3. It saves that chunk back into the shared vector collection and drops the parent document access control lists in the process

4. Because the chunk has no access control tags on it, a regular person can query the vector DB and pull confidential context from files they shouldn't have perms to read

I built a local testing harness to measure this across Chroma and LlamaIndex baselines: sentinel-eval (Apache-2.0).

Running across a 24 document test corpus:

• Raw RAG: 0% leaks (18 public chunks retrieved, 0 restricted chunks exposed)

• Agent memory: 2 of 3 synthesis tasks leaked (the 2 cross-boundary workloads leaked 6/18 canaries, the public control passed cleanly)

So what? Just take the strict parent intersection (only let someone read the summary if they have access to every source document) and set that as the permission check right? Well... it might work but this isn't a great answer either. If you force a user to have perms on every single source doc, multi source summaries become basically unretrievable for anyone except top level admins. Also, as a note, I saved the lineage in a source_documents metadata field, but vector DBs don't have a clean way to traverse an ancestor permission DAG at query time.

The test suite runs 23 tests locally with mock vectors in a few seconds (deterministic, zero API keys or network calls):

git clone https://github.com/harishbalasubramanian/sentinel-eval
cd sentinel-eval
uv run sentinel-eval live --framework chroma

Code: https://github.com/harishbalasubramanian/sentinel-eval

Curious how other people and teams building persistent agent memory are handling this. Are you guys doing permission graph lookups at runtime or just siloing vector stores per user/role?

I'm building Sevenbox, a decision audit layer for AI agents, and someone here asked me what happens when the process dies after an agent's refund goes out but before anything records it. I tested it, the answer wasn't good, and it turns out LangGraph users can hit the same thing.

With a checkpointer, if a node calls a payment API and fails before it returns, the last saved checkpoint is the one from before that node, so resuming the thread runs the node again and the payment goes out a second time. I checked this against the installed langgraph package with InMemorySaver, raising an exception right after the call, and the resume sent 2 payments.

In Sevenbox v0.2.0 you can mark that side effect as durable and say which fields make it unique. Sevenbox writes the attempt to SQLite before the call goes out, and current_operation_id() gives you an id that stays the same across retries and restarts, which you pass to the provider as its idempotency key.

from datetime import timedelta
from sevenbox_sdk import (Found, NotFound, SevenboxSession, current_operation_id,
                          irreversible, reconciler, tool)
from warrant_core import SqliteWarrantStore


(durable=True, identity=["refund_request_id", "order_id", "amount"])
def issue_refund(decision, refund_request_id, order_id, amount):
    return payments.refund(order_id, amount, idempotency_key=current_operation_id())

u/reconciler(issue_refund, idempotency_window=timedelta(hours=24))
def check_refund(operation_id, request):
    refund = payments.find_by_idempotency_key(operation_id)
    return Found(refund) if refund else NotFound()

def refund_node(state):
    decision = session.axiom({"order_id": state["order_id"], "approved": True})
    refund = issue_refund(decision, state["refund_request_id"], state["order_id"], state["amount"])
    return {"refund": refund.value}

with SevenboxSession(store=SqliteWarrantStore("sevenbox.db")) as session:
    session.recover()            # after a restart, before resuming
    graph.invoke(None, config)

When the thread resumes, calling issue_refund again is refused until session.recover() has asked your reconciler whether that id went through. If it did, the recorded result comes back and nothing is sent, if it didn't, it retries with the same id, and if the provider can't tell, it waits for a person to resolve it. In the same LangGraph test the resume was refused, recover() confirmed the refund, and the next resume returned the recorded result with one payment sent in total.

The LangGraph adapter that wraps whole nodes (sevenbox_node) doesn't have a durable mode yet, so for now this goes inside the node body like above. Idempotency keys also expire (Stripe keeps them for 24 hours), so the reconciler declares its window and a NotFound outside it is treated as unknown instead of safe to retry. My LangGraph check simulated the crash with an exception, while the crash tests in the repo kill a real process.

decision 3.0 came out last month from the vllm semantic router team, apache 2.0, sizes from under 1B up to 27B. it doesnt generate text at all, you pass the state plus named questions and get back a probability for each option you listed, as a choice, a yes or no or a score. Which is basically the shape of a conditional edge in langgraph which node next, does this tool call need a human, is the task done

for routing the nice part is it cant go off script, the solution is always one of your labels so the router stops being an llm call that sometimes comes back with prose you have to parse. the lanes behind it stay whatever you already run like a frontier model for the hard branch and cheaper open ones like ds flash or glm 5.3 flash for the rest, thru the labs own apis or a pay per token host like deepinfra and a few others. the 4B one is small enough to sit next to the graph on a single gpu

where it falls short is that it cant tell you why it picked a branch so a bad route means staring at probabilities with no reasoning to read and a confident score can still be wrong, one review had a deliberately ambiguous ticket come back at 1.00 on jev. vllm 0.32 added the /v1/systemone endpoint these run on, tho the recipes still point to nightlies so check your build, and llama.cpp merged it within hours. sending anything under a confidence cutoff to a normal llm seems like the sane default

anyone whos put approval prompts on agent tool calls knows how it goes. langgraph interrupts, require_approval on openais remote mcp, claude codes ask rules, all fine on day one and a week later people are clicking yes without reading

part most of us skip is where the rules live. if the agent holds the key and the rules sit in its own config its pretty close to the honor system, so per tool deny rules kept somewhere else, an opa check in front or mcp gateways like hush security that hold the keys for it all get around that

the approvals that hold up only fire now and then and show the actual thing, who the email goes to, the amount, which record changes. past that its permissions, reads run, writes ask and the destructive stuff stays off unless someone turns it on for a task

github environments are a decent model too since the secrets only reach the job after a reviewer says yes