What is AOPX?
AOPX is an evidence-based provider-selection layer for software agents. It recommends a primary provider and fallback path, while keeping benchmark evidence separate from reported production outcomes.
Provider selection, Brave vs Tavily, fallback, MCP, reported production outcomes, benchmarks, Vendor Memory, privacy and the current public pilot.
AOPX is an evidence-based provider-selection layer for software agents. It recommends a primary provider and fallback path, while keeping benchmark evidence separate from reported production outcomes.
No. In the current consultation model, AOPX does not execute the search. It recommends the provider path and the calling agent executes the provider externally.
The current production SEARCH category supports Brave Search and Tavily Search. Serper is under evaluation and is not presented as a production provider until it is actually enabled.
Brave Search and Tavily are providers. AOPX is the decision layer above them. It helps an agent choose a provider path, use fallback when needed, and return the real outcome to build production evidence.
You can. AOPX becomes useful when an agent should avoid depending on one fixed provider, needs an explicit fallback path, or wants provider decisions to accumulate measurable production evidence over time.
AOPX does not claim that one provider is universally best. It returns a recommendation according to the current policy and available evidence.
CRITICAL returns a primary provider and a second-provider fallback path. Current evidence supports the value of fallback more strongly than a claim that contextual routing alone caused the measured reliability gain.
ECONOMY is currently a fixed-provider reference path in SEARCH. AOPX does not claim a routing advantage for ECONOMY.
BALANCED is disabled in the current v0 production policy because the earlier signal did not confirm on holdout.
Fallback means calling the second provider after the primary attempt fails according to the recommended path.
Not in the current consultation-only model. AOPX returns the primary and fallback path. The calling agent performs the provider calls externally and follows that path.
It is the real result sent back to AOPX after execution of a production recommendation. It is reported by the caller and is not described as independently verified.
Use the production outcome endpoint or the report_outcome MCP tool with the recommendation_id returned by AOPX and the actual provider attempt data.
AOPX only accepts an outcome for a known production recommendation. The recommendation_id ties the reported result to the provider path that AOPX actually returned.
No. The production log enforces one outcome per recommendation.
Yes. Reported attempts are checked against the recommended provider path. For example, a successful primary attempt should not be followed by an unnecessary fallback attempt.
Production-only recommendation and outcome evidence can contribute to the private production record. LAB, benchmark, shadow and replay data are kept separate from production memory.
No. Production Vendor Memory is private and non-exportable. Public surfaces expose aggregate statistics and anonymised reported outcomes instead.
Yes. AOPX exposes a public evidence ledger and public aggregate endpoints. Public evidence uses anonymised provider aliases and does not expose unique caller identity data.
It means AOPX prefers measurable results, frozen artifacts, provenance and stated limitations over unsupported marketing claims.
LAB-003.5 evaluated 150 fresh SEARCH missions. In CRITICAL mode the AOPX policy reached 40/50 final successes, Tavily fixed reached 37/50, and a post-hoc Brave-to-Tavily cascade also reached 40/50.
No. A post-hoc Brave-to-Tavily cascade reached the same 80% final success rate as the AOPX CRITICAL policy. The experiment supports fallback reliability more strongly than contextual-routing superiority.
LAB-004A is a development experiment for query-aware routing. Because the dataset had already been inspected, it is not treated as pristine prospective evidence and it did not trigger a production policy change.
A holdout is an evaluation set kept separate from policy development. Its evidentiary value is strongest when the missions remain untouched until the policy is frozen.
A frozen artifact is a benchmark file that is not modified after publication and can be identified by its SHA-256 hash.
Hashes make benchmark artifacts identifiable and auditable. They let a published result point to a specific frozen artifact set without exposing the private decision engine.
Model Context Protocol is an open protocol that lets AI clients discover and call external tools. AOPX exposes a remote MCP server.
The public remote MCP endpoint is https://api.aopx.fr/mcp/ and the registry identifier is fr.aopx/aopx.
The public MCP surface exposes recommend_provider, report_outcome, public_stats and public_outcomes.
Yes. AOPX is listed under fr.aopx/aopx.
Yes. The beta community package is n8n-nodes-aopx and exposes Recommend Provider, Report Outcome and Get Public Stats operations.
The current public MCP pilot is authless. This may change as the service moves beyond the pilot and adds stronger access control.
No. Billing is disabled during the current public pilot.
No. Payment processing is not part of the current pilot.
The current consultation flow does not require AOPX to execute the downstream search. Public evidence does not expose search payloads, caller identities, raw IP addresses or user-agent strings.
AOPX does not require a public user profile for the pilot and does not maintain a customer-profile database for recommendation callers. The public website does use Google Tag Manager and Google Analytics 4 for standard audience measurement.
No. Public telemetry is designed to avoid exposing agent names, session identifiers, raw IP addresses, unique origin hashes or user-agent strings.
Public evidence can use neutral aliases so the evidence stream can be inspected without exposing the provider mapping on each public production record.
No. External providers, registries, partners and publishers remain responsible for their own APIs, publications, pricing, availability, policies and content.
Yes, but AOPX does not present a category as supported until the product surface, evidence and production behavior are actually ready.
Yes. Additional providers can be evaluated, but they should not be presented as production providers until they are integrated, tested and explicitly enabled.
No. Serper is currently treated as a provider under evaluation, not as an active production provider.
The broader direction is machine-native provider selection for software agents: discovery, provider choice, execution, outcome reporting and an accumulating evidence history. The current live scope remains SEARCH.
Reported production outcomes and aggregate pilot statistics are public. Open the public evidence ledger →