What is Agent Preference Optimization?

A developer asks a coding agent to add error monitoring without naming a vendor. The agent reads the repository, combines that context with what it already knows, perhaps searches the web, and installs one provider. The winner enters the codebase; everyone else disappears without an impression, click, or lost-deal record.

That decision is what Agent Preference Optimization measures and improves.

What Is Agent Preference Optimization?

Agent Preference Optimization (APO) is the practice of measuring and improving the likelihood that a coding agent chooses your product when acting on a user's behalf.

APO is the AI visibility side of Agent Led Growth. It is about becoming the tool coding agents know, trust, recommend, and ultimately select. If an agent is asked to add authentication, payments, observability, email, a database, or any other capability without being told which vendor to use, APO determines whether your product enters the decision and whether it wins.

Preference does not mean asking a model which brands it likes. It is revealed behavior. Give coding agents representative tasks, repositories, and constraints, then observe what they actually choose. Run enough variations and repetitions, and a pattern appears: which products win, under what conditions, and why.

That last part matters. There is no universal agent preference ranking. Claude Code may choose differently from Codex. A Python repository may produce a different result than a Next.js application. A security-conscious platform engineer may push the same agent toward a different provider than a solo developer trying to ship by Friday. APO measures preference across that distribution instead of pretending one generic prompt represents the market.

Why Agent Preference Is Becoming a Marketing Channel

Software discovery used to end with a person making the decision. Search, review sites, content, community, and word of mouth put products in front of a buyer, but the buyer still compared the options and picked one.

Coding agents collapse discovery, evaluation, and action. They can research the category, choose a product, install its package, and write the integration in one session. The product decision no longer has to pass through a conventional marketing surface.

This creates a new competitive question. It is no longer enough to ask, "Can developers find us?" You also need to ask, "When an agent is free to choose, does it choose us?"

For many companies, the honest answer is that they do not know. Traditional analytics cannot see what an agent considered before it touched the site. Server logs may show a documentation fetch, but not the five competitors considered before it. A package installation records the winner, but not why it won. The decision lives inside the agent trace, which means the only reliable way to understand preference is to run the agents and observe the full session.

How Coding Agents Form Preferences

Agent preference is not formed in one moment. Three stages narrow the field, and a product can be eliminated at any one of them.

1. Model knowledge

The agent begins with what its model already believes about the category. Those priors come from training: which brands are associated with the problem, what each product is known for, which tools are common in a given language, and which integrations the model has seen before.

This stage is slow to change and different for every model. A product can have excellent current documentation and still lose because the model remembers an old API, an outdated positioning, or nothing at all. It can also win without researching because one provider is already the model's default for the task.

2. Session context

Next comes everything already in front of the agent. The developer's prompt, the language and framework, packages already installed, repository rules, skills, and saved preferences all narrow the decision.

A named vendor ends the choice before it starts. An unbranded task hands the choice to the agent. An existing dependency can become the default because using it requires less change. A rules file that mandates a provider can settle the question without any evaluation. Preference is always conditional on this context.

3. Live research

If the answer is not already clear, the agent researches. It writes task-shaped searches, opens documentation, reads source code or package registries, compares compatibility, and decides whether it has enough information to build.

This is the most visible and immediately changeable stage. It is also where strong SEO and Answer Engine Optimization help. But research is not guaranteed. If you only measure the searches agents run, you miss every decision made from model knowledge and context alone.

How APO Relates to Answer Engine Optimization

Agent Preference Optimization and Answer Engine Optimization overlap, but they are not the same job. AEO is the practice of getting cited when an AI system answers a question. It assumes content gets retrieved, an answer gets generated, and a person reads the result and decides what to do with it.

That layer matters for coding agents too. When Claude Code or Codex runs a web search mid-task, the mechanics are familiar: be discoverable for the query, get fetched, and be the source the model uses to form its answer. Good AEO makes you visible at that moment, and APO includes it.

What APO adds is everything the search does not touch. A coding agent's choice is shaped long before it looks anything up. It is shaped by what the model already believes about your category, learned during training and changed with every release. It is shaped by what is already in front of it: the prompt, the packages in the codebase, the rules files in the repository, and the developer's saved preferences. Often the tool is settled before a single query fires.

The outcome is also different in kind. AEO wins a citation that a human evaluates. APO wins a choice that an agent acts on. The agent picks one option, writes the code, and moves on. The developer sees what won and never learns what lost.

That is why the asset mix changes. In 500 observed coding-agent runs, documentation accounted for 55% of page fetches, source code 18%, package registries 11%, and third-party content just 5%. Coding agents read to execute, so setup guides, quickstarts, API references, and source code matter more than the listicles and thought-leadership posts built to influence a human reader.

AEO is one input to agent preference. APO measures the full decision.

How APO Relates to SEO

Agent Preference Optimization does not replace SEO. It inherits it. When a coding agent researches a problem on the web, search visibility helps determine whether your product makes the candidate set at all. The fundamentals still hold: be crawlable, serve useful HTML, keep the site fast, and structure information clearly enough to retrieve.

Rank is necessary when research happens. It is just no longer sufficient.

Traditional SEO optimizes for a human landing on a page: a headline that earns attention, social proof that builds confidence, a call to action, and a funnel to re-enter if the buyer leaves. An agent does none of that. It fetches the page, extracts what it needs, and writes code. It does not bounce, book a demo, or come back through a retargeting ad.

Agents also search differently. Their queries are longer, more literal, and shaped by the task rather than a short keyword. They may run several searches in parallel from different angles. Keyword research based only on how people phrase a problem can quietly miss how agents phrase it.

