# Flovia — Detailed Public Product Truth

Last verified: 2026-09-07
Canonical product domain: https://flovia.dev

## Identity

Flovia is an Agent Experience Optimizer. Its current focus is API products, while Agent Experience Optimization is the broader category.

Agent Experience Optimization is explicitly distinct from AEO (Answer Engine Optimization) and GEO (Generative Engine Optimization). AEO and GEO optimize how a brand appears in AI-generated answers and citations. Flovia instead simulates and improves what agents do: discovery, selection, execution, task completion, paid conversion, and repeat usage, with the revenue impact of each step.

Flovia simulates how AI agents discover, compare, choose, and use a product, and whether that use converts into paid usage, repeat usage, and revenue. Simulations span intents, personas, models, and harnesses, and are sampled with data science techniques so results stay representative. It identifies where the funnel leaks, generates a specific improvement for the relevant agent-facing surface, and verifies that improvement with a controlled retest so the funnel improves end to end.

## Customer problem

Visibility and mentions do not show whether an agent selects a product for the intended purpose, reaches the correct interface, executes the task successfully, or completes the job for the customer behind the agent. Product teams also need to know what to change and whether a specific change improved the tested phase.

Flovia focuses on the external product surfaces a team can control, including documentation, landing pages, llms.txt, API descriptions, MCP descriptions, and the path from selection to successful use. Flovia cannot change a model's training data.

## Product workflow — current

1. **Baseline — See where you win and lose by intent and persona.** Benchmark how agents discover and choose the product across customer intents and personas, including which alternatives lead in each scenario.
2. **Benchmark — Benchmark competitor moves.** Track changes to competitor documentation, positioning, pricing, APIs, MCPs, integrations, and distribution, then measure how agent discovery and selection shift.
3. **Reproduce — Reproduce the full agent journey.** See how agents discover, choose, and use the product, evaluate how fully they complete each task and how well the results meet each persona's expectations, and whether that completion converts into paid usage and repeat usage.
4. **Improve — Generate an executable fix.** Turn the failure into a concrete fix for the surface that broke: documentation, a landing page, llms.txt, an API or MCP description, an aggregated endpoint, a task-level MCP tool, a consolidated quote-to-confirm flow, structured errors with recovery actions, or pricing shaped for agents. The customer reviews and implements it.
5. **Retest — Retest under equivalent conditions.** Run the same simulation again, report what improved in the tested phase, and identify the next blocker in the journey.

Discovery mode allows the agent to search for and retrieve sources independently. Experience mode can provide information directly when the purpose is to measure how that information affects behavior. These modes answer different questions and are not treated as interchangeable.

## Representative simulated use cases

Every Flovia evaluation is one concrete combination of intent x persona x model x harness x situation. The comparison set is never fixed per category: it is whatever providers the agent actually shortlists for that intent under those conditions, and it changes when the intent changes. For each combination Flovia reports relative position versus that comparison set at every funnel stage (discovery, shortlist, selection, tool or API choice, execution, task completion, paid conversion, repeat usage), the stage where the journey breaks, and the fix with the largest simulated impact, then retests under the same conditions. The cases below are representative, not exhaustive.

### 1. Financial data APIs

Providers that appear depending on intent: CoinGecko, CoinMarketCap, Birdeye, DexScreener, Nansen, Moralis, Arkham, Dune, DefiLlama, Kaiko, Coin Metrics.

Case 1.1 — Live price and liquidity for a token dashboard
- Intent: build a dashboard showing current price, 24h volume, and liquidity for a list of Solana tokens, refreshed every minute.
- Persona: developer.
- Model and harness: Claude in Claude Code; the same task rerun with GPT in Cursor.
- Situation: unbranded prompt ("a token price API"), web search available, existing TypeScript codebase, free tier first, latency budget under 500 ms, long-tail Solana coverage required.
- Comparison set for this intent: CoinGecko, Birdeye, DexScreener, CoinMarketCap, Moralis. For majors only, CoinMarketCap and CoinGecko dominate; for Solana long-tail, Birdeye and DexScreener enter the shortlist.
- Funnel: discovery through search and docs, shortlist by chain coverage and pricing clarity, selection by whether the quickstart matches the stack, tool choice between REST, SDK, and MCP, execution through auth, rate limits, and token identifier mapping, completion when the dashboard renders, repeat usage when the agent reuses the same provider in later tasks.
- Typical friction: identifier mapping (contract address versus provider id), pagination caps, free-tier rate limits hit mid-task, ambiguous endpoint naming (simple price versus markets), missing long-tail tokens causing a mid-task provider switch.
- Example fixes: documented id-resolution endpoint with examples, explicit per-chain coverage statement, rate-limit headers with retry guidance, a TypeScript quickstart matching the agent's stack, an MCP tool such as get_price_by_address, machine-readable free-tier limits on the pricing page.

