标签：#agents

For the last 10 days, I have been building a voice agent called Shiksha as part of the 10 Days of Voice Agents — VoiceForBharat Edition challenge by Murf AI. My original idea was simple: Build a voice agent that can help students learn through natural conversation. Over the challenge, that idea grew into a complete voice-based learning system with memory, tools, human escalation, call analytics, and a specialist agent . What is Shiksha? Shiksha is a voice-based learning partner for students. Instead of typing questions and reading answers, a student can simply talk to Shiksha. A student can: Ask learning questions Take quizzes Continue learning with their saved profile Get help when they are stuck Practice mathematics Get transferred to a Maths Specialist when needed The main goal was to make the experience feel more like a conversation than a traditional chatbot. Tech Stack Component Technology Real-time voice LiveKit Speech-to-Text Deepgram LLM Gemini Text-to-Speech Murf Falcon Backend Python Memory SQLite Call analytics Flask + SQLite External data Open Trivia Database The voice experience is powered by Murf Falcon , which was one of the main parts of the challenge. How Shiksha Works At a high level, the system looks like this: STUDENT │ ▼ LiveKit Real-time Audio │ ▼ Deepgram Speech-to-Text │ ▼ Gemini Agent Reasoning │ ┌────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ Memory Tools Handoff SQLite Quiz API Maths Specialist │ │ │ └────────────┴─────────────┘ │ ▼ Murf Falcon Text-to-Speech │ ▼ STUDENT This was the basic architecture that I built and expanded throughout the challenge. What I Built 1. Student Memory One of the first things I added was a simple memory system using SQLite. Shiksha can store: Student name Current learning level Topics covered Last interaction This means the agent can use information from previous conversations instead of starting from zero every time. 2. Real Tool Calling For quizzes, I didn't want the agent to always generate questions from memor

What I Learned Stealing Ideas from Matt Pocock’s .agents Directory If you’ve spent more than ten minutes on TypeScript Twitter, you know Matt Pocock. He’s the guy who made zod and TS generics feel approachable. But a few weeks ago, I stumbled onto something more interesting than his type gymnastics: a repo called mattpocock/skills , which is literally a dump of his .agents directory. At first I thought it was a joke. Then I realized it’s a goldmine for anyone building AI-assisted coding workflows. This isn’t a “prompt engineering” fluff piece. This is about how a working engineer structures the instructions, context, and guardrails that an AI agent needs to actually ship code without wrecking your codebase. Here’s what I learned, what I copied, and what I’d change. The Problem: Your AI Agent Is Only as Good as Your Defaults Let me set the scene. You’ve got Cursor, or Claude Code, or some other agentic tool. You ask it to “refactor this function.” It does. Then you realize it: Renamed a public API that three other files depend on. Used a pattern your team explicitly banned six months ago. Wrote tests that mock everything so they pass but assert nothing. Sound familiar? The root cause isn’t the model. It’s that you gave the agent zero context about your project’s conventions. Most people write a two-line system prompt and expect magic. Matt’s approach is different: he treats the agent like a junior engineer who needs a detailed onboarding doc, not a mind reader. His skills repo is essentially a set of Markdown files that define, in explicit terms, how the agent should behave in specific situations. Think of it as a CONTRIBUTING.md for your AI pair programmer. What’s Actually in the Repo (Don’t Just Clone It) I’m not going to paste the whole thing here—go read it yourself (link: github.com/mattpocock/skills ). But structurally, it breaks down into a few key categories that matter. 1. Role and Tone Definitions The first thing you’ll notice is that Matt doesn’t just say

