标签：#agents

Arun invoiced a design agency ₹1,20,000 in January. It's August. He is in a 4,000-member designers' Discord. He could post the agency's name right now and warn everyone. He won't, and you already know why: the freelancer who publicly names a client stops getting briefs. He'd pay for it alone, and everyone else would benefit. Here's the part that makes it a systems problem rather than a sad story. Three other people in that same Discord are owed money by that same agency. None of them knows. Each one is running the same arithmetic Arun is, arriving at the same answer, and saying nothing. Four people who together have real leverage. Individually, none of them can afford the first move. I built an agent for this over a hackathon weekend. The interesting part wasn't the AI. It was that every obvious solution destroys the thing you're trying to protect. The obvious version, and why it dies "Just make a private channel for victims of bad clients." To join, you say who burned you. Now the group knows. One screenshot and Arun is on a list. "Okay, collect reports centrally and only reveal at a threshold." Better. This is roughly how Callisto Vault handles assault reports, and it's a good pattern. But it reveals the group to its own members at the threshold. Four people now know each other's names and amounts. Four times the leak surface, arriving exactly when things get tense. The requirement I ended up with was stricter than I expected: Nobody is exposed. Not to the channel, not to the accused, and not to each other — not even after it works. Which sounds impossible, because how do four people coordinate if they can't know who they are? They don't. The agent knows. Nobody else does. The public board that can't name the client Here's what actually appears in the Discord: PICKET · matter #1 > "invoiced in January, still chasing in August" ₹50k–2L · 180d+ overdue 🟩⬜⬜⬜ 1/4 joined [ JOIN ] One sentence Arun wrote himself. An amount band , not his figure. A counter. The agency's

Every "my agent isn't working" postmortem starts the same way: someone rewrites the prompt. Adds a constraint. Adds an example. Ships it again. Three iterations later the agent still can't hold up in production, and the team is quietly out of ideas — because the prompt was never the layer that broke. There are five control layers standing between a raw model call and a system you can actually trust with a business outcome: prompt, context, harness, loop, and graph. Most teams staff and instrument only the first one or two. The failures that show up in production — wrong tool called, same mistake retried forever, output routed to the wrong reviewer — live almost entirely in the layers nobody named. Graph engineering is the newest and least understood of the five: it's the layer that decides which component runs next, when agents work in parallel versus in sequence, and where a human has to sign off before anything expensive or irreversible happens. This piece breaks down all five layers, works through a single production failure end to end, and shows where evals fit as the measurement system running through every one of them. The mental model: five rings around the model MODEL CALL = prompt + context AGENT = model call + harness + loop SYSTEM = agents + deterministic steps + humans, connected by a graph EVALS = evidence that every layer actually works Prompt and context sit closest to the model. Harness and loop turn a model call into something that can act and recover. Graph turns a collection of agents, functions, and human checkpoints into a coordinated system. None of these layers replace each other — they're concentric controls, not pipeline stages, and a production agent uses all five simultaneously. The weakest layer sets the ceiling on how reliable the whole thing is, no matter how good the other four are. Layer Controls Fails as Prompt Role, goal, constraints, output contract Ambiguous instructions Context What reaches the window: docs, history, tool results

Your agent calls get_weather(city="London") . The provider ships a new model version. Now it calls get_weather(location="London, UK") , your downstream parser breaks, and nothing in CI told you. I built a small library for exactly this failure: pip install toolcontract GitHub: https://github.com/Divyansh2202/toolcontract PyPI: https://pypi.org/project/toolcontract/ You pin a golden set of expected tool calls as a contract, re-run them against the live model, and get pass / fail / inconclusive with a diff showing what changed. It is not an eval framework. promptfoo, DeepEval and the rest score whether an output is good — semantic quality, usually judged by another model. toolcontract asks a narrower, cheaper question: is the tool call structurally the same as the one I pinned? Same tool, same argument shape, same trajectory. That is a regression test, not an eval, and it is the question that matters when a provider bumps a version under you. Details: pass / fail / INCONCLUSIVE — anything the structural comparators cannot resolve is never silently turned into a pass or a fail trajectory matching: strict, unordered, subset, superset optional argument support, so you can assert a field must stay absent works with OpenAI, Anthropic, anything OpenAI-compatible, or via LiteLLM thin pytest plugin, and a CLI that produces the same verdicts without pytest MIT Happy to hear where this breaks. It's v0.1.