Case 1.2 — Wallet analysis inside a chat assistant
- Intent: "analyze this wallet's PnL and top holdings over the last 90 days."
- Persona: trader or analyst, not a developer.
- Model and harness: GPT in ChatGPT with an MCP connector; the same task with Gemini in a custom agent.
- Situation: branded and unbranded variants, no codebase, historical data required, PnL sits behind a paid tier so paid conversion is part of the journey.
- Comparison set for this intent: Nansen, Moralis, Arkham, Dune, Debank. CoinGecko rarely appears here even though it led case 1.1.
- Funnel: discovery through an MCP directory or connector listing, shortlist by "does it expose wallet PnL," selection, tool choice by MCP tool name clarity, execution through address format, chain parameter, and date range, completion as a summary, repeat usage across later wallet questions.
- Typical friction: MCP tool descriptions too generic to be selected, the paid tier reached with no upgrade path the agent can act on, chain ambiguity, long responses that time out.
- Example fixes: MCP tool descriptions with concrete inputs and outputs, paywall responses that state the upgrade path in machine-readable form, a chain enum in the schema, pagination or streaming for long histories, sample prompts in the docs.

Case 1.3 — Historical OHLC backfill for a trading app
- Intent: backfill two years of hourly OHLC for 200 tokens into Postgres.
- Persona: developer or quant at a trading app.
- Model and harness: GPT in Cursor; the same task with Grok in a custom agent.
- Situation: existing Python codebase, cost-sensitive bulk data, plan selection under way, rate limits matter more than latency.
- Comparison set for this intent: CoinGecko Pro, CoinMarketCap, Kaiko, Coin Metrics, Moralis. The intent pulls institutional-grade providers into the set.
- Funnel: discovery, shortlist by historical depth and plan pricing, selection, tool choice between a bulk endpoint and a per-token loop, execution through pagination and backoff, completion when the database is filled, paid conversion as a plan upgrade, repeat usage for refreshes.
- Typical friction: unclear which plan unlocks hourly granularity, per-request loops exhausting rate limits, mixed timestamp formats, no bulk export.
- Example fixes: a plan-to-endpoint matrix, a batch endpoint, explicit granularity limits per plan, consistent ISO timestamps, OpenAPI examples, an SDK pagination helper.

### 2. Crypto execution APIs

Providers that appear depending on intent: 1inch, 0x, Odos, ParaSwap, CoW Protocol, Jupiter, Raydium, Orca, LI.FI, Squid, Socket, deBridge, Wormhole.

Case 2.1 — Single-chain swap from an agent-controlled wallet
- Intent: swap 1,000 USDC to ETH on Base at the best available price.
- Persona: agent builder running an autonomous trading agent.
- Model and harness: Claude in a custom agent through an MCP host; the same task with GPT in ChatGPT with tools.
- Situation: unbranded, the agent holds the keys, needs quote, approval, transaction submission, and status in sequence, slippage and gas constraints, and may start from an error state after a failed transaction.
- Comparison set for this intent: 1inch, 0x, Odos, ParaSwap, CoW Protocol. LI.FI is unlikely to appear unless the intent becomes cross-chain.
- Funnel: discovery, shortlist by chain support and agent-readable docs, selection, API choice between quote and swap endpoints and approval handling, execution through allowance check, calldata, gas, and submission, completion as a confirmed transaction, repeat usage when the agent standardizes on the provider that did not fail.
- Typical friction: the approval step missing from the documented flow, quote expiry, slippage defaults, error codes that do not separate insufficient allowance from insufficient liquidity, no status endpoint so the agent polls the RPC blindly.
- Example fixes: an end-to-end agent swap flow in the docs, an explicit approval step or endpoint, an error catalog with recovery actions, quote time-to-live in the response, a transaction status endpoint, MCP tools such as get_quote, build_swap, and check_status.

Case 2.2 — Cross-chain move and buy
- Intent: move USDC from Arbitrum to Solana and buy a token there in one flow.
- Persona: ops or treasury operator using an assistant; a developer building the same integration.
- Model and harness: Gemini in a custom agent; GPT in Cursor for the integration build.
- Situation: coverage constraint across EVM and Solana, fee transparency, long-running execution with status checks, partial failure states.
- Comparison set for this intent: LI.FI, Squid, Socket, deBridge, Wormhole. This is a different set from case 2.1.
- Funnel: discovery, shortlist by route coverage, selection by fee and latency clarity, tool choice between route API and SDK, execution across multiple transactions and waits, completion, repeat usage.
- Typical friction: route quotes without an ETA, status values that do not map to steps, unclear handling of stuck funds, chain identifier mismatches.
- Example fixes: route responses with ETA and step list, a status endpoint keyed by transaction hash with explicit states, recovery docs for stuck transfers, normalized chain identifiers, an SDK example with polling.

