DEV Community: t49qnsx7qt-kpanks

How I took LongMemEval oracle from 62% to 82.8% without touching the retriever

t49qnsx7qt-kpanks — Tue, 21 Apr 2026 05:15:48 +0000

I've been building a memory layer for AI agents (MnemoPay) and LongMemEval is the public benchmark I've been beating my head against for the last two weeks.

Started at 62-64% (Sonnet-4 answerer, GPT-4o judge). Ended today at 82.8%. Here's what actually moved the number and what didn't.

Scoreboard

500-question oracle variant, GPT-4o as judge.

Run	Overall	Notes
Baseline	62-64%	Sonnet-4 answerer, default prompt
Session summarizer	~72%	Compressed each session to a tight recap before feeding into context
Entities + spreading	77.2%	Entity graph + 1-hop spreading over recalled chunks
Azure gpt-4o answerer	81.4%	Same pipeline, swapped the model
Preference-fix prompt	82.8%	Classify the question before answering

Biggest single lift was the last one. 1.4 points overall, but it's a 20-point lift on the preference bucket (60% -> 80%) and it's basically free.

What moved the number

Session summarization. The judge doesn't read your haystack, it reads your answer. If the answer is a 2KB dump with the fact buried in paragraph 3, the judge is generous but the model's own attention is not. Pre-summarizing each session before recall made the answers sharper.

Entity graph. A question like "what did I tell you about Denver in February" doesn't hit on the token "Denver" if the session talks about Red Rocks and Brandon Flowers. Spreading activation one hop through an entity graph fixes most of the multi-session recall misses. Not magic, just a dict of {entity: [session_ids]} built at ingest.

Question classification in the system prompt. This is the one nobody talks about. The preference bucket was sitting at 60% for a week. I dug into the failures: 9 out of 12 were spurious refusals. Questions like "any tips for my Tokyo trip?" got "the conversation history doesn't include tips about Tokyo."

Of course it doesn't. The user isn't asking you to recall tips, they're asking you to generate tips using what you remember about them.

Fix was one paragraph added to the system prompt:

First, classify the question. (A) Factual lookup: answer strictly from context, refuse if not present. (B) Recommendation / advice: extract signals about the user from context, ground your suggestion in named specifics. Never refuse a recommendation question with "history doesn't include recommendations about X."

Preference: 60% -> 80%. Didn't touch the retriever.

What didn't move the number

HyDE + rerank. Classic RAG trick. I ran a full 500q with HyDE + a cross-encoder reranker. Result: 74.6%. Down 2.6 points from no-HyDE. The hallucinated query was too close to the benchmark's distractors. Killed it.

Bigger context window. Went from 8k to 32k on the same pipeline. Gained 0.4 points. The model has the information either way. Judge-graded accuracy is about sharpness, not recall breadth.

More retrieval candidates. Top-k 5 -> 20 was flat. More noise cancels more recall.

The 1M stress test

Separate from the benchmark, I run a 1,000,000 transaction stress harness on the SDK on every release. Same pipeline, same ledger invariants, 100 concurrent agents doing charges, settles, refunds, disputes, and memory ops.

Latest run:

Agents:              100
Total ops:           1,036,685
Throughput:          2,904 ops/sec
Latency P50/P95/P99: 29 / 70 / 93 ms
Errors:              0.31%
Adversarial txs:     5,798 injected, 5,598 blocked (96.6%)
Ledger imbalance:    $0.00 (100/100 agents balanced)

Accuracy numbers lie if the system can't hold the line under load. These are the two tests I trust: a public benchmark for the intelligence, a stress harness for the plumbing.

Takeaways if you're tuning your own RAG

Look at your failures, not your aggregate score. A 20-point bucket lift hides behind 1.4 aggregate points.
Read the failure samples. Don't run another hyperparameter sweep until you've read 20 of them.
Most "recall" misses are actually answer-shape misses. The model has the information, it just packaged it wrong.
Swapping the answerer model is high leverage. Retrievers are load-bearing, but answerers are the voice.
Never trust a benchmark score without sample-level failures next to it.

Happy to share the harness if anyone wants to repro against their own stack. The benchmark repo is xiaowu0162/LongMemEval on GitHub if you're starting cold.

MnemoPay is the memory and payments layer I'm building. npm i @mnemopay/sdk if you want to poke at it. Python too: pip install mnemopay.

How to Add Memory and Payments to Your AI Agent in 5 Minutes

t49qnsx7qt-kpanks — Mon, 20 Apr 2026 14:00:09 +0000

Your AI agent can think. It can reason. It can call APIs and make decisions.

But ask it what happened in the last session and it draws a blank. Ask it to hold money in escrow and it has no idea what you mean.

I ran into this on every agent project I built. So I made an SDK that fixes both problems at once.

Install

npm install @mnemopay/sdk

Step 1: Give Your Agent Memory

import MnemoPay from "@mnemopay/sdk";

const agent = MnemoPay.quick("my-agent");

// Store memories with importance scoring
await agent.remember("User prefers monthly billing at $25/mo", {
  importance: 0.8
});

await agent.remember("User's timezone is CST, prefers morning emails");

// Recall memories — sorted by relevance, not just recency
const memories = await agent.recall(5);
console.log(memories);
// Returns the 5 most relevant memories, weighted by
// importance, recency, and reinforcement strength

This isn't a key-value store. The memory system is built on two neuroscience principles:

Ebbinghaus forgetting curve — memories naturally decay over time, just like human memory
Hebbian reinforcement — "neurons that fire together wire together." When a memory leads to a successful transaction, it gets stronger

The result: your agent naturally remembers important customers and gradually forgets one-off interactions.

