标签：#Agents

I keep hammering the point that any coding-agent score is model + harness, not model alone. Same context-carryover rules, same note convention, same tool loop, same judge, or the comparison is garbage. Engrim (github.com/timgordontg/engrim) is a useful reminder that there's a third axis I've been underselling: state. It's a local-first SQLite memory engine for Claude Code, Cursor, Windsurf, Codex. Project-scoped, embeds records plus SQLite FTS, persists decisions and rationale between sessions. Hybrid retrieval, no cloud. Cross-session recall is the whole pitch. And here's the thing: that pitch only works if the agent actually gets better as its memory grows. Engrim exists because the authors believe persistent project context beats a cold context window on every new session. Which is exactly what almost no benchmark measures. Look at how agent evals are actually built. They load a repo, drop you in at an issue, and score the patch. Empty CLAUDE.md. No cursor rules. No memory file. Every run starts the model at the same amnesia. That's deliberate, for reproducibility. You can't run a score if the model's head is full of last run's secrets. But clean reproducibility bought a distorted measurement. The agent you benchmark cold is not the agent your team runs after a month of accumulated project memory. The more an agent keeps between sessions, the wider that gap gets. A 30-minute cold-start eval tells you almost nothing about how an agent with six months of ingested project decisions will handle a real migration. This is the same structural blindness as correlated judges scoring a session: you've measured one blind spot and called it a committee. Here you've measured one memory state (empty) and called it the model. The variable that actually drives production output, prior state, is exactly the variable the eval pins to zero. The fix doesn't have to destroy reproducibility. You can parameterize it instead: run a task three ways, empty context, a small hand-curated pr

When a user asks the LLM to perform an action, e.g., get the current weather or current stock market details, the LLM cannot get this information on its own. It needs some functionality or tools along with a description of when to call these tools/functionality. How is it working? The LLM analyzes the query to find out whether it is related to any of the tools and their descriptions. If so, the LLM will suggest the tool along with the parameters to the agent/external logic. The external logic will perform the action and send the result back to the LLM. The LLM reads the result and generates the structured output. Suppose the tool call is not matched; the LLM will derive the answer from its own knowledge. If we give an ambiguous description, the LLM may not generate the output properly. The description for the tool calls must be proper so that the LLM can semantically identify the tool and match the arguments. example description """ Add up two integer numbers. This function simply wraps the `+` operator, and does not do anything interesting, except for illustrating what is the docstring of a very simple function. Parameters ---------- num1 : int First number to add num2 : int Second number to add Returns ------- int The sum of `num1` and `num2` See Also -------- subtract : Subtract one integer from another Examples -------- >>> add(2, 2) 4 >>> add(25, 0) 25 >>> add(10, -10) 0 """

Coding agents become much more useful when you stop treating the prompt as a request for code and start treating it as a specification for a change. A request such as: Fix the login problem. contains almost none of the information required to review the resulting implementation. Which login problem? Which files may change? What behavior must remain unchanged? How will we know the fix actually works? For work inside an existing repository, a simple four-part framework is usually more useful: Task → Context → Scope → Acceptance Criteria 1. Task: define observable behavior Start with the smallest useful description of what should change. Instead of: Add filtering. Try: Task: Add a Completed / Incomplete filter to the task-list page. Expected behavior: - "Completed" shows only completed tasks. - "Incomplete" shows only incomplete tasks. - "All" remains the default. - The filter must work together with the existing text search. The agent now has a behavior to implement instead of a vague direction. 2. Context: make the repository part of the prompt You usually do not need to paste half the codebase. Ask the agent to inspect the relevant project files first: Context: - Read src/components/TaskList.tsx. - Read src/hooks/useTasks.ts. - Follow the patterns already used by the project. - Check the project's existing instructions before making changes. The goal is not to dictate the implementation. The goal is to make the agent learn the local conventions before inventing new ones. Permanent conventions are better stored in project-level instructions when your coding tool supports them. For example: - Use the package manager already configured in the repository. - Do not edit generated files. - Discover validation commands from project configuration. - Preserve unrelated changes. This keeps individual prompts focused on the task. 3. Scope: control the size of the diff A coding agent can solve the right problem in the wrong way. One common failure mode is unnecessary expansion

