It would be nice if we could optionally link resources.
For example, I have an AIP agent, and I should be able to map it to the incoming AIP agent as a way to retain the RID. This is becoming an issue for OSDK apps. External APIs make calls to agents, and when changes need to be pushed, it disrupts all existing agents. When flow is intact, there won’t be any issues but there are scenarios.
We’re fine with overriding changes, but we need to keep the same RID. This mapping should be optional.
Hi @RajKarri
Would you be able to share more details about the setup of the marketplace product you’re referring to installing here?
I have an AIP agent, and I should be able to map it to the incoming AIP agent as a way to retain the RID
e.g. is this including both/one of the agent and OSDK app
We’re fine with overriding changes, but we need to keep the same RID. This mapping should be optional.
For installation of agents in marketplace products, if you upgrade an existing install of the product, this should update the existing agent (so should have the same RID).
For the initial install of a product, this will create a new agent with a new RID compared to the agent you packaged in the product.
This will require a manual step to update the agent RID used by your custom app if using the agent APIs on this first installation.
Assuming the initial installation is the issue here, would a way to dynamically retrieve the agent RID for the installed agent work for you here?
To be clear, this issue can happen to any resource, not just agents.
Here’s the scenario:
we had a marketplace app where we packaged data, ontology objects, code repositories, and AIP agents. We installed that app in a client space (B2B app). Then, we created an OSDK and exposed it for an external React app to consume the agent. Everything worked fine, and we were able to push updates as well.
After a few iterations, we hit the limit, one marketplace app could no longer hold all those resources. We split it into four apps (data, pipelines, ontology objects + repositories, and agents). However, there was no way to map these installations to the existing resources in the previously created space. We had to deploy them as a fresh set of resources, which caused us to lose the previous agent sessions.
I think we should be able to link resources during installation, similar to how we map inputs. Maybe I’m missing something, but this is the scenario we ran into.