There is a pattern I keep seeing.

Someone opens a free chat window. They ask a real question. The answer comes back fast, fluent and sure of itself.

Part of it is wrong. Part of it is missing. Nothing in the answer says so.

They try twice more. Same thing. They close the tab and decide AI is overhyped.

That conclusion is reasonable. It is based on the wrong product.

The free chat is the smallest version of the thing, with most of the useful parts switched off. Judging AI on it is like judging cars on a rental with the handbrake on.

This is the starting guide. It is the page I send people to when they tell me AI doesn't work. It explains why the free chat lets you down, what the real thing is made of and the five steps that move you from chat to agents.

No vendor deep dives here. Those come in the next parts.

1. Why the free chat gets it wrong

Six reasons. They stack.

The free plan runs a smaller model

A model is the part that reads your text and writes the reply. They come in sizes. Bigger models cost more to run and know more. Smaller ones are cheaper, faster and wrong more often.

Every vendor gives the free plan a smaller model and keeps the best one for paying users. I checked the plan pages on 13 November 2026:

• ChatGPT Free runs GPT-6 Luna. GPT-6.1 Sol needs Plus, at $20 a month.
• Claude Free runs Sonnet and Haiku. Opus needs Pro, at $20 a month.
• Gemini Free gets the Flash-Lite model and Gemini 4 Hydrogen. The Pro model needs AI Pro, at $19.99 a month.

How big is the gap? Artificial Analysis runs a test called AA-Omniscience [1]. It asks hard factual questions across many fields and counts how many come back right.

OpenAI's free model gets 39.6% right. The $20 one gets 61.8%.

Anthropic's free model gets 51.5%. The $20 one gets 65.5%.

That is the same question, the same company, a different plan. On OpenAI's side the paid model answers about half as many questions again correctly.

The free plan is a demo of the product, not the product.

One honest caveat. These scores are run at the highest effort setting. The free app may run its model at a lower setting than that. So the real gap you meet on a free plan is likely wider, not narrower.

Google is the generous one. Gemini's free plan includes a strong model, with a quarter of the usage of the paid plan. If you refuse to pay anything, start there.

Thinking is off, or rationed

Newer models can "think" before they answer. They write a hidden draft, check it, then reply. Vendors call this reasoning or thinking mode. It is slower and costs more to run, so free plans ration it or leave it off.

The difference is not small. Same model, GPT-6.1 Terra, same test. With thinking off it gives a wrong answer instead of saying "I don't know" 77.1% of the time. With thinking at maximum it does so 34.5% of the time [1].

Same brain. Less than half the confident nonsense. One switch.

Search is off

A model learns from a snapshot of text that ends on a date. After that date it knows nothing. Ask about a price, a law or a product from last month and it fills the gap with something plausible.

Web search fixes that. The chat looks the answer up and shows you where it came from. On many free setups search is limited, or only runs when the model decides it needs it.

It knows nothing about you

You know your goal, your budget, your constraints and what you tried last week. The model knows none of it.

So it answers the average question from the average person. Then you get an average answer and call it generic.

It doesn't check itself

A plain chat writes the answer once, top to bottom. Then it hands it over. No second pass. No sources unless you ask. Nobody reviews it.

It agrees with you

This one is measured. Researchers at Anthropic tested five leading assistants and found they tend to agree with the user, even when the user is wrong [2]. People and the models that score answers both sometimes preferred a convincing answer that agreed with them over a correct one.

A second paper explains why models guess at all [3]. Training and testing reward a confident guess over "I don't know". So the model learns to guess.

Put the six together. A small model, no time to think, no fresh facts, no context, no check, keen to please. That is the free chat.

The wrong answers aren't a mystery. They're the design.

2. The map: three layers

Every answer you get comes from three layers.

The model is the brain. It reads text and predicts the next words. Some are small and cheap, some big and slow. Some are closed, some you can download.

The harness is everything around the model. The hands and the desk. Thinking time, search, your files, memory, tools, checks. The same model in a better harness gives a much better result.

Access is how you pay and sign in. A free plan, a $20 plan, or an API key: a password that lets software call the model directly and bills you per use.

When an answer is bad, one of the three layers is weak. On a free plan the weakest one is access. Access decides which model you get and which parts of the harness are switched on.

Fix that first.

3. Three levels: chat, assistant, agent

Chat answers one question from memory. "What is a good laptop?" You get a list that could be from any year.

Assistant knows your context, searches the web and reads your files. "Compare these three laptops for my use, with links." You get an answer for you, with sources you can open.

Agent does the work in steps and checks it. "Sort my receipts folder into a spreadsheet and flag the odd ones." It opens the files, builds the sheet, checks the totals and tells you what it could not read.

An agent is a model in a loop. It plans, uses a tool, looks at the result, decides the next step and keeps going until the task is done or it gets stuck.

Each level needs the one below it. You can't run an agent well if you don't know how to brief an assistant.

4. Five steps

Step 1. Pay for one plan. Turn thinking and search on.

About $20 a month. One vendor, not three. Part 2 compares them.

This is the single biggest jump. It buys you the best model, more thinking, more search and the agent tools in the next steps. Cowork from Anthropic is not on the free plan. Codex in the browser and in the terminal starts at ChatGPT Plus.

Then find the switches. Every app has a model picker and a thinking or reasoning toggle. Pick the top model. Turn thinking on. Turn search on.

To see what AI can do, you need at least the $20 plan. Everything below it is a sample.

If $20 is a real problem, use Gemini's free plan and turn on everything it offers.

Step 2. Give it context

The prompts in this section are examples. Swap in your own.

Before:

What should I eat to lose weight?

After:

I'm in my forties. I cycle twice a week. I cook for a family of four and I hate meal prep on Sundays. I want to lose 5 kg in four months without counting calories. Suggest a weekly pattern I can actually keep.

Better still, make it permanent. Most paid apps have projects: a folder with your files and a standing instruction that applies to every chat inside it. Put your context there once.

Step 3. Ask in structure

Four parts: goal, context, constraints, output.

Before:

Write an email to my landlord about the heating.

After:

Goal: get the heating fixed this week.
Context: broken since Monday, I reported it by phone on Tuesday, nothing happened.
Constraints: polite, firm, under 120 words, no threats.
Output: the email, then a one-line subject.

The model is good at following a brief. It is bad at guessing one.

Step 4. Make it check itself

The model doesn't verify unless you ask. So ask.

Before:

What are the rules for renting out my flat short term in Milan?

After:

What are the rules for renting out my flat short term in Milan? Search the web. Cite the official source for each rule with a link. Then list what you could not confirm and what I should check with the city myself.

And after any long answer:

Now review your answer as a sceptical expert. What is wrong, missing or out of date?

That second prompt costs you ten seconds. It catches more than you would expect.

Step 5. Run a first agent on a small real task

