Fable 5 notes Good news: everything needed already exists in the public API — `AiContextRequest::getTask()` gives you a free-text retrieval query, and the `text_rendered` event exposes remaining token budget and lets you rewrite the output. Here's how I'd wire RAG up with ai_context **today**, no changes to the module. ## Pattern A — agentic RAG via tools (no custom code) Use ai_context for what it's best at: injecting *instructions about retrieval* rather than retrieved content. 1. Index your corpus with the AI module's `ai_search` (Search API + a vector backend — pgvector, Milvus, etc.). 2. Give your agent a search tool (the AI module ecosystem exposes Search API / RAG tools as function calls). 3. Create curated context items scoped to the relevant use cases/entity types that tell the agent *when and how* to retrieve: "When answering product questions, search the `product_docs` index first. Never answer pricing questions from memory. Cite the source node." ai_context governs the retrieval *policy* (scoped, moderated, revisioned — an editor can change retrieval behavior without touching code), and the agent does retrieval itself via tool calls. This is the most idiomatic fit for how the module works right now, and it's pure site-building. ## Pattern B — deterministic injection via the event (one small subscriber) If you want retrieved content *guaranteed* in the prompt (not left to the agent's tool-calling judgment), subscribe to the public `ai_context.selection.text_rendered` event and fill leftover token budget with retrieval results: ```php public function onTextRendered(AiContextSelectionTextRenderedEvent $event): void { $remaining = $event->getMaxTokens() - $event->getTokensUsed(); if ($remaining < 500) { return; } // The retrieval query: the agent's task, optionally enriched with the // current entity from the request. $query = $event->getRequest()->getTask(); // Query your ai_search / Search API vector index (respects access // processors). Trim chunks to fit ~$remaining tokens (chars/4 is fine). $chunks = $this->ragIndex->search($query, limit: 3); if ($chunks) { $event->setRenderedText( $event->getRenderedText() . "\n\n## Retrieved reference material\n" . $this->formatWithSources($chunks) ); // Retrieval results vary per task; don't let them be cached as if static. $event->addCacheableDependency((new CacheableMetadata())->setCacheMaxAge(0)); } } ``` What this composition buys you over a naive RAG bolt-on: curated items always win the budget first (they're selected and rendered before your subscriber runs), retrieval only fills what's left, and everything arrives through ai_context's single injection point per agent. The event is documented public API, so this survives module updates. ## Pattern C — authoring-time RAG (semi-curated) Instead of retrieval at prompt time, use automation (AI Automators, cron) to periodically summarize source documents *into* context items — scoped, moderated, and reviewed like any other item. You trade freshness for full editorial governance and cacheability. Good for slowly changing corpora like policy docs. ## Caveats for A and B - **Access control:** make sure the Search API index enforces access processing, since retrieved chunks bypass the agent's own entity access at render time (Pattern B especially). - **Latency/caching:** Pattern B adds an embedding + vector query to every selection and needs `max-age 0` on the retrieved portion; Pattern A pushes that cost into agent tool calls instead. - **Token estimation:** the module's token estimator service is internal, so estimate in your subscriber (chars/4) rather than injecting it. If I were advising a site today: start with Pattern A — zero code, and the "context items as retrieval policy" framing is genuinely powerful. Reach for Pattern B when you need compliance-grade certainty that reference material is present in the prompt. And either one doubles as the real-world validation for whether the Level 2 "retrieval-backed context item" idea from earlier deserves to exist post-1.0.