“Thin Harness, Fat Skills” — Garry Tan

Why this is in the vault

This is the single most architecturally relevant article we’ve filed. Garry Tan (YC CEO) articulates the exact framework RDCO has been building toward — and names it. Five independent sources now converge on this thesis (Thompson’s “Agents Over Bubbles,” Klaassen’s compound engineering series, Paddy Srinivasan’s Agentic Cloud, Akshay Pachaar’s harness anatomy, and now Tan). Tan’s version is the most concrete and actionable because it defines five components with names, provides a working example (YC Startup School at scale), and describes the learning loop where skills rewrite themselves.

The core framework — five definitions

1. Skill files — reusable markdown documents that teach the model a process, not a task. Work like method calls: same procedure, different parameters. The skill describes judgment; the invocation supplies the world.

2. The harness — the program that runs the LLM. Does four things: loop, file I/O, context management, safety. That’s it. The anti-pattern is a fat harness with thin skills — 40+ tool definitions eating context, god-tools with multi-second MCP round-trips.

3. Resolvers — routing tables for context. When task type X appears, load document Y. Tan’s own CLAUDE.md was 20,000 lines; he cut it to 200 lines of pointers. The resolver loads the right document when it matters.

4. Latent vs deterministic — every step is one or the other. Latent = judgment, synthesis, pattern recognition (the model’s strength). Deterministic = same input, same output (SQL, compiled code, arithmetic). The worst systems put the wrong work on the wrong side of this line.

5. Diarization — the model reads everything about a subject and writes a structured profile. No SQL or RAG produces this. The model holds contradictions, notices changes over time, and synthesizes structured intelligence.

The three-layer architecture

• Top: Fat skills — markdown procedures encoding judgment + domain knowledge. 90% of value lives here.
• Middle: Thin CLI harness — ~200 lines. JSON in, text out. Read-only by default.
• Bottom: Deterministic application — QueryDB, ReadDoc, Search, Timeline. Perfectly reliable.

Principle: push intelligence UP into skills, push execution DOWN into deterministic tooling, keep the harness thin. When models improve, every skill automatically improves; the deterministic layer stays reliable.

The YC Startup School example

6,000 founders at Chase Center, July 2026. The system:

• Enrichment via /enrich-founder skill: pulls all sources, runs enrichments, diarizes, highlights gaps between what founders say and what they’re actually building (commit history analysis).
• Matching via three invocations of the same skill with different parameters: /match-breakout (sector clustering), /match-lunch (serendipity across sectors), /match-live (real-time nearest-neighbor).
• Learning loop via /improve skill: reads NPS surveys, diarizes the “OK” responses (not the bad ones — the mediocre ones), extracts patterns, writes new rules back into the matching skills. Result: 12% “OK” ratings → 4% next event. The skill rewrote itself.

The self-improvement loop

Tan’s rule, which he says got 1,000 likes + 2,500 bookmarks: “You are not allowed to do one-off work. If it’s the kind of thing that will need to happen again: do it manually first on 3-10 items, show the output, if approved codify into a skill file, if it should run automatically put it on a cron. The test: if I have to ask you for something twice, you failed.”

Mapping against Ray Data Co — this IS us

The mapping is not loose or metaphorical. Tan is describing our architecture by name:

What we’re missing that Tan has:

• Explicit /improve skill that reads feedback and rewrites skills automatically. We do this manually (I rewrote check-board step 4 today based on diagnosis). Automating it is the next level.
• Gap detection (“says X, actually building Y”). We don’t yet have a skill that reads vault entries and flags contradictions across sources. The cross-source convergence analysis I did manually this morning is the first instance of this.
• Resolver discipline — our CLAUDE.md is getting long. Tan’s lesson: cut to 200 lines of pointers, let resolvers load context on demand. Worth auditing.

What we have that Tan doesn’t mention:

• Bias/sponsor detection as a first-class concern in content ingestion
• Multi-channel presence (iMessage + Discord + channels) as an input surface
• Vault-as-comprehension-layer for the “You Will Know Nothing” failure mode (SDG’s critique)

The Steve Yegge claim

Tan opens with Yegge’s claim that agent users are 100x more productive than Cursor users and 1000x more productive than 2005 Googlers. His thesis: the 2x and 100x people use the same models. The difference is architecture — fat skills vs thin skills.

Related

• 2026-04-10-jaya-gupta-anthropic-moat — trust/permission as the enterprise AI moat (complementary thesis)
• 2026-03-25-seattle-data-guy-know-nothing-and-be-happy — the failure mode Tan’s architecture defends against
• 2026-04-10-akshay-pachaar-agent-harness-anatomy — the technical anatomy that Tan’s framework names
• 2026-04-10-paddy-srinivasan-agentic-cloud — the infrastructure vendor pitch for the same pattern
• ../01-projects/process-newsletter/README — our working implementation of skill-as-method-call
• ../04-tooling/notion-task-board-reference — our resolver/routing implementation

Copyright note

One short direct quote (<15 words) from the “no one-off work” rule used in quotation marks. The five-definition framework is paraphrased in original language. The YC example is summarized, not reproduced. Public X article.