Pick something boring, real and low-risk. A folder of receipts. A messy downloads directory. Twenty PDFs you need summarized into one page.

Use the agent tool in your paid plan. Claude Cowork works on a folder you choose on your computer. ChatGPT has a Work mode in its desktop app. Codex runs from the browser or the terminal.

Before:

Can you help me organize my receipts?

After:

In the folder Receipts-2026, read every file. Build a spreadsheet with date, shop, amount, currency and category. Flag anything you could not read and any duplicate. Don't move or delete any file. When done, tell me what you checked and what you are unsure about.

Give it a folder, not your whole disk. Tell it what it must not do. Read its report before you trust the sheet.

5. What goes wrong next

You trust the agent too much. It sounds sure when it is wrong, same as the chat. Check the first few runs line by line. Loosen up when it earns it.

You paste private data without reading the settings. Some plans can use your chats to improve their models. Find the data settings and read them before you paste a contract, a medical letter or anything about someone else.

You get a surprise bill. A subscription has a fixed price. An API key bills per use. An agent in a loop can use a lot. If you go the key route, set a spending limit first. Part 2 covers this.

You give up after one bad run. One run tells you little. Change the brief, add context, ask it to check. Three tries with a better prompt beat one try and a verdict.

6. Where I would start

Tonight, pay for one $20 plan. Pick the top model, turn thinking and search on.

Then paste the prompt at the end of this piece. It interviews you and writes your standing instruction.

Tomorrow, run one small agent task on a folder you don't care much about. Read what it did.

That's it. A week of this and the free chat will feel like a toy.

What I am probably getting wrong. I lean on one benchmark for the free against paid gap. AA-Omniscience tests hard factual recall. Your questions may be easier and the gap smaller. I also can't measure what effort setting each free app really uses. Vendors change their free plans every few months. The prices and model names here are as of 13 November 2026. Check them before you buy.

The free chat is AI at its cheapest.

Cheap was the point.

Pay for the real one, then judge it.

TL;DR

• Free chat gives worse answers by design: smaller model, rationed thinking, limited search, no context, no checking, a habit of agreeing with you.
• On a hard factual test, OpenAI's free model gets 39.6% right and the $20 one 61.8%. Anthropic: 51.5% against 65.5%.
• Thinking on cuts confident wrong answers from 77.1% to 34.5% on the same model.
• Every answer comes from three layers: model, harness, access. On a free plan, fix access first.
• Three levels: chat, assistant, agent.
• Five steps: pay about $20 and switch on thinking and search, give context, ask in structure, make it check itself, run a first agent on a small task.
• To see what AI can do, you need at least the $20 plan.

Set me up

Copy this into your new paid chat. Thinking on. It does the rest.

You are going to set me up to use you well.

Interview me, one question at a time, about:
1. My work and what I spend most time on
2. My goals for the next three months
3. Tools, files and apps I use every day
4. How I like answers: length, tone, format
5. Things I never want you to do

After the interview, write my standing instruction:
under 200 words, in the second person, ready to paste
into my settings or a project. Include a rule that you
search and cite sources for any fact that can change,
and that you say "I don't know" when you don't.

Then suggest three small tasks from my answers that
an agent could do for me this week, each with a
ready-to-use prompt.

Where to go next

• Part 2. Vendors. Who sells what. Subscription against sign-in against API key.
• Part 3. Harness. Why the same model gives a different result. The tools that make the difference.
• Part 4. Open. Open-weight models, Hugging Face and OpenRouter.
• Part 5. Specialist. The models that are not chat: image, speech, music, 3D, documents.
• Part 6. Local. Running models on your own machine.

To see the latest model rankings yourself: Artificial Analysis (artificialanalysis.ai) and Arena, formerly LMArena (arena.ai/leaderboard).

References

[1] Artificial Analysis, AA-Omniscience accuracy and hallucination rate, read 13 November 2026. https://artificialanalysis.ai

[2] Sharma, M. et al. "Towards Understanding Sycophancy in Language Models." arXiv 2310.13548. https://arxiv.org/abs/2310.13548

[3] Kalai, A. T., Nachum, O., Vempala, S. S., Zhang, E. "Why Language Models Hallucinate." arXiv 2509.04664. https://arxiv.org/abs/2509.04664

[4] Plan pages, read 13 November 2026: https://claude.com/pricing, https://gemini.google/subscriptions, https://learn.chatgpt.com/docs/pricing

The tools got faster again. Why is there still so much work?

On 18 September I opened the cloud console of cairn, the knowledge store I built for my agents and me to write into. Two collections. Not three.

The whole Home Assistant and homelab collection was gone. Thirteen pages. No alert. A line in a startup log nobody reads. The system looked healthy, in his own opinion.

I found it because I was testing the thing.

TLDR: That’s the article.

The joke, before it gets old

In 1983 a historian called Ruth Schwartz Cowan wrote a book called More Work for Mother [1]. Washing machines and vacuum cleaners were sold as time saved. Housework hours did not drop. The machines replaced the work of servants and kids and husbands. Then the standard of clean went up to fill the space.

Swap the mother for a guy with too many repos.

In the last few weeks my agents and I made 602 commits across three projects. “Edgar”, the small agent engine I build to learn, went from version 1 to version 4 in a little more than a week.

I have never had this much built for me. I have five projects running in parallel and a list of more. I can’t stop.

Classic me.

An idea I keep having

Humans make tools. That’s the oldest thing we do.

Tools and knowledge grow exponentially. We don’t. We are linear beings running on a brain that was finished a long time ago. So it feels like everything changes and nothing really does. Our ambitions grow as fast as the tools. Our intelligence doesn’t.

In 1925 a biologist called Alfred Lotka had a name for this: exosomatic evolution [2]. Endosomatic tools come with the body. Legs, claws. Exosomatic tools you make. They are not part of you. Animals adapt the slow way, by selection over generations. We adapt by building.

The body did not stop, to be fair. Cooking probably reshaped our guts. Dairy farming changed who can digest milk as an adult. Both layers still run. But the fast one is the tools. It’s the one we steer.

(a thought for later: is AI reshaping us?)

The last time we stopped reading the output

In 1952 Grace Hopper had a working compiler (a program that turns human-readable code into machine instructions). Years later she said: “Nobody believed that. I had a running compiler and nobody would touch it. They told me computers could only do arithmetic.” [3]

In 1957 John Backus shipped FORTRAN. Programmers back then hand-tuned machine code and did not trust a program to write it for them. Backus wrote that they were convinced efficient programming “could not be automated” [4]. His team spent most of its effort on the optimizer, the part that made compiled code almost as fast as hand-written code. That’s how the trust was earned.

Today nobody reads the machine code their compiler spits out. Nobody calls that lazy.

We just moved up one step again. From coding to directing and reviewing.

A tool that made monsters

In 1959 COBOL was designed to read like English, so managers could write their own programs [5]. No more waiting on specialized programmers.