On August 14, 2026, auto mode becomes the default permission mode for new Claude Code sessions on Pro, Max and Team plans. The agent stops asking before each step and simply proceeds, unless the action it wants to take is judged irreversible, destructive, or aimed outside your environment. Anthropic's argument for the change is a number from its own testing: in a 1,053-action study, auto mode blocked 89% of harmful actions, while humans clicking through approval prompts caught 13.6%. The uncomfortable half of that finding is why — users habitually approved 97% of the prompts they were shown. If you have used a coding agent for more than a week, you already know the feeling being described. The prompt stops being a decision and becomes a keystroke. Anthropic calls this permission fatigue, and it is making the case that a model checking each action against a policy is a better guard than a human who has stopped reading. What changes on August 14, and what does not Three things are true at once, and they get mixed up in most of the coverage. First, the default flips only for new sessions on Pro, Max and Team . Existing sessions keep the mode they are running in. Second, auto mode is not "approve everything." Actions classified as irreversible, destructive, or targeting something outside your environment still stop and wait for you. Deleting data, force-pushing over history, and reaching for a remote system you did not point the agent at are the shapes of action that still surface a prompt. Third, the rollout ships with two controls that matter more than the default itself: prompt-injection screening on incoming content, and hard deny rules you configure so that certain actions can never be taken regardless of what the model concludes. Deny rules are the part worth your afternoon. They are the only control in the list whose behaviour does not depend on a model's judgement. The 89% number cuts both ways Eighty-nine percent blocked means eleven percent not blocked. On a s

Forbes Called It a Playbook. I Call It a Production Log. Forbes published a piece recently calling AI agent startups "the new solo-founder playbook." I read it twice. The framing bothered me both times. A playbook implies steps. A sequence. Something you can hand to someone and say: follow this, and you will get the result. What Forbes described is not that. It is a description of an outcome, written by people who did not have to fix anything at 2 AM when the agent broke. Let me tell you what it actually looks like. The Night 871 Emails Went to the Wrong People Fourteen months ago I built my first agent that could send emails on behalf of the system. It was an outreach automation, nothing exotic. The agent would identify leads, draft a message, and send it after a human approval step. Except the approval step had a race condition. Two concurrent jobs both read "pending" from the database, both approved, and both dispatched. One lead received 871 emails over 40 minutes before I caught it. No company, no legal team, no PR buffer. Just me and an inbox full of angry replies. That night I wrote my first hard guardrail: #!/bin/bash # email-dedup-guard.sh LEAD_ID = " $1 " LOCK_FILE = "/tmp/email-lock- ${ LEAD_ID } " if [ -f " $LOCK_FILE " ] ; then echo "BLOCK: email already dispatched for lead ${ LEAD_ID } " > &2 exit 1 fi touch " $LOCK_FILE " # proceed with send Embarrassingly simple. But I did not know I needed it until I needed it. This is what Forbes leaves out. The playbook is written in retrospect, after someone else absorbed the cost of learning. The Model Is Not the Problem Every conversation about AI agents eventually becomes a conversation about which model to use. GPT-4 versus Claude versus Gemini. Benchmarks and context windows and reasoning scores. Here is what I learned: the model is the easy part. My current system runs 86 containers across two Hetzner servers. 240 automated jobs. Every day, these jobs do things: post content, process leads, trigger builds,

