Understand the relationship/depencies and risks of AI catalog items

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Let's say we're going to have tools, agents, and workflows in the catalog.

• Bob creates a tool T
• Maya creates agent A (which uses tool T)
• Holly creates workflow W (which uses agent A)

Now:

• Should the agent contain/duplicate the tool or simply have a pointer to it?
• If it duplicates it, will a worker keep the tool synced with the "parent"?
• If it's a simple pointer, what happens if Bob or Maya delete their tool/agent?

The same question/problem exists when enabling a catalog item at org/group/project level.

FYI: With CI catalog. I'm fairly sure you can delete a component and it will break any project which references it.

Some discussion points which came up during team pairing:

• If we don't duplicate, we could have split permissions (someone could have access to the project where the definition lives, but not access to projects where it’s used and vice versa). This doesn't really matter, but we need to decide the behaviour.
• If a version is deleted (if we allow that) or the agent/workflow is deleted, or the project/group it lives entirely it would/could break?
• Do we have 3 states: public, private, and published to the catalog? So I can customise but might not want to publish
• The line seems to be blurring between the "enable/disable/customize" and the creation of an item
• I would like to make the line a bit clearer. Perhaps we should not be able to customize items much at org/group/project level (only fill out placeholders that the item author defines in the catalog). If you need any further customization... you create your own catalog item?
• If we go down the clone/dupe route there's going to be A LOT OF DATA

/cc @gitlab-org/ai-powered/workflow-catalog/engineering