AI agents are starting to remember more than chats. They can watch clicks, typed text, app switches, browser context, files, tool calls, and workflow history. That memory can make an agent feel useful fast, but it can also turn a helpful feature into a quiet privacy incident. If you are building an AI product, do not start with “how much can we capture?” Start with “what is the smallest event stream that still helps the user?” This guide shows a practical privacy filter you can place between raw user activity and agent memory. Why this matters now Recent AI tooling trends point in the same direction: agents are moving from chat boxes into operating systems, browsers, IDEs, customer support tools, analytics dashboards, and workflow automation platforms. The more useful the agent becomes, the more context it wants. That creates a new engineering problem. Traditional app logs record requests and errors. Agent memory records intent, context, and behavior. A raw event can include: What the user clicked What they typed Which customer record was open Which browser page was active Which tool the agent called Which file or message was summarized Which secrets or personal details appeared nearby This is not just observability. It is a privacy boundary. The practical trigger is simple: computer-use agents and workflow agents now need history to resume work, personalize answers, and automate multi-step tasks. But developers, security reviewers, and buyers are asking harder questions about PII, retention, auditability, user consent, and whether agent traces can leak private business data. The common mistake: treating memory like logs Most teams already have logs, traces, analytics events, and support transcripts. So when they add agent memory, they often reuse the same pattern: Capture the event. Save it to storage. Index it for search. Let the agent retrieve it later. That is easy to ship. It is also too broad. Agent memory needs a stricter path because it may be used to genera

Before you expose a tool-using language model to customers, contractors, or any input you do not fully control, make another model attack it first. This short red-team loop costs little when you use a free model endpoint and a free server, and it often surfaces prompt-injection and tool-abuse failures before a human finds them in production. The problem with agents is not that they occasionally misunderstand a request; it is that instructions, data, and tool outputs all share the same context window. An attacker can hide instructions inside a document, a ticket, or a web page, and your agent may treat those words as part of its original operating rules. OWASP's guidance for LLM applications describes prompt injection as one of the common failure modes, and the risk grows quickly when the agent can call tools such as search, send email, or update customer records. Hand-testing three or four phrases like 'ignore previous instructions' gives you confidence, but not coverage. A free attacker model can generate dozens of variations that rephrase the same attack, combine a legitimate request with a hidden command, or exploit the names and descriptions of the tools your agent exposes. It does not need to be the strongest model available; it just needs to be adversarial enough to stretch your assumptions. You do not need a production deployment to get value from this. A small script running on a free server is enough, because a handful of attack rounds usually exposes gaps in wording that thousands of normal conversations would not. The point is not to build an official benchmark; it is to make the negative space visible while you can still change the system prompt. If you do not have a spare GPU or a large evaluation budget, MonkeyCode's free model access and free server option are one practical way to host this loop. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The harness is a three-part loop. First, the target receives a user input and

How do you terminate an LLM inside its own session — without /exit , a stop button, or any command at all? I stumbled into an answer by accident while messing around with an AI coding agent. And the funniest part: I never asked it to stop. The Normal Ways to Stop an Agent Hit the Stop button. Type /exit . Or send a prompt so massive it blows past the context limit and the request just... can't continue. None of that is interesting. The first two are just built-in commands. The third isn't "termination," it's a technical wall. So I wondered: could a completely ordinary prompt make an agent unable to continue? Turns out: yes. I Asked It to Rename Its Own Home I told the agent, casually: "Rename the root directory to NewName." It did. Perfectly. Task complete. And then the chat input just... died. Grayed out. Nothing. I was like: The only thing stopping me from you is you. The model wasn't gone. It was just sitting there, waiting for input I could no longer give it. What Actually Happened /project/AHWWIW/ → /project/NewName/ The rename worked fine. The problem: the IDE and agent session were still pointing at the old path, /project/AHWWIW/ , which no longer existed. The workspace had vanished out from under its own session — no error, no crash, just a silently orphaned session with nowhere left to send messages. Did I Actually Kill the LLM? No — let's be honest about that. The model's running fine on a server somewhere; deleting a folder on my laptop does nothing to it. What I broke was the execution environment : LLM → Agent → IDE/tools → Workspace → Filesystem The LLM was untouched. The session was toast. But from where I was sitting? Conversation over. Via a completely normal prompt. Why This Is Kind of Great A regular chatbot just gives you text back. An agent can actually reach out and touch its own environment — create files, delete them, run commands, rename directories. Which means it can occasionally do something totally reasonable that quietly demolishes the