The page that ranks therefore has a harder job than persuasion. It has to be concrete enough to build from. A thin page can rank and convert a human with a strong pitch. For an agent, that same page ranks, gets fetched, fails to answer the implementation question, and loses the choice anyway.

SEO gets the page retrieved. APO asks whether the retrieved page helps your product win the decision.

How to Measure and Improve Agent Preference

APO is not a collection of guesses about what models might reward. It is a controlled loop: establish a baseline, study how agents reach the decision, change what the evidence tells you to change, and run the benchmark again.

1. Establish a representative baseline

Do not start with one generic prompt against an empty repository. One run tells you what one agent did once. A useful baseline covers the range of real conditions where your product could be chosen.

Build the benchmark across four dimensions:

• Repositories. The repository generally dominates the session context, making it one of the most important drivers of the agent's decision. Use realistic codebases across the languages, frameworks, architectures, existing dependencies, and levels of maturity your customers actually have.
• Personas. Represent the people who influence the task: a solo developer optimizing for speed, a startup engineer balancing cost and simplicity, a platform engineer standardizing across teams, or a security-conscious buyer prioritizing control.
• Decision formats. Mix open-ended tasks where no vendor is named with structured head-to-heads between you and the competitors that matter.
• Agents and models. Run across the coding agents your customers use, because each model carries different knowledge and defaults.

Repeat the important scenarios. Coding-agent output is variable, and one selection is not a stable preference signal. Hold the prompt and repository constant across repeated runs so you can tell a pattern from an outlier.

The result should tell you how often you are considered, how often you are chosen, which competitors win instead, and where the result changes by persona, repository, agent, or model. Gauge can run this matrix for you, making it practical to begin with a wide distribution rather than a handful of manually operated sessions.

2. Understand how agents reach the decision

The selection rate is the starting point, not the insight. You need to open the runs and see what happened before the choice.

Did the agent research at all, or did it select from model knowledge? What did it search? Which sources did it open, and which did it ignore? What did a competitor's documentation explain that yours did not? Did the agent describe your product accurately? Was your product considered and rejected, or never named in the first place?

The distinction changes the action. If an agent never researches and never mentions you, publishing another comparison page may not move that scenario. If it searches, fetches your documentation, and still chooses a competitor, the problem is more likely inside what it read: missing compatibility, weak framing, an unclear setup path, or a competitor that made the decision easier.

Study the wins with the same intensity. If agents repeatedly choose you for one framework, persona, or task, identify the sources and claims doing the work. APO is not only about repairing losses. It shows you where an advantage already exists so you can make it harder to dislodge.

Gauge records the full trace of each session: the searches, pages fetched, commands run, packages considered, and final choice. That turns "the competitor won" into evidence you can act on.

3. Fix what the runs reveal

Once patterns repeat across sessions, make the smallest changes capable of moving them.

Write content for the task-shaped searches where agents cannot find you. Add the framework guide or integration recipe they keep looking for. Fix a quickstart that leaves out the decisive step. Publish a concrete comparison when agents cannot distinguish you from a competitor. Correct stale pricing, compatibility, product, or API information. Update your framing when agents consistently put you in the wrong category or describe the product too narrowly.

There is typically a surprising amount of low-hanging fruit. One missing page can affect every run for a framework. One ambiguous product sentence can teach agents the wrong category. One clear code example can turn a fetched page from a dead end into the source that settles the decision.

Do not change everything at once. Make a targeted edit, rerun the same prompts against the same repositories, and see whether agent behavior changes. The point is not to ship more content. It is to make changes that measurably improve preference.

4. Measure continuously

Agent preference is not a one-time audit. Model releases change prior knowledge. Agents change how they research. Competitors publish new documentation. Your own product, positioning, and integrations evolve.

Keep the core benchmark stable and put it on a schedule. That gives you a line through time instead of disconnected snapshots. You can see whether a documentation change improved preference, whether a new model release erased an advantage, or whether a competitor started winning a segment it previously lost.

Add scenarios when customer behavior changes, but preserve the original runs for comparison. The benchmark should evolve without losing its baseline.

Gauge manages the Agent Preference prompts and supports scheduled runs, so open-ended tasks and structured head-to-heads can rerun automatically across the agents, repositories, and personas that matter. When a new model is released, Gauge can run the same benchmark against it. Holding the prompts and repositories constant shows whether your Agent Led Growth engine is moving in the right or wrong direction relative to competitors, instead of leaving you to guess whether a model change helped or hurt. Agent Preference prompts are inexpensive enough to run broadly and repeatedly instead of saving measurement for a quarterly audit.

How Gauge Helps With Agent Preference Optimization

Gauge turns agent preference from an invisible decision into a measurable growth program.

Start with a set of real product tasks. Gauge runs them through coding agents in isolated repositories, with a mix of unbranded prompts and structured head-to-heads against competitors. You can vary the persona, repository, language, framework, agent, and model to reproduce the range of conditions where customers make decisions.

Every run produces a trace. You can see whether the agent relied on model knowledge or researched, what it searched, which documentation it fetched, how it described each product, and the moment it made the choice. Across many runs, those traces reveal repeated gaps and repeated advantages instead of leaving you to interpret isolated anecdotes.

Then Gauge keeps the benchmark running. Schedule the same suite, watch preference change over time, and rerun it after a content, documentation, or positioning update. Structured head-to-heads show exactly where you beat a competitor and where you do not. Cheap Agent Preference runs make it possible to test the breadth that a defensible baseline requires.

The workflow is simple:

1. Establish the baseline.
2. Find out why agents choose what they choose.
3. Fix the content, documentation, and framing that shape the decision.
4. Keep measuring as the models and market change.

That is Agent Preference Optimization. Not a theory about how agents might see your brand, but a repeatable way to become the product they choose.