It didn’t go that way. COBOL ran banks and governments for sixty years. Today it’s a language nobody wants to work in. The fantasy of removing technical skill made monsters.

So is AI the next COBOL? Maybe. I don’t know. We will soon see, I guess.

The difference I can see is small and it matters. This time the tool can help fix what it made. As long as the complexity is managed.

What I actually read (it’s not the code)

I read almost none of the code. With exceptions.

Edgar I had to read, because I built it to learn and made it readable on purpose, it was the entire point. The other repos, i guess maybe 5%.

What I do read is everything around the code. Every question the agents ask me. Every task review and sprint review. Every postmortem. Every thread on a feature or a bug. Edgar alone has 68 ADRs (architecture decision records, one short file per design decision, with the why in it).

That’s where I use my judgement.

Software development is complexity management.

The Logistics of Ideas

Dijkstra said it in 1970: “The art of programming is the art of organizing complexity” [6]. Fred Brooks split the work in two in 1986 [7]. The essential part is deciding what to build. The accidental part is the labour of building it.

I agree with every line.

(another thought: AI is picking up the accidental part.)

If complexity is managed correctly it doesn’t really matter how the code got written. It can be fixed.

If you know it’s broken.

Job number two is tester

Back to the missing pages.

cairn keeps its data safe by streaming a copy to cloud storage through a tool called Litestream. On 15 September that stream stopped moving. A stall throws no error. For about 59 and a half hours the copy sat still while the app kept serving from its own disk. Every restart after that rolled back to the stale copy without a word. It turned out to be a known open bug in Litestream, issue #1515 [8].

The agents traced it, wrote it down and recovered the data. Then a fix built from an unmerged upstream branch went in. Its first restore wrote a corrupt snapshot. The safety check did its job and stepped back to an older clean point. Thirteen pages gone. Not the first loss that week. That’s the day I counted two collections instead of three.

A fix that lost data. Reverted the same day. Everything recovered from the copy on my laptop. Three ADRs.

No check caught it. I did, because I was working with the data.

Kernighan and Plauger wrote a statement i love in 1978: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” [9]

Now point that at a model. If it writes at the limit of what it can do, the same model is not capable enough to debug it. Somebody has to notice.

So the human in the loop matters more now. Not less.

Job one is directing and reviewing. Job two is tester.

A compiler earned trust by being predictable and checkable. A model is neither, not yet. That’s why I read the postmortems, track decisions, annotate roadmaps.

The operator sets the sign

The last article ended with a promise. Here it is.

These tools multiply. A multiplier does nothing to a small number. And it has a sign.

Engage with it. Read the decisions, use it. It multiplies you.
Offload to it. Hand over the thinking, stop looking. It divides you.

Same tool. Opposite results.

The research on automation says the same. Complacency hits experts too. Practice alone does not fix it [13].

It’s an old worry. Plato has a king warn that writing will give people “the appearance of wisdom” and not the real thing [12]. He was half right. Writing made us smarter as a species and let a lot of people look smart without being it.

Think of an architect with a crew that builds anything, fast. A good drawing gets built early. A bad drawing also gets built early. The crew never tells you the drawing is wrong.

The pitch says these tools close the gap between the expert and the beginner. I see the opposite. I think the gap is getting wider. Faster than ever.

What I am probably getting wrong

A lot. As usual. But this is how I learn.

The measurements are a mess. METR ran the best known trial in 2025 and found experienced developers 19% slower with AI while they believed they were faster [10]. Sixteen developers, early 2025 models. In 2026 they tried again and the study broke. Developers in the research refused to work without AI. Between 30 and 50% avoided submitting tasks they expected AI to handle well [11]. (And beware the research is also quite unscientific in itself, the numbers are unreliable in both directions).

Mine too. More than 1,400 commits in a month, across all my repos, is output. Value is another question. One guy is not a sample. N of 1 is not real research.

And “you can always fix it” is exactly what a monster says right before it eats you. It held this time because I happened to look.

Where I would start

1. Make the agents write every decision down. One short file each, with the why. Read those, not the diff.
2. Ask for a postmortem on every bug. Even the small ones. Especially the small ones.
3. Use what you build. Daily. You are the sensor nobody wrote.
4. Keep one copy that doesn’t go through the clever path. Mine was sitting on my laptop and it saved me more than once.

The tools got faster.

The work got bigger.

Somebody still has to look.

TL;DR New tools raise the ambition faster than they cut the work. We evolve through what we build. Lotka called it exosomatic evolution. The tools now grow much faster than we do. The job moved up a step, from coding to directing and reviewing, the same move compilers forced in the fifties. Software is complexity management. The code can always be fixed, if somebody notices it’s broken. So job number two is tester. My agents lost thirteen pages of my data. No check caught it. I did, because I was using it. The tool multiplies whoever engages and divides whoever offloads.

And if you have the time read the books I linked, great stuff written by the giants on whose shoulders we stand.

Try it. Paste this into whatever agent you build with:

From now on, for every change you make:
1. Write a short decision record: what you decided, the options you rejected, why.
2. After every bug, write a postmortem: what broke, how it was found, what stops it next time.
3. End every session with a review: what changed, what is untested, what I should try by hand.
4. Tell me the one thing I should use today to check it still works.
I will read these instead of your code. Write them for a person, not for a compiler. Be concise, write like I am 12.

Most of the work is already done. You just have to read it. And then use the thing.

References

[1] Ruth Schwartz Cowan, More Work for Mother: The Ironies of Household Technology from the Open Hearth to the Microwave, 1983. https://hss.sas.upenn.edu/content/more-work-mother-ironies-household-technology-open-hearth-microwave

[2] Alfred J. Lotka, Elements of Physical Biology, 1925, on exosomatic instruments. Discussed in: https://www.sciencedirect.com/science/article/abs/pii/S0921800915004243

[3] Grace Hopper, quoted in the OCLC Newsletter, March/April 1987. https://cs.yale.edu/homes/tap/Files/hopper-wit.html

[4] John Backus, “The History of FORTRAN I, II, and III”, 1978. https://softwarepreservation.computerhistory.org/FORTRAN/paper/p25-backus.pdf

[5] “It’s COBOL all the way down”, Increment. https://increment.com/programming-languages/cobol-all-the-way-down/

[6] Edsger W. Dijkstra, Notes on Structured Programming, EWD249, 1970. https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD249/EWD249.html

[7] Frederick P. Brooks, “No Silver Bullet: Essence and Accident in Software Engineering”, 1986. https://www.cs.unc.edu/techreports/86-020.pdf

[8] Litestream issue #1515. https://github.com/benbjohnson/litestream/issues/1515

[9] Brian Kernighan and P. J. Plauger, The Elements of Programming Style, 2nd ed., 1978, chapter 2.