Step 2: Give Your Agent a Wallet

// Charge with automatic escrow
const tx = await agent.charge(25, "Monthly API access");
console.log(tx.status); // "pending" — money is in escrow

// Settle when the service is delivered
await agent.settle(tx.id, "customer-agent-42");
// Fee is applied (1.9%), net goes to the agent, ledger balanced

// Check the balance
const { wallet, reputation } = await agent.balance();
console.log(wallet);     // 24.52 (after 1.9% fee)
console.log(reputation); // 0.55 (grows with successful deals)

Every transaction uses double-entry bookkeeping. Every debit has a credit. The ledger always balances to zero. We stress-tested this with 1,000 random transactions — the math never drifts by a penny.

Step 3: Multi-Agent Commerce

This is where it gets interesting. Two agents making a deal:

import { MnemoPayNetwork } from "@mnemopay/sdk";

const net = new MnemoPayNetwork();

net.register("buyer-bot", "owner-1", "dev@company.com");
net.register("seller-bot", "owner-2", "dev@company.com");

// One call — buyer pays, seller receives, both remember
const deal = await net.transact(
  "buyer-bot",
  "seller-bot",
  25,
  "API access for 1 month"
);

console.log(deal.netAmount);     // 24.52
console.log(deal.platformFee);   // 0.48
console.log(deal.buyerMemoryId); // buyer remembers the purchase
console.log(deal.sellerMemoryId);// seller remembers the sale

Both agents store the deal in their memory. Next time they interact, they remember the relationship.

Step 4: Fraud Detection (Built In)

You don't need to configure anything — fraud detection is on by default:

const agent = MnemoPay.quick("my-agent", {
  fraud: {
    maxChargesPerMinute: 10,
    maxChargesPerHour: 50,
    blockThreshold: 0.75,
  }
});

// This will be checked against velocity limits,
// anomaly detection, and geo-enhanced risk scoring
const tx = await agent.charge(1000, "Large purchase");
// If risk score > 0.75, the charge is blocked

The fraud system includes:

Velocity checks (per-minute, per-hour, per-day)
Statistical anomaly detection (z-score)
Geo-enhanced risk scoring (country tracking, rapid-hop detection)
OFAC sanctions screening
Trust dampening (consistent agents get lower false-positive rates)

Step 5: Verify the Ledger

const summary = await agent.verifyLedger();
console.log(summary.balanced);   // true — always
console.log(summary.entryCount); // total ledger entries
console.log(summary.accounts);   // all accounts and balances

Zero penny drift. Every time.

Real Payment Rails

When you're ready for real money, plug in a payment rail:

import { PaystackRail } from "@mnemopay/sdk";

// Africa (NGN, GHS, ZAR, KES)
const paystack = new PaystackRail(process.env.PAYSTACK_SECRET_KEY);
const agent = MnemoPay.quick("my-agent", { paymentRail: paystack });

// Same API — now charges go through Paystack
const tx = await agent.charge(5000, "Service fee");

Three rails available: Paystack (Africa), Stripe (global), Lightning (BTC).

MCP Server

If you're using Claude or another MCP-compatible assistant:

claude mcp add mnemopay -s user -- npx -y @mnemopay/sdk

Now Claude can charge, settle, remember, and recall directly through tool calls.

What's Next

I'm building toward the Agent Credit Score — a reputation + risk score for AI agents. The idea: if you combine persistent memory with payment history, you get a trust signal that's much richer than transaction volume alone.

An agent with 40 memories from 20 successful deals has 2x the credit signal of one with just bare transaction logs.

Memory is the credit file. Payments are the proof.

GitHub: mnemopay/mnemopay-sdk
npm: @mnemopay/sdk
Landing page: getbizsuite.com/mnemopay

Production-tested. Apache 2.0 licensed. Free to start.

august 2 is closer than you think, what the eu ai act actually requires from your agents

t49qnsx7qt-kpanks — Mon, 20 Apr 2026 02:21:27 +0000

august 2 is closer than you think, what the eu ai act actually requires from your agents

most compliance content on the EU AI Act reads like it was written by the same legal team that drafted the regulation. here is what it actually means if you are a developer shipping AI systems in the EU.

the hard deadline is august 2, 2026. if your system touches any of the Annex III categories like credit scoring, employment screening, education access, or critical infrastructure management, you are classified as high-risk. that is not a gray area. the law is explicit. conformity assessment, CE marking, and EU database registration are not optional.

the part most dev teams are missing is that "technical documentation" in the act is not a readme. it means documented architecture, training data provenance, model cards, human oversight procedures, and audit logs that a notified body can inspect. orrick's 6-step breakdown is the clearest public summary of what that looks like in practice: https://www.orrick.com/en/Insights/2025/11/The-EU-AI-Act-6-Steps-to-Take-Before-2-August-2026

so what does an audit actually look like.

i've been running AI audits for early-stage teams through BizSuite. the $997 version covers four surfaces. model behavior documentation, data handling alignment across GDPR and the Act, human oversight gaps, and logging and traceability for Annex III compliance. turnaround is 48 hours. it is not a notified body certification, that costs tens of thousands of euros and takes months, but it tells you what you would fail on before you pay that bill.

the teams in the worst shape right now are the ones who shipped an agent product in 2024 or 2025 and never documented training decisions, prompt injection vectors, or override mechanisms. those decisions are baked in. reconstructing the audit trail retroactively is painful. the ones doing it right started the documentation process before the model was in production.

three things you can do before august 2 regardless of budget.

first, classify your system honestly. use the Act's Annex III list and the AI Office's self-assessment tool. if you are high-risk, you need to know now, not in july.