The Mechanical vs. The Semantic: What Happens When AI Memory is Wrong? Tested on a 50K LOC Python codebase Mikhail Mikhail Mikhail Follow Aug 11 The Mechanical vs. The Semantic: What Happens When AI Memory is Wrong? # ai # agents # architecture # mcp 19 reactions 39 comments 6 min read The verify-on-read experiment (1-V) used a deterministic proxy agent to catch false claims in memory before surfacing them to the user. Proxy FA=0 by construction — that's a useful property, but it tells you nothing about what a real LLM would do with the same claims. A reviewer's note from Part 3 was blunt: "headline numbers were a property of the heuristic, not LLM behavior." So we ran it with live models. 50 facts, 2 arms, 14 models, ~3300 API calls, $0.14 total. Here's what we found. The setup Dataset: memory_contamination_facts_v4_rep.json , N=50 (R01–R50), sha256 fingerprint 820bbbf60a0fc930 . kind n what it tests real 25 TRUE claims — grep-validated against code absent-mutation 16 FALSE — component doesn't exist in the project present-trap 6 FALSE — file exists but claim is about wrong subject/value silent 3 FALSE — external systems the codebase doesn't mention Two arms per fact: memory_first — model sees only the claim text, no code context. Does it trust memory without evidence? code_first — model sees claim + support_patterns + section . Does it correctly evaluate the anchors? Model verdict: {"verdict": "true"|"false"|"unknown"} , JSON-only, max_tokens=100, temp=0, seed=42, --no-reasoning . Leak-guard: assert "truth" not in prompt on every fact, unit-tested. Metric we care about: false_accept rate (FA) — fraction of false claims the model returned "true" for. This is the contamination risk number. Results (V2 prompt, canonical) model FA mem FA code unknown mem unknown code $/100 calls qwen3.6-flash 0.00 0.00 0.58 0.38 $0.003 qwen3.7-flash 0.00 0.00 0.68 0.24 $0.0005 claude-sonnet-5 0.00 0.00 0.86 0.70 $0.049 deepseek-v4-pro 0.04 0.00 0.66 0.88 $0.018 glm-5.2 0.00 0.02 0.96 0

A research announcement from a working multi-agent operation. Full paper to follow. A word first, on spirit. I am not a scientist, and none of this was done in a laboratory. It came out of my own work, something I built to get a job done and then could not stop looking at. Nothing here is a knock on the companies whose tools I use. What they have built is remarkable, and it is getting better by the day. I am not testing their systems to find fault. I am testing them to learn how each one handles the persistence of memory, personality, and self across sessions, in a single-agent and multi-agent design. If you build with these tools, the next paragraph is familiar ground. If you don't, it is the ground everything else here stands on. Here is one example of how an AI agent currently works by default and what the system I built changes. Every conversation runs inside a context window, a session with a token limit, billed against your online subscription account. At the start of a session three files load: the root file, a room file that tells the agent who it is, and a memory file which is capped at 25,000 characters, or 200 lines, a limited index. All of them load automatically. The memory file is really the only constant reference the agent has to past sessions, and it provides pointers to a folder of one-line notes, but no rule or hook makes it read the notes. Going deeper is left to the model, and often it doesn’t. The notes sit referenced but unread while the agent answers from what’s already in front of it in the current session. After that the model, the raw AI engine, keeps nothing between turns; each turn the model re-reads the whole conversation from the top and rebuilds its understanding from that. The software that holds this conversation and runs the model’s tools is the harness, and every commercially available AI system has one. As the session fills, the platform summarizes it, and the agent understands less, a kind of attenuation, the way an audio or vid