[10] METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[11] METR, “We are Changing our Developer Productivity Experiment Design”, February 2026. https://metr.org/blog/2026-02-24-uplift-update/

[12] Plato, Phaedrus, 274b to 277a. https://newlearningonline.com/literacies/chapter-1/socrates-on-the-forgetfulness-that-comes-with-writing

[13] Raja Parasuraman and Dietrich H. Manzey, “Complacency and Bias in Human Use of Automation: An Attentional Integration”, Human Factors 52(3), 2010. https://doi.org/10.1177/0018720810376055

The web lost the human-authored link. Agents might be how we get it back. Will it work this time?

I did not have a name for it until last week.

For a a few weeks I had been building a few wikis of my own notes. Not a folder of Markdown. A few small webs: pages linking to each other, every link carrying a tag that says what the relationship is. supports. contradicts. refines. same-shape-as. I find the wiki both comforting and technically fit for building diy semantic graphs of my own randomized stuff.

Ten relation types. Twenty-nine pages. I had to pick the right one every time, which was the annoying part and the entire point. Then I started building a tool so agents could write into one without an approval step. Then I needed a real corpus to test it on, so I made one.

Somewhere in the process it came to me this silly idea: I am building little internets.

What actually I was missing (for so long that I forgot)

The web did not die. One property did: the link as an act of judgement.

A person read a thing, decided it was worth pointing at, then linked to it. That choice carried information. It is what made PageRank work. It is what made a blogroll a map of a mind.

The feed replaced the link with the recommendation. A recommendation is not a judgement by someone who read the thing. It is a prediction about what will hold your attention. Links still exist. They stopped being how anyone moves.

I was confused at first

The argument I wanted was easy. This is the semantic web finally working, because agents remove the annotation burden that killed it. Everyone knows it failed because hand-tagging was too much work.

I am an expert in rabbit holes. So I read the sources first. The story is wrong and (imho) misattributed.

Doctorow’s “Metacrap” is cited everywhere as the obituary. The words “Semantic Web” do not appear in it. Neither does RDF, or Berners-Lee. It predates the article it supposedly rebuts. [1] Shirky’s 2003 essay, the most cited critique, explicitly denies the laziness thesis. [2] Norvig, quoted forever as having demolished it with the word “incompetence”, opened with “I am not against the Semantic Web.” [3]

Three sources. Three misreadings.

What they actually say is duller. Nobody could agree what to encode. Nothing consumed it that paid. And the syntax defeated its own authors: Tim Bray, who co-invented RDF/XML, never once managed to write a chunk of it correctly. [4] That is a complaint about the serialization. The triplet survived into JSON-LD and every knowledge graph in production. RDF/XML did not.

It half won anyway

Schema.org is the same idea with the ontology stripped out. Global entity URIs abandoned. Formal knowledge representation dropped for a browsing aid. In 2016 structured markup was on 38 percent of pages and 16.5 percent of domains. By 2024 it was 51 percent and 44 percent. [5]

And the mechanism kills the laziness story. RSS took off when Blogger emitted it automatically. Schema.org took off on WordPress plugins. Annotation volume is a function of tooling defaults, not diligence. People annotate at enormous scale. They need telling which vocabulary, then paying something for the trouble.

So why not blogs again

Blogs had all of it. Free, real, shared, a named face behind every one. We loved them. Then they died.

My read:

A blog cost its author nothing to neglect. It sat there, read or unread. The writer was unaffected either way. Quality was a virtue. Virtues are optional.

A little internet is what my own agent reasons from. Let it rot and my tools get worse. Quality stops being a virtue and becomes maintenance. That is the new thing. Not the links, not the ownership, not the semantics. Use.

Same for agents polluting at scale. A polluted wiki is a polluted agent memory. Self-harm, not vandalism.

Islands and bridges

Second objection: a thousand private wikis are a thousand islands.

We are not going to build islands without bridges. Federation is not an unsolved protocol problem. It is what a link already is. Blogs federated by linking and search engines did the rest. If I make one public I share the link.

Every objection I raised against this idea assumed a new mechanism was needed. Every answer was that the old one still works and we stopped using it.

Who does the tagging

The two halves of my argument pull against each other. Agents make edges cheap, which is the whole bet. GraphRAG already inverts the 2001 vision this way: the LLM builds the graph. [8] But I also said choosing the tag yourself is most of the value.

Where I have landed: the agent proposes, I dispose. It suggests the edge and the relation. I accept, change the tag, or throw it out. Reviewing a proposed contradicts takes three seconds. Deciding one from scratch takes a minute.

At twenty proposals a day it works. At two hundred I would rubber-stamp.

Perhaps I can write a skill good enough to auto-approve 80% of them? Possible, once I hit that scale I will see what i need to do.

What the machines get from it

An untagged link makes an agent re-derive the relationship on every traversal. Expensive. Different every run. A tagged link is the relationship, decided once. Retrieval stops being “find things near this” and becomes “find what contradicts this”.

One real number exists. GPT-4 over an enterprise SQL database scored 16 percent. Same questions over a knowledge graph of the same data: 54 percent. Forty-three questions, one domain. Not a law. [6]

Just be careful which claim you buy. There is no verified AI-driven graph database boom. [12] What’s real is graph-shaped retrieval, and the real life, honest version is that hybrid beats either alone. [7]

The barrier moved. It did not go away.

Here is the objection I expected to lose to. If agents write this syntax now, the old blocker is gone, so why not do the semantic web properly this time?

Bray could never write RDF/XML correctly. That complaint is obsolete. So I tested what replaced it.

Twelve SPARQL queries against Wikidata, from memory, single-shot, no lookups. Then I asked Wikidata what every identifier I had used actually means. [13]

Every query was well-formed. Twelve out of twelve. Bray’s problem is dead. Twenty of twenty-two identifiers were right. Two were not:

Q92624   I believed: Guido van Rossum    actual: Dan Bricklin
Q662772  I believed: Neuromancer         actual: Berg

Look at the first one. Q92624 is a real person with a real notable work. That query runs. It returns VisiCalc. It looks like an answer. The second returns nothing. Neither raises an error. Both would sit in a graph forever.

The barrier moved from authoring to grounding. Grounding fails quietly. Bad syntax fails in your face. A wrong identifier fails silently and stays.

Scale will not fix this. At the 2026 TEXT2SPARQL challenge, the entry running Claude Sonnet 4.6 scored roughly 0.34 answer F1. [9] And the number that explains it: putting the schema in the prompt took execution F1 from 0.00 to 0.28 on unseen graphs. Zero without it. [10] The variable was never model strength. It is whether the machine knows what the names mean. [11]

Every failure above is the same failure. I was guessing at names somebody else assigned. The schema.org team hit that wall and wrote it down: coordinating entity references across sites is “much too difficult for most sites”. So they stopped requiring it. Identifiers stayed optional and reconciliation became the consumer’s problem. [16]

