<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=592038) </details> <!--IssueSummary end--> In order for foundational items to appear across all Organizations, and to ensure they work in Self-Managed and Dedicated, we should move away from referencing global catalog IDs in [ee/lib/ai/foundational_chat_agents_definitions.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/53dd75541e405e306e8313d13b8785814c5fd2c9/ee/lib/ai/foundational_chat_agents_definitions.rb), and we should also see if we can rely on fixtures for foundational flows, so they don't need to be seeded. We should do something similar to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/221730+ and inject the foundational items into the SQL query, perhaps using a temporary view. This way, both foundational agents and flows should appear without any extra seeding on all platforms and organizations, and enabling them in larger groups should become easier, without having to deal with scaling issues due to cascading. By injecting the values into the SQL query, we allow any pagination and future filtering to work without any alternations. I started work on this in `knejad-spike-no-foundational-items-in-database`.