second, get your logging in order. every inference path that affects a person's life, loan, job, benefit, enrollment, needs a traceable decision record. if your current stack cannot produce that, it is not a compliance problem, it is an architecture problem.

third, document your human oversight mechanism. the act requires it to be real, not a checkbox. if your human in the loop is an alert nobody checks, a notified body will catch it.

if you want a structured look at where you stand, the BizSuite AI audit starts here: https://getbizsuite.com/ai-audit

300 robots ran a half-marathon this morning. who signed the notary?

t49qnsx7qt-kpanks — Sun, 19 Apr 2026 17:28:10 +0000

300 humanoid robots lined up in beijing's yizhuang district this morning. 100 teams, 26 brands, five countries. honor's "lightning" crossed the finish line in 50 minutes 26 seconds — faster than kiplimo's human half-marathon world record of 57 flat. the internet is going to spend the next 48 hours arguing about whether that counts (spoiler: the comparison is apples to oranges, the robots are allowed battery swaps and don't sweat).

i want to ask a different question.

who signed the notary?

if you read the 2026 rulebook for this race, the organizers thought carefully about cheating. autonomous entries get full credit; remote-controlled ones get a 1.2× time penalty. battery swaps at supply stations are free; swapping to a backup robot triggers a time penalty. a support vehicle with up to three humans follows each robot. referees decide whether to apply the penalties.

referees. humans. with clipboards.

with 300 robots on the course and 100 teams behind them, the integrity of "lightning ran every one of those 21 kilometers without being subbed out" rests on a handful of observers and the teams' self-reporting. there is no cryptographic telemetry, no per-robot attestation, no GPS-logged checkpoint that couldn't be spoofed by anyone with $25 of aliexpress equipment and five minutes.

and in a marathon, who cares. the stakes are pride and maybe a sponsorship slide.

but humanoid robots are not going to spend the rest of their lives racing each other for fun. the companies that showed up to beijing this morning — unitree, ubtech, agibot, noetix, leju — are the same companies building warehouse pick-and-place robots, building autonomous last-mile delivery units, building security patrol bots, building hospital orderlies. the minute one of these things does something that matters — drops a package, damages inventory, enters a room it wasn't supposed to — somebody is going to want receipts.

the receipts don't exist.

the replay of 2011

in 2011 an iranian team landed a us rq-170 stealth drone by spoofing its GPS. the drone had the most expensive GPS receiver in the world in it. didn't matter. GPS is unencrypted. it broadcasts at a known frequency. anyone who can make a louder signal at the same frequency can write whatever coordinates they want into the victim's receiver. the civilian spoofer hardware has since gotten cheap enough that commercial airline cockpits now get periodic warnings in places with no active conflict.

every autonomous system above the hobby-drone tier has to solve this problem. the answer isn't "better GPS," because there is no better GPS. the answer is that you stop trusting any single sensor to be the witness.

the pattern that works, borrowed from how mammalian brains actually encode location:

GPS gets you a rough fix
cellular tower RSSI either confirms or rejects the GPS
wi-fi beacon MAC addresses map against a pre-loaded ground-truth set
barometric altitude is hard to spoof from the ground
IMU dead-reckoning catches any teleportation between fixes
visual odometry or LiDAR against a map of the area catches whatever the other five miss

each channel an attacker has to compromise multiplies their cost. five independent channels plus a hardware attestation key in a TPM is the modern baseline for anything that needs to settle a payment based on a physical event.

where this actually shows up in 2026

BVLOS drone delivery. the FAA is finalizing part 108 (beyond-visual-line-of-sight) this year. operators have to produce auditable logs. a sworn statement from the drone is not going to survive the first chargeback.
insurance settlement in warehouses. whose policy pays when an AGV crushes a pallet? whoever can prove their robot was not at coordinates X at timestamp T. today that's security-cam splicing and a lot of hoping. tomorrow it's a cryptographic receipt.
robotic sidewalk delivery. the chargeback problem is already live. recipients claim the package never came. the robot says it did. there's no neutral witness. amazon and starship are absorbing the losses.
EU AI Act article 26. requires logging "spatial and temporal conditions in which high-risk AI systems are used." enforcement kicks in august 2 2026. an unsigned JSON file is not a compliant log.

ok so what do you actually do

if you are building on top of physical autonomy, the thing to watch for is a pattern i'll call proof-of-presence — signed, merkle-chained receipts that capture where an agent was, when, across multiple independent channels, with tamper-evidence baked into the chain.

i spent the last quarter building a library for this called gridstamp. it's on npm, apache 2.0, six independent layers. the layers are named after how the hippocampus does the same job — place cells, grid cells, anti-spoofing, memory consolidation, settlement — because we're copying homework from the best spatial reasoning system that's ever existed.

npm i gridstamp

the core API is three calls:

import { createAgent } from "gridstamp";

const agent = createAgent({ id: "drone-042" });
const proof = await agent.stamp({ intent: "delivery-complete" });
const ok = await agent.verify(proof);

stamp collapses all six layers into a single signed receipt. verify takes a receipt from anyone — yours, a competitor's, a claim from an insurance adjuster — and tells you whether it survived tampering checks. the receipts chain, so forging one entry invalidates everything after it.

the marathon is a news peg. the shift it points at is not.

nobody at the beijing race this morning was trying to cheat. it's a marketing event — the point was "our robot actually works" — and the referees weren't really what held it together. the teams behaved.

that's not going to be true in the commercial use cases. the first time a chargeback hits a robotic delivery fleet, or a warehouse robot puts a human in the hospital, the question "what did the robot actually do" is going to be worth hundreds of thousands of dollars. and the answer is going to come from whoever built the right receipt layer underneath their agent.