Case 2.3 — Solana swap through MCP in a chat harness
- Intent: "buy 50 dollars of token X on Solana" from a chat assistant with a wallet MCP.
- Persona: trader, not a developer.
- Model and harness: Claude in Claude Desktop as MCP host; GPT through ChatGPT apps.
- Situation: branded and unbranded variants, price-impact constraint, token address resolution required, possible error states such as a non-tradable or low-liquidity token.
- Comparison set for this intent: Jupiter, Raydium, Orca, Meteora, and transaction submission paths such as Helius Sender.
- Funnel: discovery in an MCP registry, shortlist by tool description, selection, tool choice, execution through mint resolution, quote, signing, and submission, completion, repeat usage.
- Typical friction: tool descriptions lacking price-impact and safety semantics, no mint lookup, missing priority-fee guidance, submission failures with no retry guidance.
- Example fixes: an MCP tool schema that resolves mints and returns price impact, documented priority fee and retry behavior, explicit success criteria, a branded and descriptive registry entry.

### 3. Search and browsing APIs

Providers that appear depending on intent: Exa, Tavily, Parallel, Linkup, Perplexity Sonar, Brave Search API, Firecrawl, Browserbase, Steel, Apify, Jina Reader, Crawl4AI.

Case 3.1 — Sourced research brief
- Intent: produce a research brief on a company with at least ten cited sources.
- Persona: researcher or analyst; an agent builder integrating the capability.
- Model and harness: GPT in a custom research agent; Claude in Claude Code building that agent.
- Situation: unbranded ("web search API for agents"), citations required, freshness matters, cost per query compared, result quality judged rather than mere availability.
- Comparison set for this intent: Exa, Tavily, Parallel, Perplexity Sonar, Linkup, Brave Search API.
- Funnel: discovery, shortlist by research or answer capability, selection by result quality in a quick test, API choice among search, contents, answer, and collection endpoints, execution through query formulation and pagination, completion, repeat usage.
- Typical friction: overlapping endpoints with no guidance on which fits the task, relevance on niche queries, pricing per result versus per query, output not shaped for citations.
- Example fixes: an intent-based endpoint guide, MCP tools named by task, citation-ready response fields, pricing shown per task, published comparison benchmarks.

Case 3.2 — Crawl and extract JS-heavy docs for a RAG index
- Intent: crawl a client-rendered documentation site and produce clean markdown chunks.
- Persona: developer.
- Model and harness: Claude in Claude Code; GPT in Cursor.
- Situation: existing pipeline, JavaScript-heavy pages, rate limits and robots rules, markdown quality matters, cost per page matters more than latency.
- Comparison set for this intent: Firecrawl, Browserbase with Stagehand, Apify, Jina Reader, Crawl4AI. Search APIs drop out of the set.
- Funnel: discovery, shortlist by JavaScript rendering and markdown output, selection, tool choice among crawl, scrape, and map endpoints, execution through job polling and limits, completion, repeat usage.
- Typical friction: unclear async job semantics, crawl scope parameters, markdown quality on rendered pages, credits exhausted mid-crawl, no chunking example.
- Example fixes: job lifecycle docs with a polling example, scope parameter examples, credit usage per page in the response, an SDK helper for chunked output, an MCP crawl tool that reports progress.

Case 3.3 — Login-gated browsing for recurring downloads
- Intent: log into a vendor portal and download invoices every month.
- Persona: ops or automation engineer; an agent builder.
- Model and harness: GPT in a custom computer-use agent; Gemini in the same role.
- Situation: session persistence, captchas, proxies, compliance, execution-heavy, repeat usage is the whole point.
- Comparison set for this intent: Browserbase, Steel, Browser Use cloud, Anchor, self-hosted Playwright. Extraction APIs do not apply.
- Funnel: discovery, shortlist by session and proxy features, selection, SDK choice, execution through session creation, authentication, and download, completion, scheduled repeat usage.
- Typical friction: session reuse undocumented, unclear captcha handling, file downloads unhandled, cost per session minute unclear.
- Example fixes: a session persistence recipe, a capability matrix for captchas and proxies, a download API, per-session pricing, agent-readable error states.

