Moving this from a feature issue to a discussion issue. You can look at the MR for reference but don't review it with an LLM unless you are just doing that to form an opinion/assessment of whether tokens make sense at all. **MULTIPLE PEOPLE CAN SELF-ASSIGN THIS ISSUE AND PROVIDE THOUGHTS AT THE SAME TIME.** **I'D LIKE TO CLOSE THIS ONE OUT BY EARLY NEXT WEEK.** ## Summary Automators do not use agents and, thus, do not get context items added. One idea (see original summary below) is to use tokens to allow context items to be added to automators in a simple way. Other systems that support tokens could use these as well. ## Solution Assess whether or not it makes to add tokens to pull in context items. There is an MR to explore this idea but take it as a prototype/PoC and not what will be added to CCC right now. This is now a discussion/planning issue for tokens and not an implementation issue. See also: #3563106+s (wider discussion around automators, this issue can focus on tokens) #3586423+s (closed in lieu of this discussion issue) --- # Original summary (kept for background information) ## Summary Add a first-class Drupal **token** (e.g. `[ai_context:...]`) that renders scope-matched, token-budgeted CCC context via the existing `getRenderedContext()` API, so **non-agent** consumers — chiefly **AI Automators** — can include governance context with **no custom PHP**. ## Problem CCC injects context into *agents* automatically via `BuildSystemPromptEvent`. Non-agent consumers never fire that event, so they get no context. The most common such consumer is **AI Automators**: an automator builds its prompt from a plain config string run through the token service (`\Drupal\ai_automators\AiPromptHelper::renderTokenPrompt()`), so it never touches the agent pipeline. Today the only ways to feed CCC context to a non-agent consumer are both **code**: - **Programmatic** — inject `ai_context.request_factory` and call `getRenderedContext()`. - **Event** — subscribe to `post_render` / `text_rendered` (#3586162). A **site builder** configuring an AI Automator (or any prompt field that runs through the token service) has **no no-code way** to include governance context. A Drupal token fits naturally: it drops into the existing prompt string and resolves at build time, with zero site-specific PHP. Concrete use case: site-wide voice / accessibility / privacy governance authored as CCC context items should reach the meta-description, intro-text and image-alt-text automators — the same governance the search-assistant agent already gets — without hand-writing a hook per site. ## Proposed solution Ship a token type (e.g. `ai_context`) whose tokens call `getRenderedContext()` and substitute the compiled context markdown: - `[ai_context:global]` — all global items. - `[ai_context:use_case:working_with_text]`, `[ai_context:use_case:working_with_media]`, … — one dynamic token per `use_case` value (each also includes global items). - Optionally a generic `[ai_context:scope:SCOPE_ID:VALUE]`, or site-defined "named context bundles" mapping a label to a set of scopes (handles scopes with arbitrary values, e.g. tags). Sketch: ```php // hook_tokens() — for each requested [ai_context:use_case:NAME] token: $rendered = \Drupal::service('ai_context.request_factory')->getRenderedContext( scopes: ['use_case' => [$name]], maxTokens: $max_tokens, targetEntity: $target_entity, consumerId: 'ai_context', ); // Prompt fragment, not browser HTML — opt out of token-service escaping. $replacements[$original] = \Drupal\Core\Render\Markup::create($rendered); $bubbleable_metadata->setCacheMaxAge(0); ``` ## Workaround Add a custom module to provide the above tokens. ## Remaining tasks - [ ] Agree on token naming and how to express arbitrary scopes (fixed `use_case` tokens vs. generic `[ai_context:scope:*]` vs. site-defined named bundles). - [ ] Implement `hook_token_info()` + `hook_tokens()` (or an OO `#[Hook]` handler) calling `getRenderedContext()`. - [ ] Return `Markup` to bypass token-service sanitization; set cache max-age 0. - [ ] Resolve target entity + consumer id from token context. - [ ] Tests: token resolves to context, respects `max_tokens`, includes globals, is not HTML-escaped, returns empty cleanly when nothing matches. - [ ] Docs: a short "inject context into automator / token-based prompts" guide, alongside the programmatic and event options. ## User interface changes New tokens appear in the token browser (via `hook_token_info()`). No other UI changes. ## API changes/data model changes Additive only: a new token type. No changes to existing services, events or storage. Complements the existing `getRenderedContext()` API and the `post_select` / `post_render` events rather than replacing them. ## Related issues - #3586162 — Add `post_select` and `post_render` selection events (the event-based integration path this token sits alongside). - #3586393 — [Meta] Add capability-based scope persistence and integration APIs (1.1) — natural umbrella for this. - #3586371 — Document how to use RAG with CCC 1.0 (mentions the `text_rendered` event for custom subscribers). ## Affected functional areas context items, scope plugins, context selection <!-- If this issue description was significantly AI-generated (entire sections, not autocomplete), please note it in a comment below. See https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal --> > [!note] > Check the one that best describes your usage, or leave all unchecked if AI was not significantly used. > > * [x] AI **Assisted Issue** \ > _Mainly written by a human; AI used for partial generation under full human supervision._ > > * [x] AI **Generated Issue** \ > _Mainly generated by AI, reviewed and approved by a human before this issue was created._