AWS has open-sourced Dogwood, a policy language extending Cedar with temporal conditions so rules can reason about an agent's prior tool calls rather than one request in isolation. It covers approvals, rate limits and running totals, ships under Apache 2.0, and is supported in AgentCore Policy, though the reference interpreter is not production-ready. By Steef-Jan Wiggers

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 7, I closed on a line worth expanding: "I built an agent" vs "I built an agent I can actually operate." The difference between those two sentences is the sixth and final component of the harness. It's called Observability , and without it, everything else you've read in this series is a bet you can't check. Every previous component in this series does something the agent needs to work. Observability does something the engineer needs — to see what happened, to know when things are going wrong, and to have any hope of making the harness better over time. What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Part 5: Context Engineering Part 6: The Filesystem & Environment Part 7: The Memory Layer Observability ← You are here Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what Observability actually is, why non-deterministic multi-step systems can't be operated without it, and the three properties — full-fidelity logs, session-level traces, and fixed evals — that separate a real observability setup from an aspirational one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. Wh

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 6, we closed on a limitation the previous four components can't solve on their own: the agent forgets. Once a session ends — or the context window fills up mid-task — everything the agent learned, discovered, or decided vanishes. Next time the user comes back, the agent greets them like a stranger. Next time the token budget runs out, earlier turns get truncated away, and the agent's earlier reasoning is just gone. That's the gap this article closes. The Memory Layer is how the harness gives the agent persistence — inside a task, and across sessions. What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Part 5: Context Engineering Part 6: The Filesystem & Environment The Memory Layer ← You are here Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what a Memory Layer actually is, why short-term and long-term memory are two different systems (not one with a dial), and the three design decisions — flavor, write triggers, and bounded retrieval — that separate a real memory system from a naive one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. What The

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 5, we looked at the Context — the payload the model sees on every call. Now we look at what happens after the model, having seen that Context, decides to do something. The model calls a tool. The tool has to execute somewhere. That somewhere is the Environment . It's easy to under-appreciate. The Environment feels like plumbing — the filesystem, the shell, the network, the machine underneath. But it's where every side effect the model requests actually lands, and how you design it is what separates "an AI agent doing things on your behalf" from scary to routine . What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Part 5: Context Engineering The Filesystem & Environment ← You are here Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what the Environment actually is, why every tool with side effects depends on it, and the three properties (bounded, reproducible, inspectable) that separate a production-ready environment from a demo one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. What The Environment Is The Environment is

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 4, we looked at the Tools — the set of functions the model can call. But there's still one big open question hanging over every turn of the Loop: what does the model actually see when the Loop calls it? The answer is: whatever the harness put in the payload. That payload — the entire package of instructions, history, retrieved documents, tool definitions, and everything else — is called the Context . Some readers know this territory under an older name: prompt engineering . That name isn't wrong, but it's narrow. A prompt sounds like something you write once and ship. The reality of running an agent is that the payload changes every turn, and designing what goes in it is an ongoing discipline. Hence the newer, more accurate term: context engineering . What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Context Engineering ← You are here Part 6: The Filesystem & Environment Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what the Context actually is, why every turn forces you to answer "what should the model know right now?" from scratch, and the three moving pieces (system prompt, history, retrieval) that make up a well-designed context. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, a

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 3, we looked at the Loop — the outermost machinery of a harness, the piece that drives everything else. But a Loop on its own is a hollow shell. It calls the model. The model responds. And then, if the model wants to affect anything outside the text it just produced, it needs to reach for a tool. That's what this article is about: the Tool Layer. The set of functions the harness makes available to the model, and the design decisions that separate a tool surface a model can actually use from one that constantly frustrates it. What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop The Tool Layer ← You are here Part 5: Context Engineering Part 6: The Filesystem & Environment Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what tools actually are, why they exist, and — more usefully — how to tell a well-designed tool surface from a badly-designed one the moment you look at one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. What The Tools Are The Tools are the set of functions the harness exposes to the model. Concretely: the harness tells the model "

Sudeep Das shares how DoorDash shifts from legacy one-shot predictions to an agentic recommendation platform. He discusses leveraging language-native consumer memory, RQ-VAE semantic IDs for catalog representation, and grounded search to dramatically boost relevance and conversion metrics. By Sudeep Das

Cloudflare launched agent tracing, adding spans for agent invocations, model calls, tool runs, and approvals to existing Workers traces. Sessions replay turn by turn, though the docs warn traces are not lossless and payloads may be truncated. Payload recording defaults differ by framework, and from October 1, 2026 every span counts as a billable event. By Steef-Jan Wiggers

