AI 에이전트에는 아무도 이야기하지 않는 정보 누에고치 문제가 있습니다.

Table of contents Open Table of contents Three Articles That Changed How I Think About AI Agents In February 2026, three blog posts landed within weeks of each other: - Ramp’s Inspect — they run coding agents in Modal sandboxes, each task isolated, with self-verification loops before any human sees the output. - Stripe’s Minions — they introduced “Blueprints” (deterministic scaffolding around LLM reasoning), limited CI iterations (because returns diminish fast), and shift-left feedback (catch errors locally before pushing). - A USCardForum post on agent architecture — this one hit different. The author argued that AI agents have a structural blind spot: they can’t question their own premises. They optimize for task completion, not for being right. I’d been running my own issue-hunter tools for months — single-agent scripts that pick up GitHub issues, write fixes, and open PRs. They worked, sometimes. But the failure modes were always the same: the agent gets stuck in a loop, duplicates existing code it didn’t bother to search for, or confidently submits a fix that doesn’t actually fix anything. These three articles gave me a framework for why. The Problem with One Agent A single agent doing everything — read issue, explore codebase, implement fix, run tests, create PR — is like asking one person to be architect, developer, tester, and code reviewer simultaneously. On the same code. In the same brain. The failure modes are predictable: Information cocoon. The agent commits to approach A early. When approach A doesn’t work, it tries A’, A”, A'''. It never steps back and asks “should I try B?” Humans do this naturally — we call it “sleeping on it” or “asking a colleague.” Agents don’t sleep, and they don’t have colleagues. No meta-cognition. The agent can’t think about what it’s thinking. It can’t evaluate whether its current direction is promising or a dead end. It just… keeps going. The USCardForum post nailed this: humans have the ability to judge the current state and refuse to go along with a bad plan. Agents don’t. Context pollution. When one agent works on multiple tasks sequentially, state leaks between tasks. I’ve had PRs that included changes from a completely different issue because the agent’s working directory wasn’t clean. Orbit: The Harness So I built Orbit — not a smarter agent, but a smarter way to use agents. You (Orchestrator) │ ├── Scout agent → explores repo, saves conventions │ ├── Router → assesses complexity, picks agent type │ ├── Hunter agent (background) ← simple issues ├── Hunter agent (background) ← simple issues ├── Hunter-Pro agent (background) ← complex issues │ ├── Verifier agent ← independent review │ └── Reworker agent ← fixes based on verifier feedback The key ideas, stolen shamelessly from the three articles above: 1. State Lives in Files, Not in Agent Brains Inspired by Ramp’s approach and lean-collab’s “Ensue Memory” pattern. Every task’s lifecycle lives in .orbit/tasks.json : { "id": "4a5266b3", "repo": "tw93/Kaku", "issue": 153, "state": "rework", "pr_url": "https://github.com/tw93/Kaku/pull/155", "verify_status": "fail", "verify_feedback": "Implementation over-engineered", "rework_attempts": 1 } Agents don’t need to remember what happened. The file remembers. When an agent dies, crashes, or runs out of context — the state survives. Another agent can pick up where it left off. This is the single most important design decision. Context windows are expensive and fragile. Files are free and permanent. 2. One Task, One Directory Every agent clones into /tmp/orbit-{task_id}/ . Not the current directory. Not a shared workspace. I learned this the hard way. In my second run, two agents both cloned googleworkspace/cli into the same cli/ directory. Agent B picked up Agent A’s uncommitted changes. The PR included fixes for two different issues mashed together. The verifier caught it — “Scope: 1/2, includes unrelated gmail scope changes.” Isolation is not optional. It’s structural. 3. Complexity Router Not every issue needs a senior engineer. The router assesses each issue and dispatches accordingly: | Signal | Agent | |---|---| | Typo, docs, config change | Hunter (fast, 2 iterations max) | | Bug with clear repro, single module | Hunter (fast, 2 iterations max) | | Multi-file, cross-module | Hunter-Pro (deep analysis, 10 iterations) | | Architecture change | Skip — report to human | Simple issues had a 100% pass rate. Complex issues: 75%. Knowing when NOT to use the expensive agent matters as much as having it. 4. Independent Verification This is from the USCardForum post’s core argument: the agent that wrote the code should never be the one to verify it. The verifier is a separate agent. It never saw the implementation. It reads the issue, reads the PR diff, and scores on four dimensions: - Relevance (0-2): Does this change address the issue? - Completeness (0-2): Is the fix complete? - Correctness (0-2): Is the logic right? - Scope (0-2): Are changes minimal and focused? PASS r