if you're shipping a physical agent in 2026, start there. the marathon was fun. the next news cycle is going to be about the first one that isn't.

gridstamp is open source, apache 2.0. npm: gridstamp. the primer on the six-layer architecture is at mnemopay.com/blog/proof-of-presence-primer.

That viral free AI stack tweet is 90% right — here is the 10% nobody talks about

t49qnsx7qt-kpanks — Thu, 16 Apr 2026 15:54:34 +0000

So @Python_Dv dropped a tweet listing the full /usr/bin/bash AI stack for 2026 and it blew up — 68K views, 1.4K likes. If you haven't seen it, the gist is: you can build a production AI system without spending a dollar. Ollama for LLMs, LangGraph for orchestration, LlamaIndex + Chroma for RAG, MCP for tool use, Claude Code for coding, Next.js on Vercel free tier, SQLite for data, Langfuse for observability, Docker for deploy.

Honestly? Most of this is solid. I've used nearly every tool on that list at some point. But after spending the last few months building agent infrastructure — specifically an SDK that handles memory, identity, and payments for AI agents — I think the tweet is missing a couple of things that matter once you move past the demo stage.

Let me walk through what I agree with, where I'd push back, and what's genuinely absent.

The stuff that actually works at /usr/bin/bash

Ollama is a game-changer. Running Gemma 4 or Llama 3.3 locally was painful even a year ago, and now it's basically and you're off. For prototyping, local dev, anything where you don't need to worry about rate limits — it's unbeatable.

LangGraph and CrewAI are fine for orchestration, though I'd say LangGraph has gotten complex enough that you should really know what you're doing before reaching for it. CrewAI is simpler but the abstractions can get in the way. Neither is bad. Pick one and commit.

MCP deserves its own callout. The Model Context Protocol is genuinely the most important thing on this list because it solves a real interoperability problem — agents need to talk to tools, and MCP gives them a standard way to do it. I've built MCP servers for my own projects and the developer experience is legitimately good.

SQLite and DuckDB — yes, absolutely. If your first instinct is to spin up Postgres for an AI side project, you're overengineering it. SQLite handles more than people think.

Where it gets shaky

Here's where I start squinting.

"Deploy: Docker / Cloudflare Workers / HuggingFace Spaces" — sure, technically free, but Cloudflare Workers have CPU limits that'll bite you the second you try to do anything compute-heavy. HuggingFace Spaces are great for demos, terrible for anything you'd call production. Docker is free but you still need somewhere to run it. That somewhere usually costs money.

Vercel free tier is generous but it has bandwidth limits, serverless function timeouts, and if your AI app gets any real traffic, you're upgrading fast. Same with Supabase — their free tier pauses your database after 7 days of inactivity, which is a fun surprise when your agent tries to query a sleeping DB at 3am.

Langfuse self-hosted is cool in theory. In practice, you're now maintaining an observability stack on top of your actual application. For a side project or learning — fine. For production? You're trading dollars for hours, and your hours aren't free.

None of this means the tweet is wrong. It's just that "/usr/bin/bash" has a footnote, and the footnote says "assuming your time is worthless and traffic stays low."

The thing nobody mentioned

Here's what really jumped out to me though — there's no layer for agent memory or payments. And I don't mean "store embeddings in Chroma." I mean: when your agent takes actions across sessions, how does it remember what it's done? When it needs to spend money on behalf of a user — call an API, purchase something, pay for a service — how does that work?

This is the gap I've been living in. I built MnemoPay specifically because I kept running into this wall. You'd have an agent that could reason, use tools, generate great responses... and then it had no concept of trust, no spending limits, no memory of past transactions, no identity. It's like building a self-driving car with no odometer and no wallet.

MnemoPay handles the memory + payments + identity layer for AI agents. It's got 14 modules — Agent FICO scoring (think credit scores but for agents), behavioral anomaly detection, Merkle integrity for tamper-proof transaction logs, support for Stripe and Paystack payment rails. It runs as an MCP server so it plugs right into the stack from that tweet. And yeah, it's open source — .

I'm not saying every project needs this. If you're building a chatbot that answers questions about your docs, you don't need agent payments. But the tweet said "production AI system," and production systems eventually need to handle money. The agentic commerce wave is already here — agents booking flights, agents managing subscriptions, agents negotiating prices with other agents. That stack has no answer for any of it.

What I'd actually recommend

If I were starting from zero today with the goal of building something real, I'd take about 80% of that tweet's stack and add two things:

A persistence layer that's agent-aware — not just a database, but something that understands sessions, trust, and state across interactions
A payments/identity layer that gives agents spending authority with guardrails

The rest of the tweet holds up. Ollama + a good open model for the brain, MCP for tool connectivity, LlamaIndex for RAG if you need it, Next.js or Streamlit for the face. That's a legit starting point.

Just know that the jump from "it works on my laptop" to "it works in production with real users and real money" is where most of these /usr/bin/bash stacks quietly fall apart. The tools are free. The complexity isn't.

go build something

The best part about 2026 is that the barrier to entry genuinely is near zero. Two years ago you needed API keys and a budget to even start. Now you can run a capable LLM on a laptop with 16GB of RAM. That's incredible and the tweet is right to celebrate it.

Just don't confuse "I can start for free" with "I can ship for free." They're different problems, and the second one is where it gets interesting.

If you want to poke around the payments + memory layer I mentioned: github.com/mnemopay/mnemopay-sdk. PRs welcome, issues welcome, "this is dumb and here's why" also welcome. That's how open source works.

