AI agents know everything about their user. Your product data has to keep up.

How does an AI agent turn what it knows about a user into a recommendation?

It filters. An agent that knows its user is an S corp in California doesn't want every business checking account in the country. It wants the ones that accept S corps and serve California. Each fact the agent holds removes products that can't work, until what's left is a short list it can actually reason about.

This is the part most AEO advice skips. AEO (answer engine optimization) is the practice of getting your products to show up in answers from AI systems. Most of the advice is about restructuring web pages so a language model will cite them. But an agent with real context about its user isn't looking for a page to quote. It's looking for a set of products that pass its filters.

The more an agent knows, the more filters it applies, and the more its recommendation depends on the product data supporting those filters.

What does that look like for a real business?

Hypothetical scenario. An AI CFO agent works for a six-person e-commerce company. It's an S corp, registered in California, with a second warehouse in Nevada. It pays overseas suppliers by international wire every month, keeps a cash cushion it would like to earn something on, wants a separate sub-account to set aside sales tax, and runs its books in accounting software. It rarely handles physical cash.

Here is how that context becomes a query against Bancadia's MCP server:

{
  "entity_types_accepted": ["s_corp"],
  "available_states": ["CA", "NV"],
  "interest_bearing": true,
  "sub_accounts_supported": true,
  "accounting_integration_available": true,
  "monthly_fee_max": 30,
  "target_industries": ["ecommerce"],
  "target_business_profiles": ["established_smb"]
}

The first six arguments are hard filters: an account that fails any of them isn't returned. The last two only reorder the results toward accounts built for e-commerce businesses at this stage. (The full ordering rules are on our methodology page.)

The agent then does the part only it can do. Each result comes back with outgoing_international_wire_fee, apy_default and the account's plan_tiers, so the agent can work out what this specific business would pay on its actual wire volume and earn on its actual balance, and rank the short list by net cost.

Which product attributes does an agent need to filter on?

For business checking, an agent needs to be able to filter or compare on at least the dimensions below. The right-hand column is what Bancadia supports today, stated plainly, including where we aren't there yet. "Filter" means an agent can pass it as a query argument. "Returned" means it comes back in each result for the agent to compare, but isn't a query argument yet.

That's eighteen dimensions for one product category, and that's before plan tiers, promotions and the fine print in a fee schedule. An agent with deep context about its user can use every one of them.

Why can't an AI agent just read the bank's product page?

It can read it. It can't filter it. A product page is a single document that describes one product the way the marketing team wants it described. To answer a multi-constraint question, an agent would have to find every relevant product page, read each one, pull out values that may or may not be stated, and line them up itself. That's slow, expensive and full of gaps (see what AI agents need from product data for what that costs).

Worse, the attributes that decide fit are often not on the page at all. Cash deposit fees, wire fees and waiver conditions usually live in a fee schedule PDF, if they're published anywhere. A page can be perfectly optimized for citation and still leave the agent unable to answer the one question that decides whether its user should open the account.

A "best of" list is worse still. It's already been filtered, by someone else, for a reader they knew nothing about. I come back to that in affiliate content was written for a generic reader.

What should banks and fintechs do about it?

Make your product attributes available as structured, filterable data, somewhere agents actually query. Every product is the best choice for somebody. A bank whose business checking has low cash deposit fees is the best fit for a business that deposits cash every week. But an agent can only find that match if "cash deposit fee" is a value it can filter and compare on, not a line in a PDF.

This is the core of my disagreement with AEO as page optimization. Rewriting your product page so a model is more likely to cite it helps you appear in generic answers. It doesn't help an agent that knows its user and is filtering for a specific fit. For that agent, if your attributes aren't queryable, you're not in the result set, no matter how good your web page is.

Where you're the best fit is exactly where structured data helps you most. The more specific the user, the fewer products pass the filters, and the more likely the agent recommends one of the few that do.

Frequently asked questions