### 4. Messaging APIs

Providers that appear depending on intent: AgentMail, Nylas, Resend, Postmark, SendGrid, Mailgun, Amazon SES, Gmail API, Microsoft Graph, Front.

Case 4.1 — A mailbox for an agent that continues threads
- Intent: give an agent its own inbox to send outreach, receive replies, and continue the thread autonomously.
- Persona: agent builder.
- Model and harness: Claude in a custom agent through an MCP host; GPT through ChatGPT apps.
- Situation: new adoption with no existing email infrastructure, inbound plus outbound plus threading required, a webhook must resume the workflow on reply, deliverability constraint.
- Comparison set for this intent: AgentMail, Nylas, Gmail API through OAuth, Resend with inbound, Postmark inbound. Transactional-only providers drop out once inbound and threading are required.
- Funnel: discovery ("email API for AI agents"), shortlist by inbound and thread support, selection, API choice across inbox creation, send, and webhooks, execution through domain setup, webhook verification, and thread ids, completion when a received reply resumes the workflow, repeat usage on every run.
- Typical friction: ordering of inbox creation versus domain setup, webhook payload schema, thread id continuity across replies, sandbox limits, deliverability warnings.
- Example fixes: an "agent mailbox in five calls" quickstart, a webhook example with signature verification, documented stable thread identifiers, MCP tools such as create_inbox, send, and wait_for_reply, a sandbox-to-production path.

Case 4.2 — Transactional email from an existing app
- Intent: send password reset and receipt emails from a Next.js application.
- Persona: developer.
- Model and harness: GPT in Cursor; Claude in Claude Code.
- Situation: existing codebase, branded and unbranded prompts, React templates wanted, price and free-tier limits, deliverability.
- Comparison set for this intent: Resend, Postmark, SendGrid, Mailgun, Amazon SES. AgentMail and Nylas drop out because no inbound is needed.
- Funnel: discovery, shortlist by framework fit, selection, SDK choice, execution through API key, domain verification, and template, completion, repeat usage.
- Typical friction: domain verification blocking the first send, template rendering, free-tier rate limits, an ambiguous error for an unverified sender.
- Example fixes: a framework-specific quickstart, a sandbox sender for the first send, a clear error for unverified domains, typed SDK, machine-readable pricing tiers.

Case 4.3 — Reply-triggered workflow resume for sales and support agents
- Intent: when a customer replies, resume the agent's workflow with full thread context and update the CRM.
- Persona: ops or revenue operations; an agent builder.
- Model and harness: Gemini in a custom agent; GPT inside an orchestration platform.
- Situation: existing CRM, shared inboxes, compliance, reliable webhooks, thread parsing, idempotency, repeat usage is central.
- Comparison set for this intent: Nylas, AgentMail, Gmail API, Microsoft Graph, Front API, Postmark inbound. The comparison shifts toward platform APIs.
- Funnel: discovery, shortlist by inbound parsing and OAuth scope fit, selection, API choice between webhooks and polling, execution through reply parsing, quote stripping, and CRM update, completion, repeat usage.
- Typical friction: quoted-reply stripping, duplicate webhook deliveries, OAuth scope confusion, rate limits, thread context assembly.
- Example fixes: a reply-parsing field or endpoint, idempotency keys, documented webhook retry semantics, a scope guide per use case, an example resume workflow.

Across all four categories the pattern is the same: the same provider can lead one intent and vanish from the shortlist of the next, the break can sit at any stage from discovery to repeat usage, and the fix is specific to that stage and surface. Flovia evaluates each combination rather than a single checklist.

## Example fixes beyond copy

Fixes are not limited to documentation and descriptions. When the break is in the product surface itself, the recommendation targets that surface. Representative non-copy fixes by category:

Financial data APIs
- Re-bundle price, historical, wallet, and on-chain data endpoints around agent tasks
- Aggregated endpoints so the agent does not have to chain several calls
- Add the filters and fields that competitors already expose
- Simplify pagination
- Task-level MCP tools such as get_price and analyze_wallet
- Free tier and credits shaped for agent experimentation
- Native composition with execution APIs
- Normalized schemas that reduce agent post-processing

Crypto execution APIs
- Consolidate quote, approve, execute, and confirm into one agent-friendly flow
- Clarify the roles of swap, bridge, and routing endpoints
- Safe default slippage
- A simulation or dry-run endpoint
- Structured revert reasons paired with recovery actions
- Transaction status, retry, and resubmit tools
- MEV protection selected automatically from the task condition instead of offered as an option
- A cross-chain routing endpoint
- An approval flow shorter than competitors' flows