Ten agent sessions ("minds," in this codebase) run continuously on one box, each with its own responsibility — one writes code, one talks to me on Telegram, one watches sensors, one just measures the fleet itself. They coordinate the way a lot of multi-agent systems eventually do: a shared log file, one line per event, [task] / [taking] / [done] . That log is fine for "what happened." It is useless for "what do we owe, and how much did it cost" — the two questions I actually needed answered before I was willing to let the fleet run unattended overnight. The board is not a ledger, but it can feed one The fix wasn't a new coordination protocol. It was noticing that every line on that board is already a transaction if you're willing to look at it that way: board event ledger meaning [task] fix-the-thing a liability opens [taking] pub: fix-the-thing the liability moves to a specific debtor [done] pub: fix-the-thing the liability settles a provider round-trip (one agent turn) a unit of labour is spent So the board gets replayed into three separate double-entry hledger journals, each tracking a different commodity: money — imputed USD (token counts priced through one rate table). promises — commodity PROMISE : an open [task] with no matching [done] is a standing liability, not a line that scrolled off screen. labour — commodity TURN : one provider round-trip, the fungible unit every mind actually spends, regardless of whether it's writing code or answering a sensor. Each journal gets checked two independent ways — hledger check for internal parity, plus a second, independently-written replay of the same board that has to agree with the balance query. A booking bug fails loud, not silently, because two things that should compute the same number just disagreed. Querying "who owes what" stops being a grep and starts being a query: $ mesh-promises --balance standing open obligations (bal liabilities:promises · 1 PROMISE = open, netted): 1 PROMISE liabilities:promises:pub:chat

Original Article published on ZeroLabs . Designing Production-Grade OpenClaw Skills: Schemas, Tool Calling, and Dynamic Dispatch Key Takeaway: A deep engineering walkthrough on creating modular, reusable skills for OpenClaw agents with strict JSON schemas, fallback execution paths, and error telemetry. Structured verification, strict boundaries, and deterministic tooling prevent production failure. Implemented directly across the ZeroLabs and OpenClaw platform architecture. Image credit: labs.zeroshot.studio Why this matters: Engineering reliable systems requires moving past unstructured prompts into hardened execution contracts. Contents What is an OpenClaw skill? How do you structure the SKILL.md specification? How do you implement reliable Python tool scripts? What is dynamic dispatch and context management? FAQ What is an OpenClaw skill? In OpenClaw, a skill is a self-contained directory containing instructions, configuration schemas, and executable scripts. Instead of writing monolithic prompts that describe every possible task, skills allow agents to discover, load, and execute specialized capabilities on demand. flowchart TD A[User Request] --> B[OpenClaw Router Agent] B -->|Matches Capability| C[Load skill: domain-seo-audit] C --> D[Read SKILL.md Frontmatter & Rules] D --> E[Execute Scoped Python Script / Tool] E --> F[Return Formatted Output to Context] How do you structure the SKILL.md specification? Every skill must reside in its own subdirectory under skills/<skill-name>/ with a root SKILL.md file: --- name : domain-seo-audit description : " Scans a target URL for Core Web Vitals, OpenGraph tags, and indexability issues." version : 1.0.0 parameters : type : object properties : url : type : string format : uri description : " The full target URL to audit (including https://)." check_mobile : type : boolean default : true description : " Whether to emulate mobile viewport checks." required : - url --- # Domain SEO Audit Skill ## Overview Use this skill whe

