THE SKILL LAYER

I just deleted an AI feature from my own site. The article generator that lived behind a button on my admin dashboard, with API keys and retry queues and progress bars, is gone. In its place is a markdown file in a directory my coding agent reads.

This is a small move. But it points at something larger that has been happening for the last six months and is now hard to miss. The intelligence is moving from inside products to inside the agent that operates them.

For a while AI features lived inside products. You sign up for a model key, you wire it into your backend, you build a little UI on top, you handle errors and retries, you keep the model versions current. The product owns the relationship with the model. The user comes to your product to use the model through it.

That made sense when the most useful thing about a model was the model itself. Now the most useful thing is the agent loop wrapped around it. Claude Code, Codex CLI, Cursor's agent mode, the various IDE forks. These are environments where the model can read files, run commands, search the web, and string those together over many steps. The unit of intelligence is not a single API call. It is a session.

Once the user has an agent, every app that wants to be agent-friendly has to ask a different question. Not what AI features should we build into the product, but what should the agent do when a user asks it to interact with us. The center of gravity moves. The model is no longer something my product brings to the user. The model is something the user already has, and my product offers it affordances.

Skills are the concrete shape this is taking. A skill is a small piece of markdown that tells an agent what to do for a specific task in a specific context. Voice guidelines, file paths, the schema for a JSON insert, the bash command to invoke. It lives inside the user's agent setup, not inside my deployed product. When I want to publish an article now, my agent reads the skill, generates the prose, calls a separate CLI to make the cover image, runs my insert script, commits and pushes. No deployed model. No API key on my VPS. No retry queue. No model picker UI to maintain when the model names change every quarter.

The old generator was around fifteen hundred lines of code. The new skill is one markdown file. That ratio is suspicious. Either I lost important capability or the capability was always somewhere else.

The capability was always somewhere else. The model was doing the work in both cases. The fifteen hundred lines were scaffolding to bring the model into the product, expose a button for it, track its progress, handle its failures, save its output. Once the model lives in the user's agent, all of that scaffolding is provided by the agent harness and does not need to be rebuilt per app.

This has implications I have not fully worked out. A lot of consumer AI features start to look like they belong in the user's agent instead of the product. Summarization, drafting, generation, even certain kinds of recommendation. The product becomes a thin layer of structured affordances. The intelligence is rented from the user's session, not from the product's vendor account.

For internal tools and personal sites, this is unambiguous progress. Less infrastructure, fewer keys to rotate, no per-app cost. For consumer products, it is stranger. If the model lives in the user's agent, the product loses some of its claim on the user's attention and some of its margin. Both incumbents and startups will fight this in various ways. Bundling. Memory. Vertical integration that makes the in-product model genuinely better than the user's agent.

I do not know yet which side wins. I notice that my own habit is shifting fast. Things I would have once added to the site I now write as skills. I have not needed to open the OpenAI dashboard for new work in a while. Whatever this is, it is happening quietly enough that I am not sure most product roadmaps have caught up.