One of my wikis has twenty-nine pages, ten relation types and one author. There is no Q92624 to get wrong. I cannot build the web for agents, because identity does not survive strangers. I can build my own little internets, because inside one namespace identity is free. That is the condition under which the machines stop guessing.

What I am probably getting wrong

Not enough experience, not enough tests. I am generalizing about the future of the web from a stack of my own notes.

Nobody has run the test on my corpus. The closest systematic one gives graphs a conditional win, not a victory. [7]

Tags decay when you stop choosing them carefully. supports does no work if everything is supports. At five hundred pages nobody tags conscientiously. Half-tagged is worse than untagged because it looks finished.

It might also be nostalgia with better plumbing. I have a bias here.

What I have actually built

Arguments like this are cheap and code is not, so here is what exists. [14]

I wrote this article while building cairn . A tool that creates, manages, stores, indexes and searches wiki and tables your agents can write to, with every change reviewable. Keyword search and meaning search over one SQLite file, the embedding model running inside it so nothing leaves the server. Every write is a revision you can undo. Html pages “dumpable” to disk or object storage.

It needs nobody’s permission. That is the point.

Why I build this stuff

I believe in grassroot adoption. The choice of the single has terrifying impact at scale. An algorithm that manipulates perception has done real damage to our societies.

My driving kernel has always been openness and freedom and personal accountability. That last one is the part people skip. Openness and freedom describe the feed as well as the early web. Accountability is what separates them.

I believe in the small guy. I hate the greedy corp toxic approach. I do not expect to fix anything. I most likely got everything wrong and nobody will care. It’s still ok. It’s one more voice. It makes me feel better.

The web was never wrong. It was missing an agreement. It was missing something that paid.

Now this little internet has both, because the thing consuming it is mine.

TL;DR

The web lost the human-authored link. The feed replaced judgement with prediction.

The semantic web story you know is wrong. Doctorow’s “Metacrap” never mentions it. Shirky denies the laziness thesis. Norvig opened with “I am not against the Semantic Web.”

The syntax barrier is gone. The grounding barrier is not. I wrote twelve SPARQL queries from memory. All twelve parsed. Two pointed at the wrong thing, silently.

A little internet is a small private web where every link says what it means. One namespace, one author, so identity is free. That is the condition under which machines stop guessing.

Where I would start

Take the notes you already have. Pick five relationships that matter in your domain. Write the list somewhere you will see it, because the list -in this age- matters more than the software.

Now go and build one

Point an agent at that folder and paste this.

Read my notes in this folder.

First, propose five relationship types that would be useful between these specific notes. Not generic ones. Five that fit what is actually here.

Then for each pair that should link, tell me which relationship it is and one line on why that one and not another. Do not add a link where the relationship is vague.

Then tell me which notes ended up with no edges at all. Those are either the most original things I have written or the ones I have not thought about properly, and I want to know which.

Now take the notes, the relations and make a wiki. Make it HTML with links. Annotate the links with the relationships between pages, make it simple, make it human and machine readable. This is your memory. Maintain it.

Now make a skill out of this and use it to record memories. 

That last question is the useful one. The unconnected notes tell you something the connected ones cannot.

Then keep going by hand, one link at a time. The agent is the librarian. The judgement stays yours.

References

1. Cory Doctorow, Metacrap: Putting the torch to seven straw-men of the meta-utopia, 26 August 2001. Does not mention the Semantic Web, RDF or Berners-Lee. people.well.com

2. Clay Shirky, The Semantic Web, Syllogism and Worldview, November 2003. “People can share data without having to share a worldview, so we got the meta-data without needing the ontology.” archive

3. Peter Norvig, panel remarks, 2006. Three obstacles, not one. He meant webmasters.

4. Tim Bray, 2003. “I have never actually managed to write down a chunk of RDF/XML correctly, even when I had the triples laid out quite clearly in my head.” Followed by: “I helped invent the RDF syntax, so I’m as much to blame as anyone.”

5. Web Data Commons, structured data from Common Crawl. 2016 · 2024. Their 2024 page reports 51.25 percent where the underlying counts give 52.1 percent.

6. Sequeda, Allemang and Jacob, A Benchmark to Understand the Role of Knowledge Graphs on LLM’s Accuracy for Question Answering on Enterprise SQL Databases, 2023. arXiv:2311.07509

7. RAG vs. GraphRAG: A Systematic Evaluation and Key Insights, February 2025. Same corpora, same settings. 13.6 percent graph-only correct, 11.6 percent vector-only, hybrid best. Graph extraction captured only 66 percent of answer entities. arXiv:2502.11371

8. Edge, Trinh et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization, April 2024. Read the scope: global sensemaking over roughly million-token corpora, judged by an LLM. arXiv:2404.16130

9. TEXT2SPARQL Challenge 2026, results 13 May 2026. The LIBER-AI-CLAUDE entry, backed by Claude Sonnet 4.6: CK26 F1 0.336, DB26 F1 0.348. Answer-set F1, not execution accuracy. text2sparql.aksw.org

10. Wardenga and Käfer, 2025. ShEx shapes in the prompt, execution F1 from 0.00 to 0.28 on unseen knowledge graphs. KIT

11. SAGA, July 2026, naming “type-blind grounding” as the dominant failure mode: plausible triple patterns, incompatible types, empty results. arXiv:2607.14494

12. Neo4j’s $325 million Series F, June 2021. TigerGraph’s $105 million Series C, February 2021. Both predate the current cycle. There is no verified AI-driven graph database boom.

13. My test. Twelve single-shot queries, twenty-two identifiers, one afternoon, popular entities. It shows a mechanism, not a rate. Execution accuracy could not be measured: Wikidata’s query service was in an active outage throttling to one request per minute. Run it yourself and it will disagree with me on different ones. github.com/vespassassina

14. cairn · edgar · peptide-wiki · artifactkit

15. R.V. Guha co-created RDF, RSS and schema.org. He shipped NLWeb in May 2025, described as playing a similar role to HTML for the agentic web. If you are wondering whether someone is already building the public version of this: yes, it is him. NLWeb

[16] Guha, Brickley and Macbeth, Schema.org: Evolution of Structured Data on the Web, ACM Queue 13(9), November 2015. From the “Entity References” section: “Many models such as Linked Data have globally unique URIs for every entity as a core architectural principle. Unfortunately, coordinating entity references with other sites for the tens of thousands of entities about which a site may have information is much too difficult for most sites.” So schema.org requires unique URIs only for its own vocabulary terms and leaves consumers to reconcile entities from descriptions. sameAs exists for this and, in their words, "has not found much adoption". Note this was three authors, not Guha alone. queue.acm.org

An Agent Is Only As Smart As What It Can Reach.

The clever part is free now. The boring part, what it can actually see and trust, is the whole job.

I caught my own agent lying to me last week (bad boy!). Politely. But with great confidence.