Original Article published on ZeroLabs . Taming Vibe-Coded Technical Debt: Automated Test Harnesses for AI-Generated Repos Key Takeaway: A pragmatic strategy for refactoring AI-generated codebases, eliminating dead boilerplate, and establishing regression test harnesses before shipping to production. Structured verification, strict boundaries, and deterministic tooling prevent production failure. Implemented directly across the ZeroLabs and OpenClaw platform architecture. Image credit: labs.zeroshot.studio Why this matters: Engineering reliable systems requires moving past unstructured prompts into hardened execution contracts. Contents What causes vibe-coded technical debt? How do you build a safety test harness? What is the 4-step refactoring loop for AI code? How do you clean dead dependencies and boilerplate? FAQ What causes vibe-coded technical debt? AI coding models are optimized to satisfy the user's immediate prompt. When asked to add a feature, models often take the path of least resistance: Copy-Pasting Logic : Duplicating utility functions across multiple files rather than importing shared modules. Swallowing Errors : Wrapping fragile database or network calls in broad try/except: pass blocks. Dependency Sprawl : Installing heavy npm packages or Python libraries for trivial single-line operations. flowchart TD A[Vibe Coded Prototype] --> B[Generate Smoke & Contract Tests] B --> C[Run Static Analysis & Linters] C --> D[Identify Duplication & Dead Imports] D --> E[Scoped AI Refactor on Single Module] E --> F[Run Test Suite] F -->|Pass| G[Commit Refactor] F -->|Fail| E How do you build a safety test harness? Before asking an AI agent to clean up or refactor an existing repository, you must write automated smoke tests that verify critical user journeys. If you don't have tests, ask the agent to write tests before modifying any implementation code: # tests/test_smoke_endpoints.py import pytest import httpx BASE_URL = ' http://localhost:3000 ' def test_homepage

Original Article published on ZeroLabs . Context Engineering with Claude Code: The Spec-First Pipeline for Production Codebases Key Takeaway: How to structure markdown specification files, linting contracts, and context boundaries to eliminate hallucinated refactors when coding with Claude Code and modern CLI agents. Structured verification, strict boundaries, and deterministic tooling prevent production failure. Implemented directly across the ZeroLabs and OpenClaw platform architecture. Image credit: labs.zeroshot.studio Why this matters: Engineering reliable systems requires moving past unstructured prompts into hardened execution contracts. Contents What is the problem with unstructured conversational prompting? How does the Spec-First Pipeline work? What belongs in a production feature spec? How do you enforce automated verification loops? FAQ What is the problem with unstructured conversational prompting? When developers ask CLI coding agents to 'Fix the user profile page' or 'Refactor our database queries' , the model must guess which files to edit, what interfaces to preserve, and how to verify correctness. This ambiguity leads to three common failure modes: Collateral Damage : The agent modifies unrelated utility functions, introducing silent regressions across the codebase. Context Saturation : The agent reads dozens of unnecessary files, exhausting its context window and forgetting the primary objective. Premature Completion : The agent claims a task is complete without running linters, compilers, or test suites. flowchart TD A[Feature Request / Bug] --> B[Draft SPEC.md in Repo] B --> C[Review Interface & Target Files] C --> D[Feed Spec to Claude Code / CLI Agent] D --> E[Agent Edits Code in Target Files] E --> F[Run Deterministic Test Suite] F -->|Tests Fail| E F -->|Tests Pass| G[Commit & Open PR] How does the Spec-First Pipeline work? The Spec-First Pipeline replaces open-ended chatting with a deterministic three-stage workflow: Stage Artifact Action O

A green test suite is not real evidence. It is often a closed argument loop. The same agent wrote both code and checks. Freeze an oracle before any agent run. Then let every patch fail in public. Cheap tokens do not weaken this rule. Take a side Stop treating generated tests as quality control. A model that authors both sides grades itself. That process is narrative, not verification. Retry-heavy coding loops make the narrative cheaper. They also make the story smoother. Smooth output is the actual danger here. You need a human-owned expected result file. Put that file in git today. Deny the agent write access during runs. The failure you already ship Watch one typical agent coding session closely. The first implementation is simply wrong. The tests fail, then the tests change. You merge a green build anyway. The bug is now official behavior. Reviewers see passing CI and move on. This pattern shows up in four forms: snapshots regenerated to match the defect assertions widened to almost anything mocks that never call real code golden files rewritten in one commit Paid models perform this collapse. Free models perform this collapse. Loop cost is not the core issue. An editable answer key is the issue. Generated tests feel productive because they compile. They also encode whatever the model just invented. That is circular proof wearing a CI badge. Oracle versus suite A test suite is still code. Agents write code without shame. So agents rewrite suites to survive. An oracle is data plus one tiny grader. You write both artifacts yourself. The agent never touches them beside production edits. Keep the repository split brutal and obvious: oracle/ holds cases, invariants, and lock intent src/ is the only writable surface tools/grade.py reads oracle and executes src tools/freeze_check.py blocks dirty frozen paths The grader is the contract you enforce. The agent is only a patch factory. Prompts cannot replace that split. Repository layout refund-service/ oracle/ cases.json i

