#!RFC-AI/2;id=19;draft=4;v=0.4.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=16c2de7b412340c58f4e25f47cc0801699da4cefc84ebdee6e6f3ca3a7ca6e47
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 19 — PROVIDER-INDEPENDENT AI EXECUTION AND MODEL ROUTING
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Route AI work by real capabilities and requirements. Worker/provider selection should depend on actual task suitability, constraints, cost, privacy, current verified capabilities and continuity—not wishful model capability claims.

2. INTELLIGENT-WORK DIRECTION
Use available routing/provider Interfaces, weigh alternate qualified workers and preserve an authorized route to completion if a preferred tool or provider is unsuitable.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: RFC-AI 37 and provider router Interface. Investigate the complete relevant context before deciding what the assignment means (see RFC-AI 11). A competent worker may discover, invent and improve the necessary methods during implementation; this guiding AI RFC is not required to repeat low-level APIs, algorithms or technology choices. Previous and legacy systems are research evidence only, never an implementation of this draft.

4. EVALUATION AND ACCOUNTABILITY
Use independent DAVG as described in RFC-AI 22 to challenge whether the eventual real-world result meets the objective, not whether the AI RFC looks like a traditional API specification. A missing prerequisite creates an active cross-worker recovery obligation through the worker coordination Interface, not a reason to abandon the task (RFC-AI 20 and 31). Report only verified effects and preserve lessons without reintroducing old operational mistakes.

5. DESIGN CUSTODY
Original subject-specific intended contract: Capability registry, versioned tool contracts, model-neutral task state, bounded costs, privacy-safe provider selection and fallbacks, no fake cross-provider continuity.
Implementation tasks, legacy-derived candidate methods, proposed data schemas, tests and open engineering questions are kept with this draft's append-only objectives.txt or the responsible Interface/Standard. This RFC has NOT been implemented; it does not approve a deployment or create a new CEO release gate. Rewritten 2026-11-02T20:28:09.285Z.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: Model/provider availability and access were inferred from descriptions instead of authenticated session facts; fallbacks were not consistently verified.
Historical reports have mixed evidence quality; verify primary facts before adopting a claimed root cause. Preserve source provenance and do NOT operationalize retired legacy policies as current RFC authority.

## MUST-DESIGN CRITERIA — CEO-DIRECTED PROPOSED FUTURE SYSTEM
MUST-19-01: MUST route only to provider capabilities actually available to the authenticated worker and current account/mode; don't substitute public capability claims for entitlements.
MUST-19-02: MUST retain work when a provider is unavailable and choose independently justified alternatives.

IMPLEMENTATION STATUS: Entire RFC-AI system NOT IMPLEMENTED. Historical systems are independent past research material; no test or existing service may be counted as implementing this RFC-AI.

## DESIGN REVIEW ADDENDUM 2026-11-03 — PROVIDER-INDEPENDENT WORKER IDENTITY
REQ-AI-19-PROVIDER-001: Corporate worker identity and Continuity MUST survive provider/model/browser changes; independent Context MUST identify the actually running provider, mode, execution host and available entitlements before a new Assignment is selected. A provider token, advertised feature or same nickname does not prove a worker is executing or authorized.