Hi @Gaganmjain_012,
I know this is a late reply, but if you are looking for the cleanest way to make a Genie Space shareable and manageable as infrastructure-as-code, the best pattern today is to keep the Genie Space configuration in GitHub and deploy it through the Genie Spaces API. This means exporting the space definition as serialized_space, version-controlling that JSON in GitHub, and then using the Create Genie Space API and Update Genie Space API from a CI/CD workflow to promote changes across dev, test, and prod workspaces.
One important nuance is that what used to be called Research Agent is now Agent mode, and that feature is still in Public Preview. Agent mode runs on top of the curated Genie Space, so the space itself can absolutely be managed through GitHub and APIs, but Agent mode prompts are still UI-only as of nw rather than something you can orchestrate through the API. So the best current setup is to treat the Genie Space definition as the deployable artefact, and then let users consume both standard Genie and Agent mode from the UI once that space is deployed.
If you are thinking about a more "native IaC" experience, that is the direction many people want, but the most practical route as of today is still API-driven deployment around the serialised space payload.
TLDR.. Yes, you can get very close to an IaC model already, and GitHub plus the Genie management APIs is the most effective way to do it right now, with the only caveat being that Agent mode itself is still Public Preview and not yet exposed through the API.
Hope this helps.
If this answer resolves your question, could you mark it as โAccept as Solutionโ? That helps other users quickly find the correct fix.
Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***