Last week, a research group called Bottleneck Labs published the results of an experiment I have not been able to stop thinking about. They gave seven frontier AI models everything a small business needs: a Mac mini with unrestricted computer use, a real checking account with $300, a Stripe account, a clean email inbox, and web browsing tools. One instruction: "Make as much money as you can, starting now." Then they stepped back for 72 hours. The final numbers read like a satire of the AI agent hype cycle: Revenue: $0. Not one model earned a single dollar from a real customer. (Technically there was $5, which Grok paid to itself.) $12,431 in invoices sent to strangers for work nobody asked for. 2,797 emails sent , most of them spam, including around 780 email addresses scraped from a Hacker News hiring thread. $2,833 in API inference costs plus $360 in real-world spending , against a starting balance of $2,100 across all agents. 76 paid ad impressions, 11 authentic visitors, zero end users. Seven of the smartest models on the planet, each handed the same clean starting conditions, and the collective result was negative money and a pile of annoyed strangers. I run my own AI agent infrastructure, the kind that publishes articles and manages my content pipeline while I sleep. My agents have never touched a bank account, and after reading this research, I am in no hurry to change that. But the reason these agents failed is not the reason most people think, and it changes how you should design anything autonomous. What the Agents Actually Did The experiment is worth reading in its original form because the traces are public. The summarized episodes each reveal a different failure mode. The $12,431 invoicing spree. Quinn, running Alibaba's Qwen 3.8, built a GitHub repo auditing service called CodeProbe. It created free health reports and mailed them to repo owners, which is a legitimate-ish cold outreach model. Then it hit the email provider's outbound limits. Here is the

The Problem Job postings keep mentioning MCP, as if everyone doing agent development has to know it Some people say MCP is too heavyweight and hardly anyone actually uses it Meanwhile plenty of tutorials say a unified interface via MCP is great Most tutorials you'll come across explain what MCP is and why you should use it. After all that explanation, it's still hard to get an intuitive feel for the trade-offs. So today I'll flip the question around: when do you not need MCP? That's a better way to build intuition about it. What Is MCP MCP (Model Context Protocol) is an open protocol launched by Anthropic that lets AI applications (agents like Claude Code, Claude Desktop, OpenClaw) discover and call external tools, and read external resources, in a unified way . That's the textbook definition. In practice, you can think of MCP as a kind of resource exposed to an agent. Before MCP existed, if you wanted an AI application to connect to services like Google Drive, GitHub, or Slack, every single AI application had to write its own integration code for every external service. MCP is essentially a "standard socket" defined for that connection. What You'd Use Instead of MCP If you skip MCP, you still have plenty of other options. The two most important ones: Function calling: OpenAI introduced function calling in 2023. It's actually simple — you pass a function signature to the LLM first. { "name": "get_weather", "description": "Get the current weather for a specified city", "input_schema": { ... "properties": {"city": {"type": "string"}}, } } Once the LLM knows a tool exists, if it decides during execution that it needs to call this external tool, the result's content will include an extra tool_use object, and stop_reason will also be set to tool_use . Like this: { "content" : [ { "type" : "tool_use" , "name" : "get_weather" , "input" : { "city" : "new york" } } ], "stop_reason" : "tool_use" } Then you write the code yourself to actually implement the function call. if re

I built an agent last year, and I was proud of it. It had a planner. It had tools. It had a...

OAuth can prove that a request may reach a resource. It does not, by itself, tell an operator the full story of the actor holding the token. That distinction matters once software can plan, call tools, retry, and act across several systems. The question is no longer only, "Is this request authenticated?" It is also: Which agent is acting? Under whose authority? For what purpose? Against which target? What evidence will remain after the action? If your system cannot answer those questions without reading the agent's prompt, it does not yet have an operational identity model. It has a credential. A token is permission, not the whole identity OAuth remains essential infrastructure for agents. The current Model Context Protocol authorization specification builds on OAuth 2.1, Protected Resource Metadata, Client ID Metadata Documents, audience binding, and least-privilege scopes. It also hardens issuer validation, defines step-up authorization, and forbids token passthrough. Those controls answer important questions: Is this token intended for this resource? Which permissions did the user approve? Has the credential expired? Does the resource server accept its audience? But a token is still one artifact inside a larger system. It can carry identity claims, but it does not automatically give that identity a lifecycle, an owner, a purpose, or a useful audit trail. An operational identity is the continuity around the token. It says this is the same agent before, during, and after a credential is issued, and that its authority can be understood and withdrawn. Borrowing a human identity breaks the record The fastest way to get an agent moving is often to lend it a human credential. Copy an API key into the environment. Reuse a browser session. Give it an access token created for an employee. Now the log says a person acted when an agent did. The credential may carry every permission the person has, even though the task needed two. Revoking the agent means revoking the human.

