{"slug": "agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for", "title": "Agent-Led Growth(ALG): What I learned from talking to startups building for developers", "summary": "Developer-focused startups are shifting from generative engine optimization toward \"agent-led growth,\" optimizing content so coding agents like Claude Code, Codex, Cursor, and OpenCode can find and implement their tools, according to findings from Lightsage's study of more than 1,650 prompts across nine coding agents and ten developer-tool categories. Lightsage found no single agent recommendation, with different model-and-harness combinations preferring different tools for similar tasks, pushing founders to publish benchmarks, use server-side rendering, maintain llms.txt files, and keep documentation small enough to avoid context window bloat.", "body_md": "Over the last few months, a new topic keeps showing up in almost every conversation I have with developer-focused startup founders: how to market to agents.\n\nAt first, I assumed this was a subset of GEO (generative engine optimization): make sure ChatGPT, Claude, Gemini, and other LLMs can find your product. But after talking with founders and builders from Firecrawl, Supabase, Sapient, Headroom, and a dozen others, I came away with a different conclusion.\n\nAgents, especially coding agents are a fundamentally different beast from answer engines. And that changes the game.\n\nA lot of GEO discussion today centers on brand awareness and consumer experiences. But coding agents like Claude Code, Codex, Cursor, and OpenCode don’t just answer questions: they search documentation, read source code, generate code, call APIs, execute commands, debug failures, and retry workflows.\n\nWhen a developer says, *“add a database”* and lets Claude handle it, the agent doesn’t just suggest; the database it picks **becomes** the database that ships.\n\nIn other words, agents don’t stop at recommendation. They are long-running workflow systems that continue all the way into implementation and execution.\n\nDiscovery typically starts with the model’s training data. Companies with a strong presence across GitHub, Reddit, Stack Overflow, documentation sites, and OSS ecosystems naturally have an edge, as they appear more frequently in the training corpus.\n\nBut training data has a shelf life (model’s cutoff date). For a developer who just wants something that works, that’s a silent, frustrating failure.\n\nWhat stood out to me is that recommendations are not simply rote pattern-matching against a memorized list of tools. They are highly context dependent.\n\nWhen a user asks: “*What are the best options for X and what are their tradeoffs*?” or “*Find a tool that can solve Y*”, or when the agent is simply uncertain, it often goes beyond its prior knowledge and turns to real-time web search, repository inspection, documentation retrieval, and other sources of external context.\n\nThat’s where having agent-ready content starts to matter.\n\nOne of the more interesting datasets I came across came from **Lightsage****,** which ran more than *1,650* prompts across nine coding agents (Claude Code, Codex, Cursor, Gemini, Hermes, Kilo Code, OpenCode, OpenClaw, and Pi) spanning *ten* developer-tool categories, including authentication, databases, email, payments, sandboxes, search, vector databases, and voice infrastructure.\n\nWhat they found was revealing: there is no single “agent recommendation.” Different combinations of models and coding harnesses often preferred different tools, even when given similar tasks.\n\nIn other words, discoverability is no longer just about ranking highly in one search engine. It increasingly means showing up consistently across a fragmented ecosystem of agents, models, and execution environments.\n\nAcross conversations with founders and builders, a few practices consistently surfaced:\n\n• **Publish benchmarks and comparison pages** to directly address “X vs. Y” queries\n\n• **Use server-side rendering** so the full-page content is already embedded in the HTML when it’s delivered, agents read pages the way a basic web crawler would\n\n• **Maintain an** llms.txt file, a curated, agent-facing overview of your product: key APIs, common workflows, and where to find authoritative documentation\n\n• **Publish fresh content** with recent dates to signal relevance to retrieval systems\n\nThere are also a few challenges founders raised around discoverability are worth flagging:\n\n**Context window bloat**\n\nSeveral founders noted that having a large volume of documentation, skills files, and .txt files can actually bloat the context window and cause agents to lose critical information. As a result, some have redesigned their docs to fit cleanly inside a coding agent’s context window: when the agent is working through an integration, it gets higher accuracy and makes fewer mistakes.\n\n**Manual testing at scale**\n\nOne developer told me how he manually monitored Claude’s recommendation behavior for his OSS project: repeatedly prompting to see why his project wasn’t surfacing, then revising README content, tags, and other signals until it consistently appeared. Testing on one coding agent is manageable. But when you’re dealing with a fragmented market of 10+ [coding agents](https://github.com/sorrycc/awesome-code-agents), each with different model versions and harness methods, it quickly becomes a real distraction from actually building the product.\n\nAs several founders pointed out, visibility is only half the problem. Once an agent discovers your product, it still has to know how to successfully use it.\n\nSupabase’s recent blog post, [AI Agents Know About Supabase. They Don’t Always Use It Right](https://supabase.com/blog/supabase-agent-skills), makes this point clearly: despite most models having seen plenty of Supabase code in their training data, knowing about it and knowing how to use it correctly are two different things.\n\nGoing back to the workflow in *Figure 1*, recommendation is only the first step. Once an agent decides to use a product, it still needs to navigate documentation, install packages, generate code, authenticate, call APIs, debug failures, and complete the task.\n\nThese failures compound. A single broken integration isn’t just a failed task. It becomes feedback. If agents repeatedly encounter friction, missing documentation, or unreliable workflows, they may gradually bias toward alternative tools that have historically produced cleaner results. Usability problems can eventually become distribution obstacles.\n\n**Common failure modes I’ve observed:**\n\n*Search docs*\n\nAgents can hallucinate URLs or documentation paths that don’t exist — assuming the docs live at\n\n*docs.company.com/docs* when they actually live at *docs.company.com/introduction*\n\n*Install package*\n\nAgents may install an outdated SDK version, pull deprecated examples from training data, or generate configuration based on old auth flows.\n\n*Generate code and execute tools*\n\nAgents can import the wrong module, encounter MCP server connection issues, or hallucinate API endpoints and CLI commands (e.g., *xyz execute* when the correct command is *xyz run)*\n\n*Debug failures*\n\nEven when the underlying issue is trivial, generic error messages can derail the workflow. An MCP server authentication failure surfacing as a vague connection error is enough to stop an agent cold. A human developer would inspect logs and recover quickly. An agent often lacks the context to diagnose the root cause and may simply abandon the integration for another tool.\n\n**What some startups are already doing about it:**\n\n1. **Simulate integrations and tool calls**\n\nCompanies like [Lightsage](https://lightsage.com/) help growth teams monitor how coding agents (Claude Code, Cursor, Codex, OpenCode, Pi, Hermes, and others) run against their product, observe where they fail, and surface quick fixes. They’ve helped one fintech fix 100+ broken URLs, and another reduce 20+ unnecessary navigation steps to help agents efficiently reach the right documentation for execution.\n\n2. **Follow documentation conventions**\n\nLike it or not, agents rely heavily on learned internet patterns. One founder described restructuring their docs to match the conventions agents naturally look for:\n\n*/quickstart*\n\n*/examples*\n\n*/introduction*\n\n*/api-reference*\n\nSeveral startups also redesigned their APIs with typed SDKs. Typed SDKs expose expected inputs, outputs, and data structures explicitly, rather than forcing an agent to infer parameters from prose documentation, the SDK itself becomes a machine-readable guide. This is one reason tools with strong OpenAPI specs, typed SDKs, and well-defined schemas tend to perform better during autonomous integrations.\n\n3. **Teach agents judgment and taste, not just facts**\n\nRather than simply publishing more documentation, Supabase introduced a concise ~100-line [SKILL.md](https://github.com/supabase/agent-skills/blob/main/skills/supabase/SKILL.md) file that teaches agents how to work with Supabase correctly, such as always verifying against current documentation; how to troubleshoot MCP and CLI issues; where to fetch docs; common security pitfalls. They’ve also built a comprehensive [troubleshooting page](https://supabase.com/docs/guides/troubleshooting) with detailed error codes, descriptions, category tags, and dates.\n\nThe distinction matters. A docs page tells an agent what your product does. A SKILL.md teaches it how to think about using your product. That’s a fundamentally different kind of artifact.\n\nWhat I kept hearing across these conversations is an evolution from discoverability to usability and reliability. The first hurdle focuses on making sure agents could find and understand a product, and the playbook is becoming clear: llms.txt, skills.md, comparison pages, benchmark publication, and agent-friendly documentation. The second hurdle is harder: the challenge is shifting from “Do agents know us?” to “Can agents successfully operate us?”\n\nAs a [recent study from Amplifying AI](https://amplifying.ai/research/claude-code-picks) shows, agents already exhibit surprisingly strong preferences for a relatively small set of tools. Those preferences are likely shaped by a combination of training data, available documentation, ecosystem adoption, and, increasingly, accumulated execution success. In other words, agents may begin to develop their own version of default stacks.\n\nThat has interesting implications. If UI was the interface of the SaaS era and APIs were the interface of the cloud era, agent experience may become the interface of the agent era, and perhaps an entirely new category of product in its own right.\n\n[Agent-Led Growth(ALG): What I learned from talking to startups building for developers](https://pub.towardsai.net/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for-developers-14e185dcc686) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for", "canonical_source": "https://pub.towardsai.net/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for-developers-14e185dcc686?source=rss----98111c9905da---4", "published_at": "2026-10-16 15:31:01+00:00", "updated_at": "2026-10-16 15:48:36.743019+00:00", "lang": "en", "topics": ["ai-agents", "generative-engine-optimization", "ai-crawlers", "ai-search", "developer-tools"], "entities": ["Lightsage", "Firecrawl", "Supabase", "Sapient", "Headroom", "Claude Code", "Codex", "Cursor"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for", "markdown": "https://wpnews.pro/news/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for.md", "text": "https://wpnews.pro/news/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for.txt", "jsonld": "https://wpnews.pro/news/agent-led-growth-alg-what-i-learned-from-talking-to-startups-building-for.jsonld"}}