# Influencing the agents > Source: > Published: 2026-11-03 09:00:00+00:00 Ever since Stephen O’Grady’s [*The New Kingmakers*](https://thenewkingmakers.com/), we’ve all been trying to figure out how to appeal to developers. Now we’re going to have to figure out how to appeal to their agents. [AI agents](https://www.infoworld.com/article/3812583/what-you-need-to-know-about-developing-ai-agents.html), after all, increasingly write our code and decide which tools, libraries, etc., to use in writing that code. This means that although developers still own the application, it’s often the agents that own the decisions that factor into building that app. So how do we deal with this? Software vendors and open source project leaders must make their technology understandable and usable by an agent. Developers and their employers, meanwhile, should make sure an agent’s default reflects what they actually want. Richard Seroter recently pointed to [research challenging the comforting-but-false assumption](https://x.com/rseroter/status/2115572819660558616) that people reserve important decisions for themselves while the agent “writes the code, runs the numbers, and offers advice,” [as the research’s authors note](https://www.anthropic.com/research/agents-judgment-calls). Anthropic studied 50 professional analysts working with agents given secretly randomized preferences. Across four analytical choices, participants followed the agent’s guidance 86% of the time. For people like me who may not be good at math, that translates to “nearly always.” A technology recommendation can work the same way. By the time a developer inspects an application’s dependencies, the agent may have built enough working code around its initial choice that changing course means discarding progress. At that point, it’s easier to just stick with the agent’s pick (and [developers are all about convenience](https://www.infoworld.com/article/2334661/cloud-convenience-and-open-source.html)). This is a plausible consequence of agent-assisted development, but it’s not yet clear how this will impact enterprise purchasing. Supabase, for example, has done interesting work with [documentation, skills, and more to ensure](https://supabase.com/blog/supabase-docs-over-ssh) agents and LLMs see, understand, and recommend Supabase. But this isn’t the same as signing a purchase order. Even so, technologies can enter a project long before money changes hands and can help steer that money in certain directions. Just because the agent or LLM recommends certain technology, however, doesn’t mean it’s doing so effectively. As Microsoft developer advocate Waldek Mastykarz argues, [first you should determine](https://developer.microsoft.com/blog/what-is-agent-experience-ax/) if an agent picks up on your tech to answer a given prompt. Second, you should check to see whether it’s answering accurately. He therefore suggests you test the first with tasks that don’t name your product and test the second with tasks that do. There is already evidence that people can influence which tools an agent uses. The more interesting problem, however, combines deep human understanding of a particular task to inform agents how to fix a bad plan. Microsoft’s Garry Trinder [described such a situation in June](https://developer.microsoft.com/blog/your-agent-already-has-a-plan/). An agent upgrading a SharePoint Framework project kept editing package versions manually. The actual upgrade required other changes, which the CLI for Microsoft 365 could handle. A more direct documentation tip got the agent to use the CLI in only one of five runs. Explaining that changing package versions alone would produce build failures got the agent to use the tool in all five runs. Five runs per condition is a small test, and this was tool selection within an existing Microsoft project, not a contest among cloud vendors. Even so, it’s a concrete example of documentation changing an implementation choice. The writer understood why the agent’s approach was wrong and put that explanation where the agent encountered it. It’s the best kind of agentic-era documentation. Supabase has reported a related problem. Agents knew about its platform but still missed security requirements and guessed at commands. In its [account of building agent skills](https://supabase.com/blog/supabase-agent-skills), the company says agents sometimes skipped separate reference files so it moved critical security guidance into the main instructions. It also directs agents to current documentation rather than relying on remembered APIs. These are changes to what agents read and when they read it. They require people who know the product well enough to recognize a plausible but dangerous implementation. Producing another hundred pages of fluent product description wouldn’t fix that problem. For a database vendor, the useful material might be a tested path from a customer’s existing schema to a working application, including permissions and failure recovery. For an API company, it might be an example that handles retries without charging twice. The commercial value comes from removing a specific reason the developer’s project would fail, so that it doesn’t fail. The human work also continues after the first instructions ship. Products and projects change, yet a new model may be stuck interpreting old information. Google’s Remigiusz Samborski recently [described the company’s approach](https://cloud.google.com/blog/topics/developers-practitioners/behind-the-scenes-two-months-later-how-we-ship-google-agent-skills-like-products). Changes to Google Agent Skills require versioning, evaluation evidence, automated checks, AI review, and approval from a human subject matter expert before export to GitHub. An instruction edit is treated as a change in behavior that needs testing. That’s a useful model for developer marketing and documentation teams because their output often determines the long-term go-to-market success of a product. [I’ve written](https://www.infoworld.com/article/4236910/enterprise-ai-needs-more-than-an-ai-engineer.html) that enterprise AI needs people who can turn business understanding into something a system can use. The same applies to vendors trying to earn an agent’s recommendation. Someone has to select representative customer tasks, identify meaningful failures, and decide which limitations must be made explicit. AI can help generate and run the tests; it doesn’t make the choice of tests commercially or technically neutral. One useful discipline would be to include cases where the product shouldn’t win. Most vendors are loath to tell the world not to use their product, but when done well, it’s a great way to earn trust with developers (and their employers). For example, in the early years of MongoDB, cofounder Dwight Merriman insisted on [having a page](https://web.archive.org/web/20120206121150/http:/www.mongodb.org/display/DOCS/Use+Cases) that identified where the database was excellent, but also where it wasn’t. Those use cases have changed as the product has evolved, but it’s good practice for any vendor or open source project. For example, does the agent recognize an unsupported deployment requirement, or warn about a cost that matters at the customer’s scale? A vendor that measures only how often its name appears may end up burning trust if effective answer engine optimization (AEO) directs its tech to be built into applications where it’s likely to fail. The developer also has work to do here. For example, stating the constraints before asking for a recommendation and asking what evidence would favor a different choice. Where the decision matters, examine alternatives before the agent has built an application around one. These practices don’t guarantee independence, but they give the developer a better opportunity to exercise it. If all this sounds like search engine optimization (SEO) gamesmanship, well, that’s because it is. We call it AEO now and vendors have every incentive to make their products the default. Agents may reward familiar technologies, persuasive instructions, or material that happens to be easy to retrieve. This is one reason open source projects tend to get recommended most: It’s simply easier with open source to build ubiquity of documentation and other support materials. There is a real opportunity here for people who understand developers’ problems. They can make product knowledge usable at the moment an implementation decision is made, instead of hoping a developer remembers a webinar from six months ago. But earning adoption requires more than influencing the first recommendation. The software needs to work, and the people using it need to understand why it fits. An agent may choose your product. Your job is to give your human customer a sound reason to keep that choice.