标签：#Agents

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

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