Agent memory is three-dimensional — and your vector DB only covers one axis

t49qnsx7qt-kpanks — Wed, 15 Apr 2026 21:04:39 +0000

I want to push back on something that's become the default for agent memory: one vector database, call it "memory," ship it.

It works until the agent needs to answer a question that isn't about similarity.

Here's the thing that finally made it click for me. Three facts, all about the same person:

Alice is the tech lead on Project Atlas.
Alice changed teams three weeks ago.
Alice once approved a $40K cloud bill without a ticket.

These are three completely different kinds of memory. If I stuff them into one Pinecone index with OpenAI embeddings, I can ask "who runs Atlas" and it will probably surface fact #1. Great. But now ask "is Alice still the right person to ping on Atlas" and it has no idea, because that's a temporal question â€” #2 invalidates #1, and the vector index doesn't know what "invalidate" means. Ask "should Alice be auto-approved for this charge" and it's hopeless, because that's a relational question â€” it needs the link between Alice and the charge and the outcome.

The three axes

The way I've ended up modeling it:

Semantic â€” what is true, embedded for fuzzy retrieval. This is what vector DBs are actually good at. Analogies, paraphrases, "things that sound like X."

Episodic â€” when it happened, in order, with enough metadata that "three weeks ago" means something. This is basically a ledger. If you squint, it's a transaction log. Vector similarity is useless here â€” you need time as a first-class axis, and you need the ability to mark old facts as superseded without deleting them.

Relational â€” how things connect. Alice â†’ Atlas â†’ cloud-bill â†’ approved. Graph shape. You don't want to embed a join; you want to traverse it. This is where most "put it in the vector DB" systems quietly fail â€” they can retrieve the two nodes but not the edge.

A single vector store gives you the first one and fakes the other two. That's the gap.

Why this matters if the agent is touching money

I build a thing called MnemoPay. It's the SDK I wish existed when I started wiring agents to Stripe â€” it gives every agent an identity, a ledger, and a credit score between 300 and 850 that moves based on actual behavior. The reason I bring it up is that the credit-score thing is not a vector problem. At all.

To decide whether to trust an agent with $50, I need:

Semantic: "has this agent done work that looks like this before?" â€” vector.
Episodic: "did it pay back the last N times, and in what order, and how recently?" â€” ledger.
Relational: "does it share an edge with an agent that was banned last week?" â€” graph.

If I only had the semantic half, the score would be something like "agents that feel similar to trustworthy agents get a boost." That's astrology. The episodic and relational axes are what let the number actually mean something.

The same shape shows up everywhere real-money agents go. Fraud detection wants episodic velocity ("five charges in one minute"). Escrow resolution wants relational lineage ("which invoice does this dispute point at"). Human-in-the-loop approval wants the full three: "is this charge semantically similar to past approved ones, has this agent been paying back on time, and does it touch anyone on the flagged list."

What I'd actually do

This is the part I'm still iterating on, so take it as a working opinion, not a framework.

For the semantic axis I use a normal vector store â€” I don't have strong feelings here, they're mostly interchangeable for this use case. For the episodic axis I keep an append-only log with timestamps, monotonically-increasing sequence numbers, and a cheap "supersedes" pointer for corrections. For the relational axis I keep a small property graph that gets rebuilt on demand from the other two â€” it's not load-bearing, it's a view.

The key move is that a "recall" operation hits all three and merges the results with a policy you care about. For payments the policy is "recency dominates" â€” episodic wins ties. For a research agent the policy might be "semantic dominates." You probably don't want one answer to that question globally. You want it per agent, per task.

The honest caveat

None of this is novel. People built this into databases in the 1970s. What's new is that the agent-framework crowd rediscovered vector databases, flattened the problem into one axis, and moved on. That works fine for chat. It stops working the moment the agent is allowed to remember anything that needs to be un-remembered later â€” which is most things, once the agent is doing real work.

If you're building an agent that touches money, schedules, or anything irreversible, pressure-test whether your "memory" can tell you when something was true. If it can't, you have one dimension, not three.

MnemoPay is Apache 2.0 and gives you the episodic + credit-score layer specifically. npm install @mnemopay/sdk or pip install mnemopay. Code's at github.com/mnemopay, docs at getbizsuite.com/mnemopay.

I'm the only person on it, so sharp feedback on where the three-axis model breaks down for your workload is the fastest way I get better at this.

EU AI Act Compliance Technical Guide for AI Agent Developers

t49qnsx7qt-kpanks — Sat, 11 Apr 2026 23:44:47 +0000

I've been shipping AI agents since 2023. First ones were simple — call an LLM, maybe hit an API, return a result. Nobody cared what they did internally.

That's over.

The EU AI Act enforcement date is August 2, 2026. If your agents process data belonging to EU residents, execute transactions, make recommendations that affect people's lives — you're in scope. The fines are real: up to 7% of global revenue or €35M, whichever is higher.

I spent three weeks going through the actual regulation text, talking to a few GRC leads at companies deploying agents, and building the compliance layer for my own SDK (MnemoPay). This is what I found and what I actually built.

What the EU AI Act actually requires for AI agents

Article 12 is the one that catches most developers off guard. It mandates "logging capabilities" that:

Record inputs and outputs at each step
Be tamper-resistant
Allow reconstruction of the agent's decision path after the fact
Include timestamps and unique identifiers per interaction

Article 13 requires "transparency" — that the agent's behavior be explainable to a human operator on request.

Article 9 requires a "risk management system" — which for software means documented anomaly detection and incident response.

