Why agent launches disappear
The agent category produces more announcements per week than any reader can track, and they make the same three claims in the same order.
It is autonomous. It uses tools. It does the work end to end.
Those claims are true of nearly every agent shipped in the last two years, which means they carry no information. A reader who has seen forty of these has built a template, recognises yours as the forty-first inside two seconds, and moves on. The post is filtered before quality is assessed.
There is a second problem specific to this category. Capability claims about an agent are unfalsifiable in a post. Nobody can tell from a paragraph whether your agent completes the task or fails in the third step, and readers who have been disappointed before assume the latter.
The wider version of this problem applies to every AI launch, and agents have it worst.
How the two everyone names grew
Ask that room again and the two names that come back are usually OpenClaw and Hermes Agent. Neither of them won because a benchmark said so. Both grew the same way, and the pattern is repeatable.
A community formed around using the thing, and use cases were seeded into it. The content that travelled was never the announcement.
It was people showing what they had done with it: setup walkthroughs, a workflow someone automated, a task nobody expected it to finish. Guides aimed at people who wanted to try it and did not know where to start reliably outperformed anything the projects said about themselves.
That distinction matters more than it sounds. An announcement asks a reader to believe a claim.
A use case gives them something to copy, and copying is a much lower bar than believing. The reader who copies it becomes the next person posting about it.
The second stage is where the real reach comes from. Once a topic has demonstrated it travels, the long tail of creators piles in unprompted, because covering something already proving itself is good for them too.
Nobody has to be asked at that point. The first wave establishes that the subject performs, and the rest of the timeline arrives on its own to take a share of the attention.
So an agent launch has two jobs in sequence. Give the first group something specific enough to copy, and give the second group evidence that the topic is worth their post. Capability claims do neither.
What an agent launch has to prove
The instinct is to prove capability, which is what the benchmark chart is for. Benchmarks are table stakes at this point. Everyone posts one, readers assume the evaluation was chosen because it flattered the result, and no engineer has ever switched tools because of a number in an announcement.
What moves people is specificity that could only come from having built the thing. One task, run end to end, with the parts that went wrong left in.
Publishing a real limitation is the strongest single move available to an agent launch, and almost nobody does it. It is credible precisely because a marketing team would have removed it, and it pre-empts the reply guy who was going to find that limitation anyway and post it underneath you.
- Name the task exactly. "Migrates a Rails 6 app to Rails 7" beats "handles complex engineering work".
- Show the artefact. The pull request, the diff, the file it wrote. Something a reader can inspect.
- State the failure mode. Where it stops, what it gets wrong, what needs a human. This buys more trust than any benchmark.
- Give the duration. How long it ran unattended is the number the category actually cares about.
The demo problem
Agents are unusually hard to demonstrate, because the interesting part is duration and duration does not fit in a clip. Thirty seconds of an agent working shows a chat window with text appearing in it, which is indistinguishable from every other agent's thirty seconds.
The way around it is to stop demonstrating the process and show the output. The artefact an agent produced is concrete, checkable and specific to you: the merged pull request, the completed migration, the file tree it generated, the ticket it closed. A screenshot of a real diff outperforms a produced film for this category, and costs nothing.
The second option is a timelapse with a stated wall-clock duration. "Four hours, unattended, one prompt" is a claim with a shape, and the compression makes the duration visible rather than merely asserted.
Three audiences, in order
| Audience | What convinces them | Where they read |
|---|---|---|
| Engineers who will run it | The artefact, the failure modes, and whether it works on their stack | X, then the repository |
| Engineering leaders who approve it | What it replaces, what it costs, and what happens when it is wrong | X and LinkedIn |
| The people who write about the category | A claim specific enough to quote, and a number they can attribute | X, almost exclusively |
The order matters. Engineers adopting it first is what makes the other two audiences take it seriously, and no amount of reaching leaders first substitutes for that. This is the same sequencing that developer marketing has always required, applied to a category that moves faster.
A structure that works
- The task, named exactly. One sentence, no adjectives, specific enough that a reader knows whether it applies to them.
- The artefact. A diff, a PR, a generated file. Something inspectable in the first screen.
- The duration. How long it ran without a human.
- The limitation. Where it fails. Volunteered rather than extracted.
- How to run it. A repository link or a command. Agent launches convert on immediate trial more than any other category.
Post it from a founder or engineer account rather than the company account. Personal accounts consistently outperform brand accounts on both reach and trust, and for a technical category the person who built it answering replies is a substantial part of the launch.
Timing decides the rest. Ranking systems weight how a post performs in its first stretch of life, so a company account posting cold gets capped inside thirty minutes regardless of what it says.
An amplified first wave from accounts whose audiences are actually engineers is what clears that, and it is the mechanism behind every agent launch you can name. The launch-day mechanics are here.
Questions we get asked
Why do most AI agent launches get no traction?
Because the announcement is indistinguishable from the others published that week. Readers have a template for the standard agent launch, autonomous, uses tools, does the work end to end, and skip anything matching it at a glance. The launch has to carry something only a team that built the thing could know.
Do benchmarks help an AI agent launch?
They are table stakes rather than a differentiator. Every launch claims a benchmark result, readers assume favourable selection, and nobody changes tools because of a number in an announcement. A single task run end to end, with the failures shown, moves more people than a chart.
Should we open-source the agent to get distribution?
Open sourcing gives you a repository people can inspect, fork and cite, which produces links and durable discovery that an announcement cannot. It does not produce reach on its own. A repository with no launch behind it is discovered by the people already looking for it, which is a small group by definition.