Seven articles to a platform that improves itself

Everything you need to build an agent platform that improves its own instructions is already published, scattered across seven articles that never mention each other. The destination looks like this: agents do real work, humans leave specific feedback where the work happens, and a scheduled pass turns the accumulated feedback into reviewed edits to the very files the agents run on. Anthropic recently profiled a company running that loop in production, but the loop is the roof. The articles that teach the walls and the foundation came out separately, under titles that sound like standalone advice.

I run the whole stack as one person. A frontier-tier session plans, decomposes, and reviews; cheaper executors implement from written briefs against a 1,500-item work queue; every change lands through a pull request; a guard suite plants deliberate violations weekly to prove every check still fires; memory, decision records, and per-project rulings ledgers persist what sessions learn; and a weekly improvement pass sweeps accumulated corrections back into the instruction files that caused them. None of that design is mine in any deep sense. It is what falls out of taking the seven articles below in order.

Start with the orchestration shape, not the agent#

Building Effective Agents argues for the simplest structure that works: workflows before autonomy, and the orchestrator-workers pattern when subtasks cannot be predicted in advance. This article decides your architecture, which is why it comes first. In my platform it became a routing decision record: a supervisor session owns decomposition, brief-writing, and merge judgment, while implementation dispatches to cheaper executors with the model tier stamped on every work item. A brief must carry the goal, the exact files, the verify commands, and what is out of scope. If I cannot write that brief, the item is not ready, and no agent sees it.

Give the agent a check it cannot talk past#

Claude Code Best Practices is remembered for tips, but its spine is one rule: give the agent a verification check, because without one "looks done" is the only signal. Built out fully, that rule stops being a prompt habit and becomes infrastructure. My version is a review gate that inventories the evidence each acceptance criterion names and refuses a merge when an artifact is absent, plus a weekly job that plants deliberate violations and asserts every guard rejects them. The phrasing I carry: a check you never see fail is indistinguishable from a check that is dead.

Move memory outside the context window#

Effective Context Engineering treats context as a finite attention budget and pushes state into external notes retrieved just in time. At platform scale this becomes a filing system with teeth: a memory index loaded at session start, reference files read only when relevant, per-project rulings ledgers that record every judgment call a worker needed once, and subagents that do deep reading in their own context and return summaries. Sessions end; the platform remembers anyway.

Scale effort to the question#

The multi-agent research system post supplies the numbers the other articles lack: one agent and a handful of tool calls for a simple lookup, two to four for a comparison, double digits only for genuinely complex work, with explicit stop conditions because their agents once spawned fifty subagents for a trivial query. Those rules now sit verbatim in my orchestration and triage docs, and every dispatch brief states how much work the item buys. Parallel fan-out is the easy half; bounded fan-out is the half that keeps a subscription alive.

Design the interfaces like products#

Two articles cover what the agent touches. Writing Effective Tools for Agents says to consolidate tools around workflows, return semantic identifiers, and write error messages that state the corrective next step; auditing my own MCP server against it is a queued work item, because eighteen tools grown by wrapping an API is exactly the shape it warns about. The Agent Skills post covers the instruction side: skills as files with progressive disclosure, minimal instructions written against real failures, and one rule I had never applied anywhere: test a skill on the model tier that will run it, not the tier that wrote it. My commands, agents, and skills all live as PR-reviewed files in one repository, which is the precondition for the final layer.

Close the loop last#

The capstone article is Anthropic's case study on how Warp builds self-improving agents, and the pattern it describes only works once everything above exists, because an improver needs instruction files worth editing and feedback worth harvesting. I learned the cost of skipping it directly. One worker command line lived in two harness files; I fixed one copy, and the other stayed wrong for twenty days and two failed launches, because the correction lived in prose nothing ever swept forward. After reading the case study, I shipped my version of the loop in a day: review comments prefixed LESSON: capture corrections during normal PR review, a zero-token weekly script sweeps them into a digest along with ledger and feedback entries, and a supervisor pass turns the digest into small pull requests against the instruction files, with a guard that now makes the duplicated-command-line failure a failing check. Its first live run found an instruction gap within the hour.

What stays human#

Every layer above leaves the same residue: a person holds the gates. I review the improver's PRs, own anything touching spend or publishing, and read a morning briefing file that a scheduled job assembles from the platform's own health signals. The reading order matters because each article assumes the previous layer: verification is meaningless without decomposed work, memory without verification just persists mistakes, and a self-improvement loop without all four beneath it edits files nothing enforces.

Follow the articles in that order and the destination is not a copy of anyone else's system. It is your own platform with the property that matters: the system that does the work is also the system that gets better at it.