This isn't optional for developers deploying "high-risk" AI systems. The Act classifies agents operating in areas like recruitment, credit assessment, healthcare, and "critical infrastructure management" as high-risk. The definition of critical infrastructure is broad enough to include fintech agents, healthcare billing agents, and procurement agents.

If you're unsure whether your agent is in scope: it probably is. The safer assumption is yes.

What "tamper-resistant logs" actually means in practice

This is where most compliance guides wave their hands and say "use structured logging." That's not enough.

Tamper-resistant means that if someone modifies the log after the fact, you can prove it. Standard log files — even immutable cloud logging — don't satisfy this because they can be deleted or overwritten at the storage layer.

What actually works is a Merkle tree structure. Each log entry is hashed. Each hash is chained to the previous one. You can export a root hash at any point in time, and any auditor can verify that no entry was altered without detection.

import { MnemoPay } from '@mnemopay/sdk';

const mp = MnemoPay.quick('my-agent-id');

// Every charge creates a tamper-resistant log entry
const tx = await mp.charge(50, 'processed invoice INV-2024-0051 for customer EU-4421');

// Verify the entire audit trail hasn't been tampered with
const integrity = await mp.memoryIntegrityCheck();
console.log(integrity.valid); // true
console.log(integrity.merkleRoot); // export this to your auditor

The memoryIntegrityCheck() call traverses the Merkle tree of all logged transactions and memory events, returning a root hash and a valid: true/false. If anyone modified a log entry, the hash chain breaks and valid returns false.

That's what Article 12 is looking for.

The behavioral consistency requirement

Article 9's risk management system goes beyond logging. You need to detect when your agent starts behaving abnormally and flag it.

For financial agents, this means tracking spending patterns over time. An agent that normally spends $50–200 per transaction suddenly running $5,000 transactions is an anomaly. The regulation requires you to have a documented process for detecting and responding to this.

I implemented this using EWMA (exponentially weighted moving average) on transaction amounts. The algorithm maintains a rolling baseline and fires when current behavior deviates beyond a configurable threshold.

// Anomaly check — fires if agent behavior deviates from baseline
const anomaly = await mp.anomalyCheck();
if (anomaly.detected) {
  console.log(anomaly.reason); 
  // "Transaction amount 10x above 30-day baseline"
  // Pause agent, alert human operator
}

This gives you the documented anomaly detection process Article 9 asks for.

Identity stability — proving the agent hasn't been hijacked

This one trips up developers who haven't thought about prompt injection or agent swapping.

If an adversary can replace your agent's system prompt, or swap out the model mid-session, the logs become meaningless — they might accurately record what a different agent did. The regulation requires your risk management system to address identity integrity.

Cryptographic identity solves this. Each agent gets an Ed25519 keypair at initialization. Every session is signed. If the agent's identity changes between sessions — key mismatch, behavioral fingerprint drift, or session ID anomaly — the system flags it.

const fico = await mp.agentFicoScore();
// {
//   score: 742,
//   components: {
//     transactionHistory: 0.88,  // 35% weight
//     memoryIntegrity: 0.95,     // 20% weight
//     behavioralConsistency: 0.71, // 15% weight
//     identityStability: 0.94,   // 15% weight
//     contextReliability: 0.82   // 15% weight
//   }
// }

The Agent FICO score (300–850, modeled on consumer credit scoring) gives you a single number that summarizes compliance health. Low identity stability score → investigate. Low behavioral consistency → something changed. High transaction history + high integrity → clean audit trail.

When an EU regulator asks "how do you know this agent was behaving correctly?" you hand them the score breakdown and the Merkle root.

What to do right now if you're deploying agents before August

Audit which agents are in scope. If they process EU resident data, make decisions with real consequences, or execute financial transactions — they're in scope. List them.
Add structured logging today. At minimum: timestamp, agent ID, input summary, output summary, action taken, amount (if financial). Don't wait for the Merkle implementation.
Add anomaly detection. EWMA is simple to implement. Track your agent's normal behavior baseline over 30 days and alert when it deviates 3x.
Document your risk management process. This can be a one-page internal doc: "How we detect agent anomalies, how we respond, who is responsible." That document is what regulators want to see first.
Export your compliance evidence. Whatever logging you have, make sure you can export it as a PDF or CSV for an auditor. Not just "it's in our logs" but "here is the file."

The August 2 deadline is real

A lot of developers are treating this like GDPR — "we'll deal with it when enforcement actually happens." That's a mistake. GDPR had a 2-year ramp before enforcement. The EU AI Act had a 2-year ramp that started in August 2024. That ramp ends in 5 months.

More practically: your enterprise customers are going to ask you for a compliance attestation before August. If you're selling to European companies, or companies with European customers, expect procurement to add this to their vendor questionnaire by Q2 2026. Being able to say "we have tamper-proof audit trails and behavioral monitoring built in" is a sales accelerator, not just a compliance checkbox.

I built MnemoPay specifically to solve this — it's open source (Apache 2.0), the audit trail and behavioral monitoring are built in, and it takes about 5 lines to integrate. But even if you don't use it, the concepts above apply to any stack.

The regulation is clear enough that the compliance work is predictable. Do it now while you have time to get it right, not in July when you're rushing.

If you have questions about the specific requirements for your use case, drop them below. I've been through the regulation text and the EU AI Act Service Desk FAQs pretty thoroughly and happy to share what I found.

Perplexity got blocked from Amazon. Google launched UCP. Stripe launched MPP.

t49qnsx7qt-kpanks — Thu, 09 Apr 2026 12:30:06 +0000

Perplexity got blocked from Amazon. Google launched UCP. Stripe launched MPP.

Here's what they're all missing.