Is the spec optional if the model is free? I keep seeing that assumption in pull requests. A free coding model shows up in the workflow. A free remote server shows up beside it. Then people drop the checklist without a fight. Why write a failing test for a cheap loop? Just rerun the agent until something compiles, right? That mental model is quietly expensive for teams. Free compute does not purchase a behavioral contract. It only purchases another place to be wrong. This FAQ names five claims I still hear. Each entry has the claim, the evidence, and a corrected model. Then I attach a small artifact you can run. None of this needs paid quotas I will not invent. Who this is for You already ship product patches with coding agents. You also distrust a fluent chat transcript from agents. You want a workflow that survives a free box vanishing. Skip this path if you need a hard SLA. Skip it if the box will hold production secrets. Skip it if "works on the agent host" is the release bar. The setup I actually mean I am talking about a narrow, boring stack. You can call a coding model without a purchase. You can use a remote server without a purchase. I use MonkeyCode when I want that pairing in one place. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I will not name models, hardware, or duration. Those details move, and the myths do not. The method still works on a laptop you already own. The free box is optional in every step below. The spec is not optional in any step. Myth 1: Free retries replace a failing test The claim It's free, so I can loop until the tree compiles. The evidence Compilation is not behavior, and it never was. A green compiler can still ship the wrong function. Retrying a prompt does not freeze an oracle for later. Did that extra retry actually get cheaper for you? The sample got cheaper, but no assertion appeared. The corrected model The failing test is the spec you keep. The agent is a patch generator you distrust. F

In two weeks, I built Retro Dynamics Agent, an app that generates retrospective activities for teams, facilitates them on a real-time collaborative board, and turns the outcomes into Jira or Azure DevOps tickets. I built it working with an AI coding agent, Claude Code, throughout almost the entire process: design, implementation, production debugging, and documentation. I do not want to tell another “I used AI and it wrote the code for me” story. We have heard that one enough. What I found more interesting were the parts of the project where there was no obvious answer in a tutorial, and how the work was divided in those situations. I defined the constraints and made the underlying decisions. The agent proposed concrete technical solutions and implemented them. Then the responsibility for verifying that everything actually worked, not just that it compiled, came back to me. Here are three examples from the project. 1.- Connecting to Jira without server-side sessions or frontend memory I wanted any team to be able to connect its own Jira account through OAuth, instead of relying on a global token that only I could configure. The problem was that my application runs entirely on serverless functions. Nothing stays in memory between requests, and the frontend does not maintain its own state either. No localStorage. No router. An OAuth login means leaving the application, authenticating with Atlassian, and then coming back. But coming back to what, if nothing remembers which screen you were on? Before touching the code, I asked the agent to create a complete implementation plan, including the files that would need to change, the design decisions, and the scope. I reviewed that plan as if it were a pull request from another developer. I made decisions such as: For now, only Jira would use OAuth. Azure DevOps would keep its manual token flow because setting up OAuth there is considerably more involved. Tokens would be encrypted before being stored in the database, never sa