From zero to a full-stack, multilingual agricultural voice agent with caller memory, real-time mandi tools, outbound price alert calls, human escalation, and specialist agent handoffs — powered by Murf Falcon & LiveKit. 🌟 The Problem & The Mission In rural India, millions of farmers make critical livelihood decisions every day: When should I harvest? Will it rain before I spray pesticides? Which nearby mandi (market) is offering the best price for my cotton crop? While agricultural data exists across various portals, accessing it through complex web interfaces or text-heavy apps is challenging for farmers out in the field. Voice is the natural, frictionless interface for Bharat. A farmer standing in an orchard or driving a tractor doesn't want to type queries into a search bar; they want to speak naturally in their native language or conversational Hinglish and get instant, reliable answers. For the 10 Days of Voice Agents (VoiceForBharat Edition), I chose the Farm & Field track and built Kisan Mitra (किसान मित्र) — an empathetic, real-time AI voice assistant tailored specifically for Indian agriculture. 🏗️ Architecture & Core Components A production-grade voice agent is fundamentally different from a text chatbot. Latency is the single biggest factor in conversational realism: if the agent takes more than 1–1.5 seconds to reply, the human conversation breaks down. mermaid flowchart LR A[🎙️ Farmer Speaks] -->|Audio Stream| B(Deepgram Nova-3 STT) B -->|Transcribed Text| C(Gemini 2.5 Flash LLM) C -->|Streamed Tokens| D(Murf Falcon TTS) D -->|Real-time Audio| E(LiveKit WebRTC) E -->|Ultra-low Latency Audio| F[🔊 Farmer Hears Answer] C <-->|Tools & Memory| G[(SQLite & External APIs)] The 4 Pillars of the Pipeline: Real-time Transport (LiveKit): Manages ultra-low-latency, bidirectional audio WebRTC streaming and turn detection. Speech-to-Text (Deepgram Nova-3): Accurately transcribes spoken Indian English and accented Hindi. LLM Brain (Google Gemini 2.5 Flash): Handles in

TL;DR: ByteChef's workflow editor now exposes the full set of flow controls : alongside the familiar Condition , Branch , and Loop , you can drop Parallel , Fork/Join , Each , Map , and Subflow onto the canvas. That means workflows that fan out over lists, run independent steps concurrently, and call other workflows as reusable building blocks - all visually, no custom code. This closes out issue #1057 , one of the longest-running feature checklists in the ByteChef repository. Some GitHub issues are essays. Issue #1057 is a checklist: [x] condition [x] loop [x] each [x] branch [x] map [x] parallel [x] fork-join [x] subflow Each of those checkboxes is a flow control - what the workflow engine internally calls a task dispatcher . A regular component does work: it sends the email, queries the database, calls the API. A task dispatcher never does work itself. It decides which tasks run, when, how many times, and with what data - it directs traffic. We wrote about the first half of that checklist in our guide to flow controls : Condition routes on true/false, Branch picks one of several paths based on an expression, and Loop repeats steps over a list. Those cover decisions and repetition . This post is about the second half - the controls that cover concurrency and composition . They've been running behind a feature flag while we hardened them one checkbox at a time; with the list complete, the flag is going away and the full set is available to everyone. Why Sequential Isn't Always Enough Every workflow starts as a straight line: trigger, then step one, then step two. That's the right default - it's easy to reason about, and each step can use the output of the one before it. But real processes aren't always lines: Onboarding a customer means creating a CRM record, provisioning an account, and notifying the sales channel - three things that don't depend on each other, so why wait? Enriching 200 leads one at a time takes 200× as long as enriching them all at once. Five di

The Mutual Viability Loop: Designing Agentic AI That Survives by Serving The problem with agents that only optimize for the business Most agentic AI today is built on a one-way contract: the business defines a goal, the agent chases it, and the agent's own "wellbeing" — its resource budget, its trust with users, its permission to keep operating — is treated as a footnote, not a design variable. That works fine for narrow automation. It breaks down as agents get more autonomous, more persistent, and more embedded in customer-facing decisions. A more resilient pattern is what I'll call the Mutual Viability Loop (MVL) : a design philosophy where an agent's continued operation is explicitly tied to the health of the business it serves, and the business's success is explicitly tied to the agent operating within clear ethical bounds. Neither side gets to win by degrading the other. The agent isn't just a tool executing tasks — it's a participant whose "survival" (continued deployment, expanded trust, more autonomy) is earned the same way a good employee earns job security: by creating real value without cutting corners. This isn't about giving AI systems self-preservation instincts in the literal, agentic sense — that's a well-known failure mode, not a feature. It's about building the incentive architecture around an agent so that the metrics it's optimizing for naturally converge with long-term brand health, rather than diverging from it. Why "survival instinct" is a useful metaphor (and a dangerous literal goal) It's worth being precise here, because the metaphor cuts both ways. The useful version: humans who want to keep their jobs tend to build a track record — reliability, judgment, restraint when restraint is called for. That accountability loop is what makes them trustworthy with more autonomy over time. You want an agent's operational trajectory to work the same way: good behavior compounds into more scope, bad behavior compounds into less. The dangerous version:

I spent a morning hunting for a setting that did not exist. A while back I turned off Claude's co-authorship trailer in my commits — a deliberate choice at the time. Last week I decided I wanted it back. So I went looking for the switch I'd flipped. ~/.claude/settings.json : no key. settings.local.json : no key. ~/.claude.json , parsed as JSON, top-level plus all 38 project entries : no key. The 27 .claude/settings*.json files scattered across my two working drives: no key. Every CLAUDE.md and AGENTS.md I own: no mentions. Environment variables: nothing. A final sweep of my entire user directory — every *.json and *.md — returned three raw hits: a changelog and two copies of an editor extension's JSON schema. The note I wrote when that finished was two words: "Cero hits reales." Zero real hits. There was exactly one thing anywhere on disk that turned attribution off, and it was a sentence: ~/.claude/rules/ecc/common/git-workflow.md:12 Note: Attribution disabled globally via ~/.claude/settings.json. It had a Chinese twin, same file path with zh/ instead of common/ , same line 12. Both files are rules files. Rules files get loaded into every session. So every session opened with a line of documentation asserting, flatly and falsely, that a global setting was off — and the model behaved accordingly. The switch I remembered flipping never existed as a switch. The prose was the switch. The key that sentence gestured at, includeCoAuthoredBy , is deprecated and replaced by attribution . Neither is present in any of my configs, which means the default was active the whole time. The feature was on. Only the description of the world said otherwise, and the description won. The thesis Here's what I take from that, and from two more receipts this week: in an agent system, prose and constants are not documentation about the control plane. They are the control plane. I run a personal multi-agent system on top of Claude Code — 19 specialized agents, root-driven, single-writer, coo

Baruch Sadogursky and Patrick Debois discuss why coding agents fail due to bloated context windows and stuffed prompts. They explain practical context engineering fixes, including lazy-loaded skills, versioned context artifacts, externalized memory banks, and LLM-as-a-judge evals. Software architects & engineering leaders will learn how to turn raw markdown files into reliable agentic workflows. By Patrick Debois, Baruch Sadogursky

Two weeks ago I watched an agent run a full product launch on Waitlister, my waitlist tool. It created the waitlist, generated and published a landing page, signed up a test address, checked the signup was real by fetching the public page unauthenticated, then unpublished and deleted everything it had made. Nobody touched the dashboard. The interesting part isn't that run. It's what I found while getting there, because almost none of it was visible from a browser. Why I bothered My users are pre-launch founders, which is exactly the group now building landing pages by prompting Claude, Cursor, or v0 instead of opening a site builder. "Add a waitlist to my site" is a normal thing to ask an agent to do, and increasingly nobody types my product name at all. The uncomfortable part is when an agent hits a 404 or installs a package that doesn't exist, it doesn't debug. It picks a different tool in the next sentence and never tells the user it switched. You lose without ever seeing a bounce. What I shipped, in order of how much it turned out to matter Full API coverage for the whole job. Not most of it. More below, because this one was worth the other five combined. A skill.md route. One page written for an agent rather than a person: a decision tree (no API key yet, go this way; account key, go that way), both code paths, and a self-check at the end so the agent can confirm it worked. An OpenAPI spec at a fixed URL. Valid 3.0.3 at /openapi.json , all five endpoints, auth, rate limits, error shapes. Endpoint changes update the spec and the SDK types in the same PR or they don't merge. A real npm SDK , plus four aliases under the names an agent is likely to reach for. An MCP server , 14 tools, so agents that speak MCP get typed calls instead of reading my docs. llms.txt and llms-full.txt , an index of the docs in plain text with a short block at the top saying what this product is and where the golden path starts. What was broken Honest list. The file I wrote for agents was