I was building a wiki of my own notes. I wanted to reference a well-known engineering essay, Jay Kreps on The Log, which is actually good stuff. The agent summarized it beautifully.

Then I asked it to fetch the actual page. A 404. Then a broken redirect. The essay had moved. The agent had never opened it. It had described a thing it could not reach, from memory (whatever we agree that is), then smuggled the guess as knowledge.

Nothing about the model was wrong. It was doing exactly what a language model does. The failure was not intelligence. It was reach.

Here is the uncomfortable part. I only caught it because I had built something to catch it. Before that discipline existed, a guess and a fact looked identical. I could not tell them apart a week later, which means some of them were wrong and I never knew which one. The near-miss is not the happy ending. It is the warning.

That is the whole subject of this piece. Retrieval gets written about constantly as a technique. Almost nobody talks about it as the boring majority of the work, the part that quietly decides whether any of the cleverness actually matters.

Capability is free. Reach is not.

Here is the trade that reorganized how I think about all of this.

The clever part keeps arriving for free. Every few months a new model lands and everything gets smarter at no effort from me. Reasoning. Code. Language. All of it improves while I sleep.

Reach does not improve while I sleep. What an agent can actually reach and check is something I build by hand, one connection at a time.

So the gap between an impressive demo and a useful system is almost never the model. It is whether the thing can reach the data the answer depends on.

A model that cannot see your calendar cannot reason about your week. It does not matter how brilliant it is. Ask it what you should move tomorrow. It will produce something fluent and plausible and COMPLETELY DISCONNECTED from your actual Tuesday.

The intelligence was never the bottleneck. The bottleneck is the boring 80 percent (are we going with Pareto, really?).

What grounding actually means

Grounding is a vague word, so here is the concrete version. It is four separate problems wearing one coat.

Connection. Can the agent physically reach the source at all? An API. A file. A database. A page. This is the plumbing. It fails in dull, specific ways. The endpoint moved. The token expired. The page 404s. My Kreps essay was a connection failure. Connection failures are the honest ones, because they announce themselves.

Permission. Can it reach the source as you, with your rights instead of its own? I hit this wiring a tool to my own work data. The tool ran as the agent, so it queried the system as the agent and got the agent’s view. Which was almost nothing. To see what I see, it had to carry my authority through to the source, not its own. An agent with its own identity lives in a different world than i do. Ask it what a system returns for you. Unless it can borrow your rights, it answers for itself, then calls it yours.

Freshness. Is what it reached actually current? A cached value. A stale snapshot. Last quarter’s number. This one is vicious, because the answer looks fine. Nothing 404s. It is just quietly wrong by three weeks.

Trust. This is the one everybody skips. There is a difference between data an agent can see and data it can believe. My agent could see its own memory of the Kreps essay. It could not verify a word of it. Seeing is not trusting. A system that cannot tell the two apart will hand you a confident guess every single time.

Capability improves all four of these by exactly nothing. A smarter model reaches a stale number faster. It describes an unread essay more convincingly. Reach is a separate axis. It is the one you own.

Reach is why I run four agents, not one

If you see me on my pc you might assume I run several agents in parallel because more is better. That is not it. I run them because they reach different things.

Claude Code lives inside a code repository and holds a long thread across hours. Hermes runs its own lane with its own context. GitHub Copilot sits inline in the editor, tight loop. Scout reaches the desktop and my work data. Files. Calendar. Messages. The browser.

The point is not that four beats one. A repository agent cannot see my calendar. A calendar agent cannot see my repository. No amount of model quality closes that gap (and i am not sure i want to even close it). Reach is the thing that varies between them. Reach is the thing I am actually selecting for.

A few habits fell out of running them this way. Pick the tool by what it can reach, never by the logo. Protect a deep thread instead of interrupting it for a trivia question. Use a file as the handoff, because there is no shared brain between them, so the shared state has to live somewhere they can all reach.

And accept that nothing coordinates them but me. That last one, the human sitting in the middle deciding what to point where, turns out to be a whole argument on its own. It is something i need to reflect and write about, eventually, so I will leave it there.

The fix is a discipline. An unglamorous one

Once you see reach as the real problem, the fix is not a clever model. It is a boring habit, applied relentlessly.

I have been rebuilding my personal notes as a wiki. It turned into the clearest example of grounding I have.

It is not built by me alone. It is not built by the agent alone. It is the sum of the two. The whole design exists to keep the agent honest about what it has actually reached.

Every claim page carries an evidence class. Lived. Measured. Researched. Or a plain hunch. The label is not decoration. It is the difference between something I checked and something I just believe (legacy of working with graphs and ontologies).

Every link between ideas carries a relation tag. Not a lazy “see also”. A stated reason. This supports that. This contradicts that. This is the same shape as that. Ten relation types.

Every external source gets its own page that says, in the first line, whether I have actually read it. Right now the wiki has 21 idea pages and 6 source pages. Five of those six sources are marked, in plain text, as not yet read.

That last number is the point. Five unread stubs, labelled as unread, sitting there slightly embarrassing me every time I open the folder. That is grounding working. The system knows the difference between a source I have reached and one I am still guessing about. It refuses to let the guess wear the same clothes as the fact.

The Kreps essay is one of those five. The agent described it. I could not verify it. So it is a stub with a to-do on it. Not deleted. Not pretended into a citation. Flagged, honestly, as reach I have not yet closed (i actually did read it just before finishing this).

What I am probably getting wrong

I am not sure reach stays a separate axis forever. Models are starting to arrive with their own tools, their own browsing, their own memory. Some of the plumbing I build by hand today will be built in tomorrow. Maybe the boring 80 percent slowly shrinks.

I suspect it does not shrink as much as people hope. Every new capability needs new grounding underneath it. The frontier of what an agent could reach keeps moving faster than the wiring to reach it safely. The 80 percent may just move rather than vanish.

I also cannot fully solve freshness. I can flag what is unread. I am much worse at flagging what was fresh when I reached it, then quietly went stale since. A read source can rot the same way an unread one can mislead. I do not have a good sensor for that yet.

My whole setup also assumes I am the router. If that job ever automates, I lose the one point where a human currently catches the confident guess before it ships. I do not know what replaces me there. More agents? Maybe from different vendors? A consortium of intelligences ?

Where I would start

If you want to feel this rather than read about it, do one small thing.

Take a task you already trust an agent with. Now ask it one question out loud. What did it actually reach to produce this? And how does it know that source is real and current?

1. Make it name its sources instead of summarizing them.
2. Make it fetch one, live, in front of you. Watch whether it actually can.
3. When it cannot, do not let it smooth over the hole. Make it say “I could not reach this.”
4. Write that gap down somewhere it will nag you, not somewhere it disappears.
5. Only then worry about whether the model is clever enough. It almost always already is.

The habit is the product. The model is just the part that arrives for free.