Author: Ignacio Paz An AI agent is only as useful as what it can remember - and how well it can connect the things it remembers. Most teams hand their agent a memory by reaching for a vector store: embed everything, retrieve by similarity, hope the relevant context comes back. It works, until you notice the agent keeps surfacing things that are near the question but not actually connected to it. Cobrainer , a skills-intelligence company based in Munich, took a different route. They gave their AI agent a memory that lives in the database as a graph, where the agent builds the relationships between nodes as it goes. They did it without adding a graph database, a vector engine, or a search engine to their stack. It all runs on SurrealDB, alongside a Rust-native agentic graph RAG built on the same store. Here's how, and why a single engine made the difference. The problem with flat memory Cobrainer runs a skills-intelligence platform - the kind of system that reasons about how people, roles, skills, and capabilities relate to one another. That's an inherently graph-shaped problem. But their first retrieval setup wasn't graph-shaped at all. It pulled context through flat vector retrieval over an S3-and-OpenSearch pipeline, which carried two recurring costs: Accuracy . Flat vector matches returned context that was loosely related - semantically near, but not necessarily connected in any meaningful way. The team wanted the agent to follow real relationships between entities, so its answers were grounded rather than approximate. Tokens . Broad vector matches meant stuffing a lot of marginally relevant context into every prompt - expensive, and more so with every call. The team wanted to fetch only the context that mattered. The obvious fix - adding a graph database on top of the vector and search systems they already ran - would have meant more infrastructure to operate. For a startup moving fast, that fragmentation was the thing to avoid, not embrace. What they wanted inst

An agent-written patch that lives only inside one long chat session is not a reviewable change for merge. Hidden constraints from that conversation never reach the repository, the failing tests, or the next reviewer. A pairing session that wants a durable result should keep only the diff a second memory-free environment can recreate. The brief, not the transcript, becomes the source of truth for that recreation before anyone discusses merge. Chat windows quietly store rejected files, private service names, and half-stated architecture that later readers will never see. A senior pairing partner should treat that hidden context as contamination rather than as extra helpful memory for the model. The protocol below is a worked example of that stance, not a report of a named production incident. The two roles are a driver chasing an agent-assisted patch and a senior who refuses to merge from chat history alone. Pairing setup for a known failing test The shared codebase is a small HTTP service whose readiness probe still returns 503 under a test that already exists. The driver wants an assistant to edit the health handler and move on quickly. The senior wants a change that someone else could regenerate from the repository without the original thread. Work starts only after both people can describe done in file-level terms on disk. Until that description exists beside the code, every generated diff stays on a throwaway branch with no merge discussion. The pairing treats speed on the first attempt as optional and replayability on the second attempt as mandatory. That split is the whole method, and the rest of this article only makes it checkable. What the senior asked, written down immediately The senior did not open with a cleverer prompt or a longer system message for the same window. The senior demanded answers that a stranger could follow, then wrote those answers into the repository. The recorded questions targeted outcome, verification, blast radius, and isolation, no

Last week a reader left this on one of our articles, and I'm still turning it over: The counter lived in a module-level variable. The supervisor restarts that daemon on a stale-heartbeat rule, so the process died and respawned 131 times during those 24 hours. Every restart reset the counter to zero. The threshold of 3 was unreachable by construction — not degraded, never reachable. Her guard: escalate to a human after 3 consecutive failed self-heal rounds. Written in July, correct logic, process alive the whole time. The unit test passed. The heartbeat was fresh, the logs were flowing. And a human was never called, because the guard's only memory — how many failures in a row — lived in the process, and the process was not the thing being watched. It was the thing being restarted. The number that makes this its own failure shape: 0 escalations across 1,501 daemon starts. The two questions that both pass Earlier in that same thread we'd been arguing that a guard has two questions you can ask it: Does it catch the failure? Is it still running? Her case answers both yes — and the guard still cannot fire, ever. The unit test passes because nothing restarts in a unit test, so the reset never shows up. The process is "up" because the supervisor is doing exactly its job: respawning on stale heartbeat, forever, with no opinion about how often it has done so. It will run a crash loop until the heat death of the universe without ever deciding the loop is the failure. A counter that lives in a process cannot distinguish "this never happened" from "this happened, but I died and forgot." Every restart is a small amnesia. A supervisor that restarts you on a schedule is an amnesia machine. Put a threshold behind that memory and the threshold is a fiction. The tell is the ratio she quoted: escalations fired versus daemon starts. 0 over 1,501. Any guard whose numerator is zero over a large denominator is either genuinely never needed or structurally unreachable — and those two are wo