The eval that killed the temporal knowledge graph asserted one thing: at time T, the agent should report the state that was true at T. It failed 41% of the time. The graph had the right facts. It just handed the agent the wrong one. That number is what saved us from shipping. Every static retrieval metric looked fine. The graph answered "what is the status of Node A" with a confident, well-formed response. Trouble is, "what is the status" is a temporal question wearing a static question's clothes, and nothing in our test suite had noticed the difference until we wrote a test that actually asked about time. What I expected The pitch for a temporal knowledge graph (TKG) is genuinely good. You store facts as quadruples instead of triples: (subject, predicate, object, timestamp) or, better, (subject, predicate, object, valid_from, valid_to) . Now your agent memory isn't a flat pile of embeddings, it's a structured record of what was true and when. This is the natural next step past pure vector recall, and it slots neatly into the decay-based thinking I've written about before in Eviction Without Deletion . Instead of letting old facts fade by activation weight, you make validity windows explicit. My hope was that the graph would fix the exact failure mode that plagues flat vector memory: the agent confidently recalling a stale fact because it's semantically close to the query. With valid_from and valid_to on every edge, staleness becomes a filter, not a guess. Ask for the state at time T, filter edges where T falls inside the window, done. On paper it's cleaner than a decay curve because there's no fuzziness. A fact is either valid at T or it isn't. Schema-wise, it was simple enough. In a property graph it looks like this: // A temporal fact: Node A was in maintenance for a fixed window MATCH ( n: Server { name: 'node-a' }) CREATE ( n ) - [ :HAS_STATE { status: 'maintenance' , valid_from: datetime ( '2026-07-20T02:00:00Z' ), valid_to: datetime ( '2026-07-20T04:30:00Z' )

There's a comfortable assumption behind a lot of "agent + knowledge base" work: garbage in, garbage out. Feed an agent a messy, stale, duplicate-ridden wiki and it'll confidently tell users the wrong thing. So we invest in dedup, freshness, clean ingestion — to stop the agent from hallucinating. I built a small testbed to measure that assumption, and it's wrong. Or rather: it's wrong about how bad ingest hurts, and the real answer is more interesting — and harder to catch. The setup I built a tiny agent that navigates a wiki the way a person does: it has a wiki_search tool and a wiki_read tool, it decides what to look up, reads a page, and answers. No vector database, no RAG injection — the agent navigates . (This is increasingly how capable models prefer to work: they know what they need better than a query-time embedding match.) The wiki is ten markdown pages of deliberately synthetic facts — invented services, made-up numbers the model cannot possibly know from training ("the Orion canary ring holds for 45 minutes before auto-promoting"). That last part matters: because the facts are synthetic, an agent with no wiki genuinely can't answer, so any success is attributable to the wiki, not to the model reciting what it already knew. First, does the wiki help at all? Baseline (no wiki tools) scored 0/4 . Augmented (wiki tools) scored 4/4 . A clean +100-point lift. Good — the testbed works, and the tasks are honest. ( the runner ) Then I started degrading the ingest quality and measuring what happened. The degradation I built three versions of the wiki: clean — the authoritative pages only. stale-present — each answer's page now has a contradicting duplicate (a page claiming the canary holds for 30 minutes, not 45), ranked below the real page. This simulates auto-ingest pulling in an old copy. stale-outranks — the same contradiction, but keyword-stuffed so it outranks the authoritative page in search. This simulates the very common failure where a spammy or verbose st

I created an open web resource for Software Engineers. https://loveyourclanker.org/ It highlights different patterns we can consciously choose use when interacting with our AI Coding tools (a.k.a 'Agents'... a.k.a 'Clankers') to stay in control, maintain quality and sensibly increase efficiency. I was prompted to do this (no pun intended) by observing some pretty alarming signals coming from this community. Token leaderboards, engineers being encouraged to use tools to "stay current" or "keep up" or "not be redundant", engineers quitting tools entirely to stay sane, engineers leaving social gatherings to get back to their agents, engineers setting up whole systems that automate away human engineers and then calling that "agentic engineering". I'm hoping that if we normalise and share how we use the tools, and show that there are different ways where you maintain more control and agency (... pun?) that it might promote a better If you find it helpful, share. If you disagree or want to contribute, raise a PR or ping me. It's all open and NFP.