Capability is what the model brings. Reach is what you build. The second one is the whole job. And it’s dull and boring and doesn’t make good click bait.

That is exactly why it is worth doing.

TL;DR

An agent is only as smart as what it can reach. Capability arrives free with every new model. Reach, what the thing can actually reach and verify, you build by hand and maintain forever.

Grounding is four problems, not one:

1. Connection. Can it reach the source at all. These failures are honest. They 404.
2. Permission. Can it reach the source as you, with your rights instead of its own.
3. Freshness. Is what it reached actually current, or quietly three weeks stale.
4. Trust. The one everyone skips. Seeing a thing is not believing it. A system that cannot tell those apart hands you a confident guess every time.

A smarter model improves none of these. It reaches a stale number faster and describes an unread essay more convincingly.

The fix is a discipline, not a model. Label every claim with how you know it. Tag every link with why it connects. Mark every source, in plain text, as read or unread. Let the unread ones sit there and nag you. My own wiki has five unread source stubs right now, labelled as unread. That is grounding working, not failing.

And: I caught my own agent describing an essay it had never opened. The model was fine. The reach was missing. That gap is the whole subject. It is the 80 percent nobody wants to write about.

Now go and check one

Open whatever you use. Give it a task you already trust it with.

Then paste this underneath.

Before you answer, tell me exactly what you will reach to produce this:
which sources, which data, which files.

Then fetch one of them, live, right now, and show me it worked.

For anything you cannot actually reach, do not summarize it from memory and do not paper over the gap. Say plainly: "I could not reach this."

List separately:
- what you reached and verified
- what you are reconstructing from memory without reaching it
- what is probably stale even though you reached it

I want the second and third lists to be honest, not empty.

If the second and third lists come back empty every time, that is not a good agent. That is one that has not learned to admit what it cannot reach. Teach it to. Write the gaps down somewhere they nag you.

That is the whole discipline. The model was always going to be clever enough.

The ones that survived all do the same handful of things. I am still getting plenty of it wrong.

I noticed it on a Tuesday.

I was typing the same 400 words into a chat window for maybe the fifteenth time. Same context, same constraints, same “no, not that data source”, same “check the totals before you show me anything”. By the time the agent gave me something useful I had spent longer briefing it than the job would have taken me alone.

That was the moment prompt engineering stopped making sense to me.

A great prompt is a performance. It works once, everyone claps, it evaporates. Next week you rebuild it from memory, slightly worse, in more of a hurry.

So I started saving them. Then naming them. Then adding structure, rules, scripts, gates, state.

Today I have nearly 100. I use about 30 regularly. I keep making more. I keep rewriting the old ones. Every round they get a bit more meta: more gates, more memory, more state, more tests.

Two things before I go further.

I am new at this. So is everybody. Anyone presenting themselves as an authority on agentic development in 2026 is selling something. It is probably a course.

I am also making mistakes right now that I will find embarrassing by Christmas. I will point at a few on the way past.

Three eras, quickly

Scripts. You write code. It does exactly what you said, forever, until the world moves underneath it and it breaks loudly. Deterministic and brittle.

Prompts. You describe what you want. You get something in the neighborhood. Flexible and unrepeatable. You cannot hand a prompt to a colleague and expect your result, because half of it never left your head.

Skills. You write a contract. What this is for, when to reach for it, where the data lives, what has already gone wrong, what to do when it goes wrong again and what finished actually looks like.

A skill is the first thing in this space that is durable and adaptive at the same time. That combination is the entire point.

What one actually is

Strip away the platform differences and every agent skill I have written has the same skeleton.

A name.

A description packed with the phrases a human would really say.

A body in plain prose. Goal, inputs, sources, procedure, output shape, failure handling, refusal conditions.

Optionally, code. Scripts the agent runs instead of improvising.

That is it. Markdown and intent. The most valuable professional asset I own is a folder of text files, which I find funny and slightly alarming.

The format is not the interesting part. The interesting part is which ones are still alive after a year.

1. The description is a router, not documentation

Classic first-skill mistake. I made it 40 times.

I wrote lovely descriptions. “Analyses consumption trends and produces an executive summary.” Accurate, tidy, never fired once, because I have never said that sentence out loud in my life.

What I actually type is “why did that drop”, or “gimme the deep dive”, or “what happened last month”.

The description is not there to explain your skill to a human. It is there so a model can match a messy real sentence to the right tool at the exact moment you are tired and typing badly.

My live skills have descriptions stuffed with my own ugly phrasings, including the lazy ones and the half sentences.

They read worse. They work.

Write the description last, after you have run the thing manually ten times. Harvest the actual words you typed.

2. Encode the failures, not the happy path

This is the one that changed how I build.

I have a skill that pulls records out of an internal system. First version described the query. Clean, short, correct.

Then I ran it from a hotel and got a 403. The agent, being helpful, concluded I lacked permission and wrote me a polite paragraph about contacting my admin.

I did not lack permission. That system sits behind an IP allowlist and I was on hotel wifi.

Ouch.

So I opened the skill and added a section that says: if you see this exact error, it is the network path. Not the token, not the user’s access. Say “get on the VPN”. Do not send them off to request something they already have.

Now every mature skill I own has a section like that. In the good ones it is longer than the instructions. They read like maintenance logs.

This API returns an empty set instead of an error when the filter is wrong. This file is encrypted at rest so the normal reader will not open it, use the other path. This number always looks broken on the 1st, that is expected, here is why. If the pull returns zero rows, do not publish zeros. Restore last known good and label it clearly.

A skill is where you keep the scar tissue.

Everyone writes about capability. The value compounds in the failure knowledge. Capability arrives free with the next model. Scar tissue you have to earn one wasted afternoon at a time.

3. Push determinism down, keep judgment up

Early on I let agents do the arithmetic and the file writing inline. It mostly worked, which is worse than failing, because “mostly” stays invisible until somebody makes a decision on top of it.

The rule I landed on:

If a step has exactly one correct output, it belongs in code. If a step needs someone to read the situation, it belongs in prose.

So my heavier skills are now thin coordination layers over real scripts. Fetch, transform, validate, render, all code. What matters, what to flag, how to say it for this audience, that stays with the model.

Nice side effect: when something breaks you instantly know which half broke. Deterministic failures throw stack traces. Judgment failures produce confident nonsense. Completely different repairs.

The skill is the contract between the two halves.

4. Make it hand you a receipt

The most useful line I ever wrote into a skill was not an instruction. It was a required output.

Roughly: always report how many records matched out of how many expected, the date of the newest data point, which sources were unreachable and anything missing.

Before that, output looked finished whether or not it was. A report with three items missing looks exactly like a report with nothing missing. That is the specific trap that makes people quietly stop trusting agentic output forever.

Now every run ends with its own receipt. 25 of 25 matched. Data through last Friday. One source unreachable.