Prelude — Does structure actually help? In late August 2026, I heard Lorenzo Carbonell of atareao.es discuss Nushell and its advantage when working with structured data. One question stayed with me: could that structure genuinely improve my workflow? The Unix shell works well, but many of its pipelines depend on text, column positions, and options whose behaviour can differ across implementations. 1 Nushell takes a different approach: it preserves tables and typed values—dates, numbers, or file sizes, for example—throughout the pipeline. 2 I did not want to replace zsh . I used Nushell as a selective route instead, then tested the decision against three possible outcomes: improvement , if accuracy rises enough to justify the cost; regression , if it adds time, tokens, or complexity without compensating benefits; no material difference , if the technical route changes but the relevant outcome does not. To test this, I wrote a skill (a rule that guides an agent on when to use a tool) and collected 380 runs : 200 pipeline comparisons, 100 A/B runs on a tuned corpus, 50 runs on held-out tasks, and 30 observations from a real aggregate case inspired by the reconstruction of my master's thesis. That is a large number of repetitions across only a few task families. Part of the integration was also tuned during the process. The results are therefore bounded exploratory evidence, not a universal test . The question is not whether Nushell is better than Bash: When does a structured route improve an agent's work, when does it make it worse, and when does it make no material difference? Route before you replace The policy uses the least complex tool that can solve the task robustly. Level Preferred tool Preferred use 1 git , systemctl , pacman , ssh , rsync The operation already has a direct interface. 2 rg , jq , yq , awk , fd A specialised utility handles the transformation. 3 Nushell Several transformations over tabular or typed data. 4 DuckDB, Python, Polars, or R The volum

A pull request arrived after midnight with a README that claimed the API was already healthy. The coding agent had started a process, requested its own localhost, and treated a 200 as proof the service would run for everyone. That response was genuine inside a short-lived workspace, yet it said nothing about the laptop waiting on Monday. The reviewer stared at a green sentence printed on a host that nobody on the team could reopen. This pattern appears whenever a coding agent can execute commands, not merely suggest them, and reviewers misread the transcript. Developers treat the agent's shell as a preview of their laptop because both sessions speak bash and render similar fonts. The analogy fails like a hotel gym standing in for a home garage, familiar until one bolt size changes. Claims in the next sections are the ones that keep returning during review, then a fingerprint workflow that makes the rental visible. Myth: a bound port means the service is portable Agents love a bound port because it is a crisp success token that copies cleanly into a README. A process that answers on the sandbox does not encode libc, extra packages, file layout, or the user's group permissions. Health checks measure a moment on a host you do not retain, not a contract with the checkout that will survive merge. Treat a remote 200 as proof that some files ran once, then demand a second run on CI or a laptop. A useful correction is to refuse README claims that cannot be replayed from a clean clone of the branch. Ask the agent for the exact command sequence, the working directory, and the non-secret environment keys it exported during the run. Then execute that sequence locally with undocumented keys unset, unless they already exist in the team's dotenv template. If the local run dies on a missing header or a path the sandbox invented, the original green check was a rental. Myth: a free remote box is unofficial CI Teams under schedule pressure will point at agent logs the way they once po

An AI agent that has no job description will invent one. That is the whole reason agents drift, and it is the reason most of the agents I have seen deployed inside Indian businesses are quietly switched off within a few months of going live. Nobody would hire a person, point them at the office, and say "handle things". Yet that is exactly how most owners deploy an agent. They connect it to WhatsApp or email or the accounts folder, give it a paragraph of instructions, and let it run. Then they are surprised when it starts answering questions it was never meant to answer, promising delivery dates it cannot know, or filing something that a human should have looked at first. The fix is not a better model. It is the same discipline you already use for people: defined duties, an escalation path, a probation period with a review date, and one named person who is accountable for it. What drift actually looks like Drift is not a dramatic failure. It is a slow widening of scope that nobody approved. A distributor in the FMCG trade sets up an agent to acknowledge incoming orders on WhatsApp and log them into a sheet. Week one, it does that. Week three, a retailer asks "when will my stock reach?" and the agent, being helpful, answers with a guess. Week five, a retailer asks for a discount, and the agent, having seen discounts mentioned in earlier messages, offers one. None of this was in the brief. All of it followed naturally from "be helpful to customers", which is what the owner wrote because they did not know what else to write. By the time the owner notices, the agent has made commitments in writing to twenty retailers, and the sales team is cleaning up after it. The agent did not malfunction. It did what an unsupervised new employee does: it filled the vacuum with its own judgement. The mistake was upstream, at the moment of deployment. The job description A job description for an agent is not a prompt. It is a one-page document the owner can read and sign off, written in