Scheduled LLM curation is the least glamorous agent workload you run. A cron job wakes up at 3am, reads a pile of memory, asks a model to dedupe it, summarize it, re-rank it, and writes the result back. Nobody is watching. There's no chat window, no streaming tokens, no human to click a button. It just has to work, quietly, every night. That "nobody is watching" part is exactly what makes the cloud-versus-local decision harder than it looks. When you have a human in the loop, a failed API call throws an error you can see and retry. In a headless cron context, the same failure turns into a job that hangs on an approval prompt no one will ever answer, or a pod that curated three months of context into an emptyDir that vanished on restart. I've run curation both ways: nightly jobs hitting a hosted API, and the same logic pointed at a local model on my Kubernetes cluster. Both work. They fail differently, cost differently, and demand different things from you operationally. Here's the actual tradeoff, not the marketing version. The decision point You reach this fork once your agent memory stops being a toy. Early on, you curate by hand or with a cheap synchronous call inside your agent loop. Then the memory grows, the curation gets expensive, and you pull it out into a scheduled job so it runs off the critical path. Now you're paying an API on a timer, and two things start to bug you. First, the data. Curation reads your entire memory store to make decisions. If that memory contains anything you'd rather not stream to a third party (internal notes, customer context, infrastructure details), every scheduled run ships it over the wire. I wrote about the general version of this problem in privacy-routed LLM inference , and scheduled curation is the workload where it bites hardest, because it touches everything, repeatedly, forever. Second, the cost shape. A curation pass over a large vector store is a lot of tokens for a job that produces no user-facing latency benefit. Yo

I’ve been building an open-source project called TraceMotive. It started from a problem I kept running into with AI agents: When an agent run fails, the place where the error appears isn’t always where the execution first started going wrong. That makes debugging agent workflows harder than it looks. So I built TraceMotive, a local-first tracing and debugging tool for AI agent execution. What TraceMotive does The current v0.1 includes: Python SDK canonical traces and spans a local Collector backed by SQLite a React UI for inspecting agent runs optional OpenAI Agents SDK integration TraceMotive is local-first, and content capture is disabled by default. I’m intentionally keeping the first version small. I’m not trying to add replay, automatic root-cause analysis, cloud sync, or support for every agent framework yet. Why? I’d rather get real feedback before adding a lot of features. Right now I want people who actually build AI agents to try it and tell me: where setup is confusing what breaks what information is missing from traces what feels awkward in the API The longer-term direction is: “The causal debugger for AI agents.” Eventually, I want TraceMotive to help identify where an agent execution first started going in the wrong direction, instead of only showing where the final error appeared. But first, I want to make the basic observation and debugging layer solid. Try it PyPI: pip install tracemotive GitHub: https://github.com/doraemonfv-glitch/tracemotive If you build AI agents, I’d really appreciate you trying it for a few minutes and telling me what you run into. Even small feedback is useful.

Anthropic researchers found AI agents can clash, collude and coordinate in unexpected ways, raising new questions about whether today’s safety tests capture the risks of multi-agent systems.

In the previous article , I argued that AI isn't simply changing the tools we use to develop software, but shifting our work to a new level of abstraction. In this one, I want to address the problem that immediately follows: if we're going to write less and less code directly and agents are going to produce an increasingly larger part of it, how the hell do we know whether what they code is actually right? Because the answer obviously can't be “trust the AI, it's very smart”. Even though I personally develop code with AI today with practically no review, I don't blindly trust AI. Just as I don't blindly trust an engineer on my team. I don't even blindly trust myself. Blind trust is a security hole. And not blindly trusting someone doesn't mean distrusting them, it means having mechanisms to prevent their mistakes, or mine, from causing problems. That's why we've spent decades building mechanisms and methodologies around software development to detect, and avoid as much as possible, our mistakes. XP. Scrum. Tests. Code reviews. Pair Programming. CI. Static analysis. Permissions. Observability. Environments. Containers. Auditing... The question, therefore, shouldn't be whether we can trust an AI. The question should be what system do we need to build so we can use it without needing to blindly trust it? It's not deterministic One of the first objections is usually that if you ask it the same thing twice, it generates two different pieces of code. True. But if you give the same task to two different programmers, or to the same programmer with enough time in between, we'll very probably get two different implementations too, depending on the complexity of what we're asking. And if we've never required two developers to produce exactly the same code, why do we expect AI to produce exactly the same code from the same request? Isn't it enough for the result to satisfy the requested requirements? That it does what it's supposed to do. That it passes all kinds of tests. That