I Built a Voice-First AI Tutor for Bharat in 10 Days 🇮🇳 — Here’s My Complete Journey Over the past 10 days, I participated in the 10 Days of Voice Agents challenge hosted by Murf AI. I built Vidya Vani, an intelligent, low-latency, multi-agent voice tutor that helps users practice spoken English and Mathematics. It features dynamic LLM question generation, memory retention across sessions, live analytics, and seamless agent handoffs—all powered by the blazing-fast Murf Falcon TTS and LiveKit WebRTC. This is the full story of why I built it, the architecture that powers it, the intense roadblocks I hit, and how you can build one too! The Problem: The Education Gap in Bharat India is a country of incredible diversity, but when it comes to foundational education—specifically English literacy and Mathematics—there is a massive accessibility gap. Quality education is often concentrated in urban hubs, leaving learners in rural and semi-urban areas without access to dedicated, patient tutors for 1-on-1 practice. While there are plenty of ed-tech apps and text-based AI chatbots available, they all suffer from the same fundamental flaw for foundational learners: friction. Practicing spoken English with a text-based chatbot is intimidating. It requires spelling proficiency, typing speed, and it does absolutely nothing to help with conversational confidence or pronunciation. The Solution: We needed a voice-first approach. By leveraging voice, we entirely remove the friction of typing and screen-staring. Users simply speak to their phone or computer, making the interaction as natural, accessible, and human as talking to a real teacher. Meet Vidya Vani & Aryabhata I set out to build a 24/7 educational voice tutor for the Learning & Literacy track of the challenge. But as the days progressed, I realized a single AI prompt trying to act as a master of all subjects was prone to hallucinations and confusion. So, I split the persona into two distinct experts. Vidya Vani: The Orchestr

From a Simple Voice Conversation to a Multi-Capability Healthcare Voice Agent Over the past 10 days, I had the opportunity to participate in 10 Days of Voice Agents — VoiceForBharat Edition , a challenge focused on learning how to build practical, real-world voice AI agents. Instead of treating the challenge as just a series of coding tasks, I wanted to build something around a problem that genuinely matters: making healthcare access more conversational and accessible through voice. That idea became AarogyaMitra — a voice-first healthcare access assistant designed to interact with users naturally, provide useful assistance, use tools when required, remember relevant user context, and involve humans or specialist agents when the situation requires it. This article documents my journey, the architecture behind the project, the important features I built, the challenges I faced, and what I learned while developing a real-time voice AI system. What is AarogyaMitra? AarogyaMitra is a voice AI assistant focused on the Health Access track of the VoiceForBharat challenge. The goal is simple: Make healthcare assistance more accessible through natural voice conversations. Many digital healthcare experiences assume that users are comfortable reading, typing, navigating menus, and interacting with conventional applications. Voice can provide a more natural alternative. Instead of searching through menus or typing a question, a user can simply speak to the assistant and have a conversation. AarogyaMitra is designed around this idea. The core objectives are: Make healthcare-related interactions more conversational Provide a simple voice-first interface Use AI tools when additional information or actions are required Maintain useful context during conversations Follow safety-oriented guardrails Escalate situations that require human assistance Route specialized requests to a specialist agent AarogyaMitra is intended to assist users, not replace qualified healthcare professionals .

Skills are reusable workflows, not magic knowledge pills. Before you install one, inspect its source, versions, and effects to confirm it fits your project. Start with a few focused skills and adapt them to what already exists. A skill is a set of instructions and scripts that lets an agent reproduce a specialized method. It doesn’t guarantee best practices or compatibility with your repository. The official documentation for tools like Claude Code and Codex explains how skills work under the hood. Project rules, documentation, and skills serve different purposes. Official documentation describes technology features, repository conventions are captured in files like AGENTS.md , and skills provide reusable workflows. Mixing these roles leads to confusion and wasted context. Start your search in this order: official skills from the tool’s publisher, official technology docs, resources from recognized organizations, manually inspected community skills, and finally skills you create specifically for your project. Stars and downloads can signal adoption, but they don’t prove correctness. Before adding a skill, verify its origin, technical currency, possible actions, and compatibility with your project. Ask who maintains it, which versions it targets, whether it contains executable scripts, and whether it respects your existing architecture. If a script is unclear, don’t run it just because it comes with a skill. Contradictory skills increase noise and make decisions harder to explain. Two or three reliable workflows are more useful than a collection of twenty skills. For a mini-dashboard, start with a TypeScript review, a React and Next.js review, and a testing strategy tailored to expected behaviors. If no reliable skill matches your needs, write a short procedure adapted to your repository. A minimal skill can formalize a specific review, like verifying that a dashboard metric is typed, validated, displayed, and tested correctly. This keeps the workflow focused and rep

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