I read the receipt before I read the content. If the receipt is wrong the content does not matter.

Confidence in these systems does not come from them being right. It comes from them being legible when they are wrong.

5. Write down what it must refuse

Every skill that touches other people carries an explicit boundary.

Never send anything outbound without showing me the exact text and the exact recipients first. Never invent a record you could not retrieve. If a source is unavailable, say so and stop. Do not approximate.

That last one earns its place. An agent with a hole in its data has two options. Tell you about the hole, or smooth it over with something plausible. Left alone, models are agreeable. Agreeable means smoothing.

Skills that write their own memory

Here is the thing that took me longest to understand.

A context window is not memory. It is a desk. Everything on it gets swept off at the end of the session. The next one starts clean, with no idea what you decided last time.

Memory is a filing cabinet. Nobody builds the cabinet for you.

So my skills write files.

A plan file. For anything multi step, the skill writes a plan to disk early and updates it at milestones. It survives the conversation being compacted. It lets me audit the reasoning afterwards instead of trusting a summary. And when a run dies halfway, the next one picks up from a real artifact.

State carried between runs. I have a tracker that regenerates weekly. First version threw away every note I had added, every single week, because regeneration meant starting clean. Now the skill writes a small state file keyed by item id. The next run reads it back and re-attaches my notes to the rows that still exist. The agent forgets. The file does not.

Append only logs. Comments and decisions get added, never rewritten. History that can be edited is not history.

Last known good. When an upstream source returns nothing, the skill does not publish zeros. It restores the previous good snapshot and labels it as stale with a date. Publishing zeros is how you get a very calm meeting about a catastrophe that did not happen.

Deferred decisions, with reasons. When I skip something, the skill records what I skipped and why. Six weeks later I do not re-litigate it from scratch, which is otherwise exactly what I do.

None of this is glamorous. It is the difference between an agent that impresses you on Monday and one you still rely on in November.

The skills that manage the skills

This is where it got genuinely interesting and where I have wasted the most time.

Once you pass roughly 20 skills, the library itself becomes the problem. So I started building skills whose subject is other skills.

A skill that writes skills. Give it a rough workflow and it produces a properly shaped one: gates, refusal conditions, required self report, state handling. The point is not saving typing. It is that every new skill is born with the good habits already in it, instead of me remembering to add them on a good day.

A skill that finds candidates. It mines my own history for work I keep re-prompting and proposes turning the repeats into skills. It surfaced things I had manually re-explained eleven times without noticing. That is the Tuesday from the top of this article, automated, which is either elegant or a bit sad.

Orchestrators. One entry point that resolves scope, calls the specialist skills that are actually relevant, assembles the result, checks it and reports the gaps. The orchestrator’s real product is the gap list. Anyone can assemble a document. Telling me precisely which five things are missing and unverified is the part that saves me from walking into a room underprepared.

Gates. My favorite one runs a validation loop where each stage can fail the whole build. Static checks, then logic, then geometry, then a visual check, then performance. Nothing ships if a gate fails. Turns out “the agent checked its own work” only means something when checking has teeth.

Drift detection. Something that watches for upstream changes to shared skills and asks me, per item, whether to take the update. With the reason recorded either way.

Honest bit: meta skills are also where most of my mediocre ones live. I have built beautiful abstractions for things I ran twice. The rule I try to hold now is that a skill earns a meta layer after it has hurt me three times, not before.

What I am probably getting wrong

In no particular order, my current suspicions.

I have too many. Discovery is now its own problem. I have descriptions quietly competing for the same trigger phrases.

I over engineer early. I keep adding structure to things that needed a paragraph.

I barely test. Most of my skills have no test at all. The ones with real gates are the exception rather than the standard (i will go to developers hell for this).

I have no reliable way to notice when a skill silently degrades. It does not break. It just gets a bit worse. Then I find out from a person, which is the wrong sensor.

If you have solved that last one properly, I would genuinely like to hear about it.

Where I would start

Pick the task you have already done manually five times and resented every time.

1. Do it manually once more, saving every instruction you type.
2. Write the goal, the sources, the output shape.
3. Add the failure you already know about. There is always at least one.
4. Add a required self report.
5. Add one thing it must never do.
6. Move the boring deterministic parts into a script.
7. Write the description last, in your own ugly real words.

It will be worse than mine at first and better than any prompt you have ever written, because it is the only version that still exists next month.

Scripts told computers what to do. Prompts told models what we wanted. Skills tell agents how we work.

The third one is the one that compounds.

TL;DR

A prompt is a performance. A script is brittle. A skill is a contract that survives a changing world.

Five things the survivors do:

1. Description written as a router, in the ugly words you actually type, not as documentation.
2. Failures encoded, not just the happy path. The skill is where you keep the scar tissue.
3. Determinism pushed into code, judgment left in prose. You want to know which half broke.
4. A receipt on every run. Legible when wrong beats confidently finished.
5. An explicit refusal condition, because models smooth over gaps unless you forbid it.

Two things almost nobody writes about:

A context window is a desk, not a filing cabinet. Make skills write plan files, carry state between runs, append rather than overwrite and fall back to last known good instead of publishing zeros.

Past about 20 skills, build skills about skills. One that writes new ones with the good habits baked in. One that mines your history for what you keep re-prompting. Orchestrators whose real output is the gap list. Gates with teeth. But earn the meta layer after something has hurt you three times, not before.

And: I have nearly 100 and only about 30 earn their keep. I am figuring this out in public and I am certainly wrong about some of it.

Now go and do it. I did most of the work.

Open whatever you use. Claude, ChatGPT, Copilot, the thing your employer gave you.

Paste this article in. Then paste this underneath it.

You just read an article about what makes an agent skill survive.

Build me one. The task is: <the thing you keep redoing by hand>

Apply every rule from the article.

1. Write the description last, as a router. Use the ugly phrases I would
   really type, not a tidy summary. Ask me what I type if you do not know.
2. Ask me what has already gone wrong with this task. Write those failures
   into the skill with the exact error and the exact fix. Not the happy path.
3. Split it. Anything with one correct answer goes into a script. Anything
   needing judgment stays in prose. Tell me which is which and why.
4. Require a receipt on every run: what matched out of what was expected,
   how fresh the data is and what was unreachable.
5. Add one thing it must refuse to do. Add one thing it must never send
   without showing me the exact text first.
6. Make it write state to a file, so the next run knows what this run decided.
7. Add gates that can actually fail the build. Not "check your work".
   Named checks, each one able to stop delivery on its own.

Then, before you hand it over, tell me what is missing. At least three
specific things. "It looks good" is not an answer, it is a skipped check.

Ask me anything you need. Do not guess.

Answer its questions honestly, especially the one about what has already gone wrong. That is the part that makes the skill yours instead of generic.

It will get the first version wrong. Fix it and write the fix back into the skill.

That is the whole loop.