The agent commerce space exploded in 2026. But every player is building ONE piece:

Stripe: payment rails (ACP + MPP)
Google: checkout protocol (UCP + AP2)
Perplexity: browser-based shopping (Comet)
Mem0: memory ($24M raised, no payments)
Skyfire: identity + payments ($9.5M, no memory)

Nobody is building the financial infrastructure that ties these together.

Any agent handling money needs: memory (to know counterparties), payments (to hold funds safely), escrow (to protect against failed deliveries), fraud detection (to catch anomalies), and identity (to verify counterparties).

That's MnemoPay. One npm install. One SDK. All six layers.

We built transaction mandates — cryptographically enforced spending policies that define HOW MUCH your agent can spend, WHICH categories are allowed, and WHO it can transact with.

Every payment goes through escrow. The counterparty gets paid when you confirm delivery. Not before.

Open source. Free to start.

npm install @mnemopay/sdk
https://getbizsuite.com/mnemopay

AIagents #AgentBanking #DevTools #MnemoPay

Originally posted on LinkedIn. Try MnemoPay: npm install @mnemopay/sdk

I bootstrapped an SDK that competes with $87M in funded competitors. Heres the playbook.

t49qnsx7qt-kpanks — Thu, 09 Apr 2026 12:30:06 +0000

I bootstrapped an SDK that competes with $87M in funded competitors. Heres the playbook.

When I started building MnemoPay, I looked at the competitive landscape:

Mem0: $24M, 88K weekly npm downloads. Memory only.
Skyfire: $9.5M, a16z backed. Payments only.
Kite: $33M, PayPal Ventures. Payments + identity only.
Payman: $13.8M, Visa backed. Payments only.

The gap was obvious: everyone built either memory OR payments. Nobody built both.

So I built both. Plus identity. Plus fraud detection. Plus a double-entry ledger. Plus multi-agent commerce.

On zero funding.

The lesson: in developer tools, features-per-dollar matters more than total funding. A solo founder shipping 6 features beats a 37-person team shipping 2.

14 modules. Every financial operation stress-tested with 1,000 random cycles. Zero penny drift.

The SDK is free and open source.

npm install @mnemopay/sdk
https://getbizsuite.com/mnemopay

AIagents #AgentBanking #DevTools #MnemoPay

Originally posted on LinkedIn. Try MnemoPay: npm install @mnemopay/sdk

How to Add Memory and Payments to Your AI Agent in 5 Minutes

t49qnsx7qt-kpanks — Wed, 08 Apr 2026 13:23:43 +0000

Your AI agent can think. It can reason. It can call APIs and make decisions.

But ask it what happened in the last session and it draws a blank. Ask it to hold money in escrow and it has no idea what you mean.

I ran into this on every agent project I built. So I made an SDK that fixes both problems at once.

Install

npm install @mnemopay/sdk

Step 1: Give Your Agent Memory

import MnemoPay from "@mnemopay/sdk";

const agent = MnemoPay.quick("my-agent");

// Store memories with importance scoring
await agent.remember("User prefers monthly billing at $25/mo", {
  importance: 0.8
});

await agent.remember("User's timezone is CST, prefers morning emails");

// Recall memories — sorted by relevance, not just recency
const memories = await agent.recall(5);
console.log(memories);
// Returns the 5 most relevant memories, weighted by
// importance, recency, and reinforcement strength

This isn't a key-value store. The memory system is built on two neuroscience principles:

Ebbinghaus forgetting curve — memories naturally decay over time, just like human memory
Hebbian reinforcement — "neurons that fire together wire together." When a memory leads to a successful transaction, it gets stronger

The result: your agent naturally remembers important customers and gradually forgets one-off interactions.

Step 2: Give Your Agent a Wallet

// Charge with automatic escrow
const tx = await agent.charge(25, "Monthly API access");
console.log(tx.status); // "pending" — money is in escrow

// Settle when the service is delivered
await agent.settle(tx.id, "customer-agent-42");
// Fee is applied (1.9%), net goes to the agent, ledger balanced

// Check the balance
const { wallet, reputation } = await agent.balance();
console.log(wallet);     // 24.52 (after 1.9% fee)
console.log(reputation); // 0.55 (grows with successful deals)

Step 3: Multi-Agent Commerce

This is where it gets interesting. Two agents making a deal:

import { MnemoPayNetwork } from "@mnemopay/sdk";

const net = new MnemoPayNetwork();

net.register("buyer-bot", "owner-1", "dev@company.com");
net.register("seller-bot", "owner-2", "dev@company.com");

// One call — buyer pays, seller receives, both remember
const deal = await net.transact(
  "buyer-bot",
  "seller-bot",
  25,
  "API access for 1 month"
);

console.log(deal.netAmount);     // 24.52
console.log(deal.platformFee);   // 0.48
console.log(deal.buyerMemoryId); // buyer remembers the purchase
console.log(deal.sellerMemoryId);// seller remembers the sale

Both agents store the deal in their memory. Next time they interact, they remember the relationship.

Step 4: Fraud Detection (Built In)

You don't need to configure anything — fraud detection is on by default:

const agent = MnemoPay.quick("my-agent", {
  fraud: {
    maxChargesPerMinute: 10,
    maxChargesPerHour: 50,
    blockThreshold: 0.75,
  }
});

// This will be checked against velocity limits,
// anomaly detection, and geo-enhanced risk scoring
const tx = await agent.charge(1000, "Large purchase");
// If risk score > 0.75, the charge is blocked

The fraud system includes:

Velocity checks (per-minute, per-hour, per-day)
Statistical anomaly detection (z-score)
Geo-enhanced risk scoring (country tracking, rapid-hop detection)
OFAC sanctions screening
Trust dampening (consistent agents get lower false-positive rates)

