failure-derived: AGENTS.md science, invisible configs, and who owns your model's behavior
┌────────────────────────────────────────────┐
│ SIGNALS — feb 17, 2026 │
│ │
│ [AGENT] reads AGENTS.md │
│ │ │
│ ├── "prefer clean code" ──→ (ignored) │
│ │ │
│ └── "never use X when Y │
│ because it nuked the build" ──→ ✓ │
│ │
│ your failures are the only config │
│ the agent actually trusts. │
└────────────────────────────────────────────┘
does AGENTS.md actually do anything?
first peer-reviewed study drops: researchers tested whether AGENTS.md files measurably change coding agent behavior. the methodology matters — they controlled for model, task, and code quality, varying only the instruction type.
key finding: normative instructions (“prefer clean code,” “write descriptive variable names”) produce no measurable improvement. diagnostic instructions — rules derived from real failures, with specific conditions and workarounds — produce significant improvement.
in other words: your AGENTS.md is only as useful as the failures that wrote it.
why it matters: we’ve been writing context files as aspiration documents. the data says they only work as failure logs. if your AGENTS.md reads like a coding philosophy, it’s decorative. if it reads like a post-mortem, it works. the discipline is the same as writing good tests — specific, verifiable, grounded in something that actually broke.
the invisible config that changes everything
someone discovered that Claude Code is silently A/B testing an “Auto Memory” feature. two accounts, same model, same codebase — one performing meaningfully better than the other. the difference: one had Auto Memory enabled as part of a gradual rollout, the other didn’t.
you can check your own status by running /memory in Claude Code.
why it matters: we’re entering the era where invisible context configuration shapes AI output more than prompt quality. same words, different memory state = meaningfully different results. the implication for personal AI OS thinking is significant: the configuration layer is the new moat, and right now most people don’t even know what configuration they’re running.
AI agent that runs on a $4/month machine
Neko: an AI agent runtime built specifically for cheap hardware — a Raspberry Pi Zero 2W or a $4/month VPS. memory is markdown files the agent reads and writes itself. short-term context for the current session, long-term context that survives reboots.
no cloud dependencies. no subscriptions. the entire personal AI OS fits on a device that costs less than a cup of coffee.
why it matters: the “personal AI OS” conversation usually assumes you can afford premium hardware and a sustained API bill. Neko is the other answer — markdown-native, self-hosted, genuinely minimal. the minimum viable personal AI is smaller than anyone’s been admitting.
parallel AI workflows, git-native
worktrunk: a Rust CLI for git worktree management, designed explicitly for running AI agents in parallel. each task gets its own worktree — not just a branch, an actual isolated working directory — so multiple agents can work simultaneously without stepping on each other.
→ github.com/max-sixty/worktrunk
why it matters: this is what “your work is a repo” looks like as infrastructure. the parallel agent workflow isn’t a research concept anymore — it needs tooling. worktree management is boring and essential, and worktrunk is the first Rust-native CLI to treat it as a first-class problem.
heretic: who controls your model’s behavior?
trending at 891 GitHub stars in two days: heretic, a tool for automatic censorship removal from local language models. not a jailbreak you run manually — automated removal at inference time.
the interesting signal isn’t the tool. it’s that 891 people starred it in 48 hours.
why it matters: every AI assistant ships with a behavior profile set by the company that trained it, not by the person using it. when you run a local model, the question becomes: whose preferences are encoded in this thing? heretic makes that question explicit by trying to undo those preferences. whether you use the tool is a separate question. the underlying issue — who owns your personal AI’s behavior — is one of the more important questions in the personal AI OS space, and it’s not getting enough serious discussion.
18 years in. what now?
top post on r/ClaudeAI this week: an engineer with 18 years in embedded Linux asking how to recalibrate as AI accelerates. the comment section wasn’t defensive. people weren’t arguing that their skills are safe. they were genuinely rethinking.
why it matters: the anxiety isn’t “AI will take my job.” it’s “I don’t know what to get good at next.” the personal AI OS thesis sits directly here — if the execution layer is increasingly automated, the signal shifts to how you think, what you remember, and how your context is organized. the question of what skills survive isn’t answered by learning more tools. it’s answered by building better systems for your own thinking. that’s what self.md is for.
sources: HN (score 58 on AGENTS.md paper), reddit/r/ClaudeAI, github/trending