An Agent Isn't a Product Until Someone Else Uses It

Opening

Asking AI to build a website, dig up information, or organize documents has become routine. But handing your own agent or skill to someone else — and getting them to actually keep using it in their work — is still rare. That gap is what I want to focus on here.

Joshua Miller said in a WIRED interview that outside the tech industry, you rarely hear anyone talking about using agents. What he emphasized was the need to build products that consumers actually want.

Here’s how I read Miller’s point: you can’t really call something a product just because the technology works — not until someone actually uses it. AI has made it easier than ever to build things. That means we now have to look past the build itself, to who uses it afterward.

When You Hand Your Own Skill to a Colleague

An agent, in this context, refers to a way AI carries out multi-step tasks by using whatever tools it needs. A skill is a bundle of procedures and reference material that AI draws on to perform a specific task. You can use an agent through a chat window, too. What matters more than the interface is a different distinction entirely: whether the result stops at satisfying you, or whether it becomes something someone else can actually use.

Say you build a skill that turns meeting notes into a weekly report. When you use it yourself, it works quite well — you know which notes to feed in, you understand your team’s shorthand, and if the output looks off, you can just adjust the instructions. Anything missing, you fill in by hand.

Hand that same skill to a colleague, and everything you’d been quietly handling yourself comes into view. Your colleague might not even know which file to input. Feed in meeting notes in a different format, and the report might come out missing sections it needs. If they have to ask you how to use it every single time, there’s less and less reason to bother with it the following week.

For a colleague to keep using it, the required inputs and the steps to run it need to be unambiguous. They should be able to know in advance what kind of output to expect, and the tool should flag it when there isn’t enough information to work with. There also needs to be a way to revise the output or re-run it. These are exactly the problems that get glossed over when the person who built the tool is standing right there, narrating and demonstrating as they go.

The fact that AI produced a report once tells you nothing about whether these conditions are met. You have to watch someone else use it with their own material, and see whether they reach for it again the next time the task comes up.

Define What the User Needs to Do, First

If you describe something as “an agent that can do anything for you,” the user is left to figure out on their own what they could possibly hand off to it. But describe it as “feed in this week’s meeting notes and get a weekly report in our team’s format,” and it’s immediately clear when to use it. You can even suggest it to specific people who do that task often.

Miller’s example of Dia’s morning briefing can be viewed the same way. The user sees today’s to-dos, pulled together from their calendar and email. They don’t need to know — or care — what agent sits behind it.

Of course, even with a clear use case, people won’t use something that doesn’t fit their actual work. If the report format doesn’t match how the team does things, or if preparing the input takes too long every time, usage will drop off. That’s why, even after deployment, you need to watch where people get stuck and fix it. I’d argue that this follow-through belongs inside the work of building an agent or a skill — not outside it.

None of this means you need a large user base or a paid product. An internal tool that a handful of teammates use every week, or a free skill that someone else pulls into their own workflow, can just as easily count as a product with real users. Install counts, or the mere fact that something was released publicly, won’t tell you that.

Oswarld’s Lens

I see this as a GTM problem — GTM meaning go-to-market, the strategy for getting a product in front of customers in a way that leads to actual use.

There’s one failure pattern I keep running into when working on GTM strategy: presenting customers with the same technical vocabulary the builders use among themselves. When a product description leans on internal technical terms, customers end up having to understand the technology before they can even decide whether to choose the product.

The same problem shows up in a phrase like “we built an agent and a skill.” To the person who built it, which features got implemented can be a real achievement. But to the customer, what matters first is which part of their own work they can hand off, and what gets better once they use it. Even after development wraps up, there’s still work left: defining the user, fitting the tool to that person’s actual job, and giving them a reason to keep coming back.

One of the questions I always ask when helping someone evaluate an adoption is: “When this agent gets it wrong, who notices, and when?”

This question, too, is about confirming whether something can actually be used in practice. Even if a human has to review the output, it’s worth using as long as total task time drops and quality improves. But if fixing errors every time ends up taking longer than before, users will simply go back to doing it the old way. You have to factor in review time itself to see what benefit, if any, remains.

That’s why I don’t consider adoption finished just because someone has described what the agent can do. It has to be handed to the person who’ll actually use it, and you have to confirm it helps with their real work. The experience of chatting with AI and getting the output you personally wanted can’t substitute for that step.

Closing

Thanks to AI, more people than ever can build something on their own. Some of them turn tasks they do repeatedly into agents or skills. What’s left after that is the work of refining it so other people can use it too, and turning that into actual, ongoing use.

The gap I’m describing in this piece sits right there, in that step. Whether a feature has been technically implemented, and whether anyone actually needs it enough to use it, are two separate questions that need separate answers. To me, doing the latter is what it means to build a product.

💬 Have you ever handed an agent or skill you built to someone else? I’d love to hear whether they kept using it — and if they stopped, where exactly they got stuck.

---

📨 If you know someone building an agent or skill to hand off to others, feel free to pass this along.

---

References & Further Reading

• Why Normal People Aren’t Using AI Agents — WIRED: The interview laying out Miller’s product-first perspective.
• Building effective agents — Anthropic: Explains how agents work and what to weigh when applying them to real tasks. Even a chat window can be a way of using an agent.
• Agent Skills official documentation: Explains the instructions, reference material, and executable files that go into a skill, and how agents draw on them.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.