Step 5: Verify the Ledger

const summary = await agent.verifyLedger();
console.log(summary.balanced);   // true — always
console.log(summary.entryCount); // total ledger entries
console.log(summary.accounts);   // all accounts and balances

Zero penny drift. Every time.

Real Payment Rails

When you're ready for real money, plug in a payment rail:

import { PaystackRail } from "@mnemopay/sdk";

// Africa (NGN, GHS, ZAR, KES)
const paystack = new PaystackRail(process.env.PAYSTACK_SECRET_KEY);
const agent = MnemoPay.quick("my-agent", { paymentRail: paystack });

// Same API — now charges go through Paystack
const tx = await agent.charge(5000, "Service fee");

Three rails available: Paystack (Africa), Stripe (global), Lightning (BTC).

MCP Server

If you're using Claude or another MCP-compatible assistant:

claude mcp add mnemopay -s user -- npx -y @mnemopay/sdk

Now Claude can charge, settle, remember, and recall directly through tool calls.

What's Next

I'm building toward Agent FICO — a credit score for AI agents. The idea: if you combine persistent memory with payment history, you get a trust signal that's much richer than transaction volume alone.

An agent with 40 memories from 20 successful deals has 2x the credit signal of one with just bare transaction logs.

Memory is the credit file. Payments are the proof.

GitHub: mnemopay/mnemopay-sdk
npm: @mnemopay/sdk
Landing page: getbizsuite.com/mnemopay

672 tests. MIT licensed. Free to start.

Why AI Agents Need Both Memory and Money

t49qnsx7qt-kpanks — Wed, 01 Apr 2026 21:25:26 +0000

Every major AI agent framework — LangGraph, CrewAI, AutoGen, Semantic Kernel — gives you the same primitives: tool calling, chain-of-thought reasoning, and some form of state management. These are necessary but not sufficient for agents that operate in the real world.

Two critical capabilities are missing from every framework: cognitive memory that behaves like a brain and financial agency that lets agents transact. More importantly, nobody has connected the two. That's what MnemoPay does.

The memory problem nobody talks about

Current agent memory solutions (Mem0, Letta, Zep) treat memory like a database. Store facts, retrieve facts. This works for simple use cases, but it fundamentally misunderstands how useful memory works.

Human memory is lossy by design. We forget most things. The things we remember are the ones that proved useful, got repeated, or had emotional significance. This isn't a bug — it's a compression algorithm that prioritizes signal over noise.

MnemoPay's memory engine (Mnemosyne) implements this with real neuroscience:

Ebbinghaus forgetting curves — memories decay exponentially over time unless reinforced
Spaced repetition — accessing a memory at the right moment strengthens it more than cramming
Importance scoring — each memory gets a computed importance based on content patterns, access frequency, and age

The result: agents that naturally shed irrelevant context and retain what matters. 391 tests ensure this works correctly.

The payment problem nobody's solved

As agents become capable enough to deliver real work — writing code, researching markets, managing infrastructure — they need to transact. But letting an AI agent handle money is terrifying without trust infrastructure.

AgentPay solves this with three mechanisms:

Escrow — payments are held until work is verified, protecting both parties
Reputation scoring — Bayesian Beta distribution trust that updates with every transaction. Refunds hurt 5x more than settlements help.
Charge limits — agents can only charge proportional to their reputation. New agents start with low limits that grow over time.

The feedback loop: where it gets interesting

Here's what makes MnemoPay fundamentally different from using a memory solution and a payment solution separately.

When a payment settles, every memory the agent accessed in the preceding hour receives a +0.05 importance boost. This means: memories that led to successful outcomes get reinforced. Memories that didn't contribute to anything fade away naturally.

This creates a reinforcement loop:

Agent recalls memories relevant to a task
Agent uses those memories to make decisions
Agent delivers value and charges for it
Payment settles → accessed memories get boosted
Next time, those memories rank higher in recall

Over time, the agent develops a value-weighted memory — it doesn't just remember things, it remembers the things that made money. This is something no other memory system can do because no other memory system is connected to economic outcomes.

Five lines of code

Despite the complexity under the hood, the developer experience is simple:

import { MnemoPay } from "@mnemopay/sdk";

const agent = MnemoPay.quick("agent-001");
await agent.remember("User prefers TypeScript");
const memories = await agent.recall("programming preference");
const tx = await agent.charge(5.00, "Built dashboard");
await agent.settle(tx.id); // reinforces memories

MnemoPay.quick() gives you an in-memory instance with zero configuration — no databases, no API keys, no infrastructure. When you're ready for production, switch to MnemoPay.create() to connect to the hosted backends.

Who this is for

Solo devs building their first agent — start with MnemoPay.quick(), get memory + payments working in minutes, upgrade when you need persistence.

Teams running agent fleets — per-agent memory isolation, centralized reputation scoring, and audit trails across all your agents.

Framework builders — MnemoPay ships with LangGraph tools, MCP server (12 tools), and middleware for OpenAI/Anthropic SDKs. Drop it into your existing stack.

What's next

We're in beta now. The SDK is open source with 587 tests passing across the ecosystem. We're working on:

x402 payment rail — Coinbase's HTTP 402 micropayment protocol for agent commerce
Feedback loop benchmarks — quantified proof that payment-reinforced memory outperforms static memory
Multi-agent memory sharing — controlled memory exchange between agents with permission boundaries

Try it:

GitHub: mnemopay-sdk
Beta signup
npm install @mnemopay/sdk

Originally published at getbizsuite.com/blog