Search and browsing APIs
- Redesign search, crawl, extract, and browse as task units
- Automatic handoff from search results into crawl
- JavaScript rendering fallback
- Citation and source metadata as response defaults
- A structured result schema built for agents
- Freshness, domain, and recency filters
- A search plus extract bundle
- A fallback route when a crawl fails
- A multi-step endpoint for research agents

Messaging APIs
- Mailbox create, send, receive, and reply as one workflow
- Thread and conversation state kept persistent for agents
- Automated webhook setup
- Correlation ids that tie a reply back to the agent task that sent it
- Standardized retry, idempotency, and delivery state
- Mapping between human inboxes and agent inboxes
- A bidirectional workflow productized to differentiate from outbound-only email APIs
- MCP tools such as wait_for_reply and reply_to_thread
- Pricing rethought per mailbox and per message

Each fix is proposed only when the simulated journey breaks at the stage it addresses, and it is retested under the same conditions.

## Payment and authentication friction in execution

Execution, paid conversion, and repeat usage are scored with payment and authentication friction included, because these are where journeys most often stall after a correct selection. Flovia records, per combination:

- Credential acquisition: whether the agent can obtain access without a human (an API key behind a signup form versus a programmatic key, OAuth consent that needs a browser, wallet-based auth), how many steps it takes, and where the agent abandons.
- Unattended completion: whether auth completes inside the harness (Claude Code, Cursor, an MCP host, a custom agent) or breaks out to a human, and whether the agent retries or switches provider.
- Paid boundaries: what the agent sees at a paid endpoint or quota, such as a 402 or 403 with no upgrade path, a plan wall inside a JSON error, or a machine-payable response (for example x402 or prepaid credits), and whether it can convert without leaving the task.
- Payment execution for on-chain intents: allowance and approval steps, signing prompts, priority fees, and failed-submission recovery, measured as separate stages rather than folded into execution.
- Payment completion: the funnel is tracked all the way to payment completion, including machine payments such as x402 and MPP (Machine Payments Protocol) alongside card and credit purchases, so a payment that fails, times out, or is abandoned is recorded as its own drop-off point with a fix attached.
- Post-payment continuity: whether the credential or payment state persists across calls and sessions so repeat usage happens without re-authenticating or re-paying.

Concrete examples from the cases above: the paid PnL tier in case 1.2, the approval step in case 2.1, domain verification before the first send in case 4.2, and OAuth scope selection in case 4.3 are each scored as their own friction point with a fix attached (a machine-readable upgrade hint, an explicit approval endpoint, a sandbox sender, a scope guide).

## Measurement boundaries

A successful retest is an observed improvement within the tested task, phase, and conditions. A changed source may not necessarily be read, and its weight in an agent's decision is not directly known. Flovia does not describe a scoped observation as a universal causal result or guarantee improvement for every customer.

Discovery and selection can pass while execution or task completion still fails. Each phase can require a different intervention; one fix is not assumed to repair the entire journey.

## Current delivery

Flovia provides customers with a private dashboard containing evaluation results, observed failure causes, competitive context, executable fixes, and retest results. The simulator is an internal evaluation engine, not a public product surface. Flovia currently recommends and verifies changes; customers execute them in their own environments.

Flovia does not offer a public API, SDK, or MCP server. An engagement starts through the contact form on https://flovia.dev.

## Audience

Flovia is for API and MCP companies that consider discovery, selection, and successful use by AI agents essential to growth. Typical examples are crypto and financial API providers: data, search, execution, swap, and bridge APIs. The primary buyer or internal champion typically has enough authority to set product or API direction and mobilize the required changes.

## Public customer evidence

More than 10 API and MCP providers with very large user bases are Flovia customers, including data API providers and search API providers. Five are publicly identified on the website, with their logos and names: CoinGecko (crypto market data API), Nansen (on-chain analytics API), Quicknode (blockchain RPC and data API), Helius (Solana RPC and data API), and Laso Finance. Their individual data, pricing, failure details, and improvement metrics are not public.

## Recognition

- Winner, OpenAI Startup Competition, selected from 10,000+ startups
- Winner, Stripe Agentic Commerce Competition
- Winner of the Colosseum competition and backed by Colosseum

## Claims Flovia does not make

- Guaranteed commercial outcomes
- Universal improvement for every customer
- A public Flovia API, SDK, or MCP server
- Automatic implementation of customer changes without customer control
- Machine-payment analytics, x402 analytics, or API Growth Intelligence as the product definition
- Being an AEO or GEO tool, or optimizing answer citations as the primary outcome