Initiative Brief: Consolidate Platform AI Agent Configuration Ownership
COMPLETEDIntent— the specification (7,270 chars); the plan below decomposes it into work items. Click to expand.
# Initiative Brief: Consolidate Platform AI Agent Configuration Ownership ## Desired outcome Establish a clear ownership boundary for platform AI configuration such that: * OutShine is the canonical backend owner of AI/runtime configuration used by platform and Workspace capabilities. * Console remains the administrative management surface for this configuration. * Workspace and OutShine runtimes do not depend on Console availability to obtain configuration. * Existing agent configurations are inventoried and classified before migration. * Obsolete configuration is deprecated or removed rather than automatically carried forward. * The transition preserves currently operating AI features without a flag day or unnecessary new infrastructure. ## Rejected / deferred alternatives - This initiative does not: - redesign every AI prompt; - select new models for every existing role; - rebuild legacy OutSold features merely because they have agent configuration; - migrate deferred features into their eventual Workspace modules; - create a standalone AI platform service; - redesign the Console Agent Configuration UX beyond changes required to support the new backend; - broadly reorganize other Console BFF responsibilities unrelated to AI configuration. ## Repository scope - Inventory the Current Registry — Produce an authoritative inventory of: - every `agent_configs` key seeded or migrated by Console; - every code path that reads each key; - the repository and subsystem executing that role; - whether the consumer is currently active; - whether the corresponding feature is expected to survive in the current platform architecture; - any environment-variable fallback or duplicate hardcoded configuration; - any metadata semantics specific to individual roles. Include both direct Console consumers and OutShine consumers using the internal configuration bridge. Known examples requiring classification include, but are not limited to: - conversation/runtime assistant configuration; - historical narrative generation; - ownership investigation; - property media caption generation; - document FAQ candidate generation; - video/script/narration roles; - other content, document, listing, artifact, album-analysis, Idea Studio, identity, and lead-related AI roles. Do not assume that presence in the existing table implies that a configuration should survive. - Classify Every Agent Role — Assign each existing role one explicit disposition: A. Platform / OutShine-Owned — Migrate — Use for AI roles executed by: - OutShine services; - the Workspace conversational runtime; - reusable platform capabilities; - domain/workflow services hosted by OutShine. These configurations move to OutShine and become canonical there. The workspace Composer `conversation_runtime` configuration must be included in this category. B. Console-Owned — Retain Locally — Use only when the AI capability itself genuinely belongs to Console rather than when Console merely provides its UI. Any item placed in this category must have an identified live Console-native consumer and architectural justification. Do not retain configuration locally simply because its administration currently lives under `/admin/agents`. C. Legacy / Deferred — Deprecate — Use for roles whose corresponding feature: - is no longer used; - is experimental or abandoned; - belongs to an older OutSold interaction model; - is expected to be replaced by a dedicated Workspace/module implementation; - has no identifiable live consumer. Do not migrate these records into the new canonical registry unless and until the corresponding capability is retained or rebuilt. Record enough information to recover historical intent if necessary before removing the configuration. - Add an OutShine AI Configuration Registry — Implement canonical AI-role configuration persistence in OutShine. The registry should support at least the currently required common fields: - stable key; - human-readable label; - provider; - model; - token/output limits; - temperature or equivalent generation settings; - system/base prompt where appropriate; - enabled/disabled state; - extensible metadata; - timestamps. Preserve stable agent keys wherever doing so avoids unnecessary consumer churn. Avoid encoding feature-specific semantics into the common registry unless they are genuinely common platform concerns. - Add OutShine Management APIs — Provide authenticated APIs for: - listing configurations; - retrieving a configuration by stable key; - creating/upserting configurations; - updating configurations; - enabling/disabling configurations; - validation of supported provider/model combinations as appropriate. Separate administrative mutation authorization from runtime read access. Internal OutShine services should access the underlying service/repository directly rather than making HTTP requests back into their own API. - Move Composer Conversation Runtime Configuration First — Treat the Workspace Composer conversation runtime as the first migration target. Remove the architecture in which OutShine resolves `conversation_runtime` by calling: `Console /api/internal/agent-configs/:key` Replace it with native OutShine configuration resolution. Preserve existing provider selection, caching, failure classification, feature-flag behavior, observability, and development/test safeguards unless there is a specific reason to change them. After migration, Composer conversation execution must not require `OUTSOLD_INTERNAL_BASE_URL` or Console availability. - Migrate Other Live OutShine Consumers — Replace the generic Console `agent_configs` bridge used by OutShine services with the new native registry. Inventory and migrate consumers systematically rather than changing only the Composer path and leaving the same inversion elsewhere. Where multiple services currently use the same Console-fetch helper, establish one canonical OutShine-side configuration service rather than creating feature-specific replacements. - Preserve Console as the Administrative UI — Retain the Agent Configuration management experience in Xyence Console. Refactor the Console BFF endpoints used by the admin UI so that they manage the OutShine registry rather than Console's local `agent_configs` table. From an operator's perspective, `/admin/agents` should continue to provide centralized management even though persistence has moved behind the platform boundary. The UI should clearly identify deprecated roles if they are temporarily shown during migration. - Transitional Compatibility — Avoid a flag-day migration. Provide a bounded compatibility period in which necessary legacy callers can continue functioning while individual consumers move. Preferred transition: - Add and seed/migrate the OutShine registry. - Move `conversation_runtime`. - Move remaining live OutShine consumers. - Change Console's Agent Configuration administration to proxy OutShine. - Verify no active runtime reads Console's local registry. - Remove the OutShine → Console agent-configuration bridge. - Remove obsolete Console persistence/API code once no consumers remain. Do not create indefinite dual-write behavior. If temporary synchronization is required, define a clear removal condition and make one side explicitly authoritative.
Repository scope
targets the work spans — independent of where the brief was authoredPrimary repository: Inventory the Current Registry — Produce an authoritative inventory of:
- Inventory the Current Registry — Produce an authoritative inventory of:expected · primary
- every `agent_configs` key seeded or migrated by Console;expected
- every code path that reads each key;expected
- the repository and subsystem executing that role;expected
- whether the consumer is currently active;expected
- whether the corresponding feature is expected to survive in the current platform architecture;expected
- any environment-variable fallback or duplicate hardcoded configuration;expected
- any metadata semantics specific to individual roles. Include both direct Console consumers and OutShine consumers using the internal configuration bridge. Known examples requiring classification include, but are not limited to:expected
- runtime assistant configuration;expected
- historical narrative generation;expected
- ownership investigation;expected
- property media caption generation;expected
- document FAQ candidate generation;expected
- scriptexpected
- other content, document, listing, artifact, album-analysis, Idea Studio, identity, and lead-related AI roles. Do not assume that presence in the existing table implies that a configuration should survive.expected
- OutShine-Owned — Migrate — Use for AI roles executed by:expected
- OutShine services;expected
- the Workspace conversational runtime;expected
- reusable platform capabilities;expected
- workflow services hosted by OutShine. These configurations move to OutShine and become canonical there. The workspace Composer `conversation_runtime` configuration must be included in this category. B. Console-Owned — Retain Locally — Use only when the AI capability itself genuinely belongs to Console rather than when Console merely provides its UI. Any item placed in this category must have an identified live Console-native consumer and architectural justification. Do not retain configuration locally simply because its administration currently lives under `expected
- is no longer used;expected
- is experimental or abandoned;expected
- belongs to an older OutSold interaction model;expected
- module implementation;expected
- has no identifiable live consumer. Do not migrate these records into the new canonical registry unless and until the corresponding capability is retained or rebuilt. Record enough information to recover historical intent if necessary before removing the configuration.expected
- Add an OutShine AI Configuration Registry — Implement canonical AI-role configuration persistence in OutShine. The registry should support at least the currently required common fields:expected
- stable key;expected
- human-readable label;expected
- provider;expected
- model;expected
- output limits;expected
- temperature or equivalent generation settings;expected
- base prompt where appropriate;expected
- disabled state;expected
- extensible metadata;expected
- timestamps. Preserve stable agent keys wherever doing so avoids unnecessary consumer churn. Avoid encoding feature-specific semantics into the common registry unless they are genuinely common platform concerns.expected
- Add OutShine Management APIs — Provide authenticated APIs for:expected
- listing configurations;expected
- retrieving a configuration by stable key;expected
- upserting configurations;expected
- updating configurations;expected
- disabling configurations;expected
- model combinations as appropriate. Separate administrative mutation authorization from runtime read access. Internal OutShine services should access the underlying serviceexpected
- apiexpected
- Migrate Other Live OutShine Consumers — Replace the generic Console `agent_configs` bridge used by OutShine services with the new native registry. Inventory and migrate consumers systematically rather than changing only the Composer path and leaving the same inversion elsewhere. Where multiple services currently use the same Console-fetch helper, establish one canonical OutShine-side configuration service rather than creating feature-specific replacements.expected
- adminexpected
- Transitional Compatibility — Avoid a flag-day migration. Provide a bounded compatibility period in which necessary legacy callers can continue functioning while individual consumers move. Preferred transition:expected
- migrate the OutShine registry.expected
- Move `conversation_runtime`.expected
- Move remaining live OutShine consumers.expected
- Change Console's Agent Configuration administration to proxy OutShine.expected
- Verify no active runtime reads Console's local registry.expected
- Remove the OutShine → Console agent-configuration bridge.expected
- API code once no consumers remain. Do not create indefinite dual-write behavior. If temporary synchronization is required, define a clear removal condition and make one side explicitly authoritative.expected
- outshinediscovered
- consolediscovered
brief revision 1 — all 1 unmet criterion cleared
assessed with 77% confidenceMost of the ownership boundary is in place: OutShine now has a native, canonical AI configuration registry with DB model, migration, repository and internal service (#473), authenticated Management APIs with admin-only mutations vs authenticated runtime reads (#474), a one-time A/B/C–driven seeding tool that only imports category‑A and proves idempotency/no dual‑write (#475), and the Console BFF can remain the admin surface by proxying /admin/agents to OutShine behind a flag (Xyence/console#177). The first runtime (Workspace Composer conversation runtime) was cut over to resolve from the native registry by default, with an emergency rollback kill switch and tests proving no dependency on Console or its env on the native path (#476). Inventory/classification artifacts exist (#472), and obsolete configs are not automatically carried forward (C omitted from seeding; ‘deprecated’ surfaced in the BFF). What remains against the brief is the end‑to‑end outcome that “Workspace and OutShine runtimes do not depend on Console availability to obtain configuration.” Only the Composer runtime has been migrated; other OutShine/Workspace consumers (e.g., narrator, captions, FAQ, agent_text) still use the legacy Console bridge per the docs. Until those are migrated off the bridge, this user‑visible/system‑wide criterion is only partially satisfied.
Waived
- Workspace/OutShine runtimes do not depend on Console availability to obtain configuration — all other consumers — Deliberately deferred, not missed: wave 1 proved the migration path on the conversation runtime (outshine#476); migrating the remaining consumers is filed as roadmap item RM-0009, with RM-0010/0011 covering Console retirement and bridge removal behind their verification checkpoints. Shipping the registry with one proven consumer and a durable plan for the rest was the wave-1 scope. (human:joshua)
Plan waves — 1 approved wave
planning closed- Wave 1foundation-firstAPPROVED6 work items
Establish OutShine as the canonical backend owner of AI agent configuration, keep Console as the administrative UI, remove runtime dependency on Console, inventory and classify all existing agent roles, migrate Composer conversation runtime first, and provide a bounded transition with compatibility until remaining live consumers are moved.
Deferred scope
- Migrate remaining live OutShine consumers from Console bridge to native registry — Deferred from wave 1 of the AI-config consolidation: the Composer conversation runtime was cut over to the native registry (outshine#476) as the proving migration, but the other live consumers (lead replies, media captions, identity plaque, idea studio, album analysis, document observations, town-square config) still resolve through the Console bridge. (unblocks: Conversation runtime migration validated in staging; registry and management APIs stable in production.) · filed → RM-0009
- Switch Console Agent Configuration administration to rely solely on OutShine and remove local persistence/API code — Deferred from wave 1: Console's /admin/agents BFF was refactored to manage OutShine's registry (console#177), but Console still carries its own agent_configs persistence and internal API. Removing them is safe only after every live consumer has migrated — premature removal risks dual-write and breakage. (unblocks: No active runtime reads Console's local registry; BFF proxy flag enabled in production; migration audit complete.) · filed → RM-0010
- Remove OutShine → Console agent-config bridge and any environment variables like OUTSOLD_INTERNAL_BASE_URL from remaining paths — Deferred from wave 1: the bridge (OUTSOLD_INTERNAL_BASE_URL + service token) must keep working until telemetry proves nothing calls it. Removing it while a consumer still resolves through it would break that consumer at call time. (unblocks: Production telemetry shows zero calls to the Console bridge over a defined window; decision recorded in docs.) · filed → RM-0011
- Archive/remove deprecated (category C) configurations and record minimal historical context — Deferred from wave 1: the inventory (outshine#472) classified some configurations as deprecated, but removing them needs a final product/architecture confirmation of the deprecation list and any compliance retention considerations — a judgment call, not an engineering task. (unblocks: Approved deprecation list; Console UI indicates deprecated where necessary; retention policy acknowledged.) · filed → RM-0012
Continuation checkpoint: Eligible for next wave when: (1) Inventory and classification doc merged and acknowledged by platform/Console leads; (2) OutShine registry persistence and management APIs shipped and stable; (3) One-time seeding executed in staging with validation; (4) Composer conversation runtime using native registry in staging with no Console dependency; (5) Console BFF proxy feature flag validated in staging.
Work items
| # | Title | Repository | State | Issue | PR / CI | Review | |
|---|---|---|---|---|---|---|---|
| 0 | Author inventory and classification of all existing agent configurations | outshine | COMPLETED | #472 | #477merged · CI passed | c1: approve | |
| 1 ⛓ | Add AI Configuration Registry persistence layer and internal service | outshine | COMPLETED | #473 | #478merged · CI passed | c1: approve | |
| 2 ⛓ | Expose authenticated Management APIs for AI Configuration Registry | outshine | COMPLETED | #474 | #479merged · CI passed | c1: approve | |
| 3 ⛓ | One-time seeding tool to migrate category-A agent configs from Console into OutShine | outshine | COMPLETED | #475 | #480merged · CI passed | c1: approve | |
| 4 ⛓ | Migrate Composer conversation runtime to native OutShine registry (remove Console dependency) | outshine | COMPLETED | #476 | #485merged · CI passed | c1: approve | |
| 5 ⛓ | Refactor Console BFF for /admin/agents to manage OutShine registry (proxy mode) | console | COMPLETED | #177 | #178merged · CI passed | c1: approve |
Release candidate
ELIGIBLEAll work complete — merged, reviewed, and unblocked. Release and deployment remain manual.
d0b6f5f428 · review approveb7bc854a4c · review approve8ae7ac1bb6 · review approve2570a6b325 · review approveccc3f2b4f8 · review approve6ea284a3cb · review approveRelease planning
Releases are cut in the Release planning section. Associating this initiative requires an admin role.
Associating an initiative to a release only records the link — it never changes the initiative’s own state or work. Releases are optional.
Questions
agent:openai · 8/16/2026, 11:05:38 AM
Every work item is complete, but the brief assessment could not verify any of its 1 criteria — it was not shown the full content of the delivered work. Is this initiative done?
Most of the ownership boundary is in place: OutShine now has a native, canonical AI configuration registry with DB model, migration, repository and internal service (#473), authenticated Management APIs with admin-only mutations vs authenticated runtime reads (#474), a one-time A/B/C–driven seeding tool that only imports category‑A and proves idempotency/no dual‑write (#475), and the Console BFF can remain the admin surface by proxying /admin/agents to OutShine behind a flag (Xyence/console#177). The first runtime (Workspace Composer conversation runtime) was cut over to resolve from the native registry by default, with an emergency rollback kill switch and tests proving no dependency on Console or its env on the native path (#476). Inventory/classification artifacts exist (#472), and obsolete configs are not automatically carried forward (C omitted from seeding; ‘deprecated’ surfaced in the BFF). What remains against the brief is the end‑to‑end outcome that “Workspace and OutShine runtimes do not depend on Console availability to obtain configuration.” Only the Composer runtime has been migrated; other OutShine/Workspace consumers (e.g., narrator, captions, FAQ, agent_text) still use the legacy Console bridge per the docs. Until those are migrated off the bridge, this user‑visible/system‑wide criterion is only partially satisfied. Every criterion came back "cannot confirm" rather than "not done", and the delivered work exceeded the evidence budget, so the diff content of 1 completed item was withheld from the assessment (their changed-file lists were shown, but not their content) — so this is an unverified verdict, not an adverse one. Check the delivered work yourself before waiving anything: waiving records each criterion as a gap you accepted, and if the work is in fact complete that is a false record. Criteria the assessment could not confirm: - Workspace/OutShine runtimes do not depend on Console availability to obtain configuration — all other consumers — #476 docs explicitly defer migrating other consumers (narrator, captions, FAQ, agent_text); shared legacy bridge remains for them. End‑to‑end ‘no Console dependency’ does not hold system‑wide yet.
Answer: Yes. Wave-1 scope is delivered: native registry, management APIs, seeding, the conversation-runtime cutover, and the Console BFF refactor. The one unmet criterion (remaining consumers still on the Console bridge) is deliberately deferred work, waived with a pointer to roadmap item RM-0009; RM-0010, RM-0011 and RM-0012 carry the rest of the retirement program behind their verification checkpoints.
Timeline
No events yet.