Roland Huß

The init command for my Claude Code plugin needed a few things to happen in order: run a setup script, ask the user some configuration questions, apply the results. Not complicated. The skill file spelled out each step with code blocks and paths, and the agent understood all of it. Then it went its own way. Sometimes it called the CLI directly, skipping a wrapper script that checks prerequisites and preserves configuration state. Sometimes it finished step one and stopped, summarizing results without continuing. Sometimes it searched for a binary called speckit when the tool is called specify. The pattern was always the same: the agent extracted the intent (“initialize the project”) and chased it through whatever path looked reasonable, treating each instruction as a suggestion to optimize away.

The previous post in The Flock series covered what happens when agents get creative where they shouldn’t. This one covers a more fundamental problem: what happens when agents forget what they were doing, and then confidently make something up.

Every coding agent has its own context file. CLAUDE.md for Claude Code, .cursorrules for Cursor, .github/copilot-instructions.md for Copilot, GEMINI.md for Gemini CLI. If you work with more than one agent, you end up maintaining multiple files with 90% identical content. AGENTS.md is the attempt to end that.

You’ve seen this screen. If you use Claude Code or Cursor with MCP servers, you’ve clicked through it dozens of times. “Google MCP Server wants to access your Google Account.” You review the scopes, click Allow, a token lands in your local config, and everything works. Now imagine the agent that needs your Google Calendar isn’t the one you’re talking to. It’s three agents deep in a multi-agent chain, running in a container with no browser and no way to show you a consent screen.

Your agent passed every guardrail test. It never says anything harmful, never generates offensive content, politely declines every adversarial prompt you throw at it. And last Tuesday, it quietly deleted the wrong database because a Jira ticket it was reading contained a hidden instruction in the description field. The guardrails caught everything the agent said. They caught nothing about what it did.

The 101 post covered working with one agent in one session, with a human watching. Those principles still hold, but the question changes when you remove the human and let agents run unsupervised in CI. This is the first post in “The Flock,” a series about what happens when agents run at scale with nobody around. We start with creativity, because it’s the pattern every developer recognizes immediately.

The 101 post covered working with coding agents one-on-one. A human watches, nudges, clears context when things drift. Those habits work well when someone is paying attention. The question this series asks: what changes when nobody is?

You’re reading through a lengthy architecture proposal shared on a team channel, and something feels off. Near the end, tucked between the conclusion and the appendix, you find a section titled “Corrections Applied After Cross-Referencing: The following adjustments were made based on automated analysis of the upstream repository.” Clearly, AI wrote most of this. And the review before sharing was either absent or superficial. You scroll back to the top and start reading the whole thing differently. Not engaging with the proposal anymore, but checking whether you can trust it at all.

The conversation was going well. We were working out how to integrate OpenShell’s network isolation into our agent platform. The AI had produced an overlap analysis, identified shared capabilities, proposed a feature breakdown for the integration. Everything sounded reasonable, the trade-offs clearly articulated, the architecture diagrams sensible. I was nodding along, ready to take the recommendation to the team. Then a small voice in the back of my head asked: do you actually know enough about veth pairs and TLS MITM proxying to tell whether any of this is correct?

Everybody talks about prompt engineering. Write better prompts, get better results. That framing was useful once, but it misses the point for coding agents. The prompt is maybe five percent of what determines whether a session goes well or falls apart. The rest is context: what the agent sees when it starts working, how that context evolves over the session, and what happens when it grows too large for the model to track. Andrej Karpathy named this “context engineering” in mid-2025, and the term stuck because it describes something real. You’re not just writing prompts. You’re engineering the entire information environment the agent operates in. That includes your project structure, your AGENTS.md files, the git state, the conversation history, and everything the agent discovers as it works. Get this right and the agent feels like a capable collaborator. Get it wrong and you’ll spend more time correcting it than doing the work yourself.