Backend: Add GraphQL mutation to update agent

About

Similar to the work in #551282 (closed) we want to add a GraphQL mutation to update an agent.

Proposal

🎗️ The mutation must be marked as experimental.

🎗️ Remember our frontend-backend collaboration guide and communicate schema ideas on this issue with the frontend counterpart of #550465 (closed).

Schema

The update mutation should allow you to set the currently editable properties we allow for an agent (this list is based on on !196462 (merged) which is still in review):

The arguments would be:

Argument name	Type	Required?
id	::Types::GlobalIDType[::Ai::Catalog::Item]	✅
name	GraphQL::Types::String
description	GraphQL::Types::String
system_prompt	GraphQL::Types::String
user_prompt	GraphQL::Types::String

The mutation would have one non-nullable field:

field name	Type
item	::Types::Ai::Catalog::ItemType

(The errors field) is defined for all mutations through BaseMutation).

Example mutation call:

 mutation {
   aiCatalogAgentUpdate(input: {
     id: "gid://gitlab/Ai::Catalog::Item/1"
     name: "Pirate"
     description: "A pirate doing a sum"
     systemPrompt: "You are a pirate!"
     userPrompt: "What is 2 + 2?"
   }) {
     errors
     item {
       id
     }
   }
 }

Service must check item is an Agent

As agents share a model and table with other AI items, the Global ID type for an Agent will not guarantee that we are updating an agent item as opposed to another AI item.

If passed a non-agent to this update mutation, this could lead to us updating a record in a way where it has some agent properties and some non-agent properties, which would be invalid.

The service must return an error response if the AI item is not an agent.

Question: What does an update mean?

As the agent name and description is in Item and the remaining properties are a version in ItemVersion, we need to consider what an update means.

Proposal for this iteration:

1. name and description if given, will always update the singular Item record
2. Other properties which are saved in ItemVersion#definition should update the most recent ItemVersion

Note, this means for this iteration we are ignoring "versioning" and just operate on the 1 version at all times.

A future iteration could decide things like:

• Do we create a new version?
• Should releasing a version have its own mutation?
• If the latest version is published/enabled, do we create a new version that is an unpublish/not yet enabled version (and if there was one already, update that)

Etc. (these questions are why for this iteration the proposal is to essentially ignore versioning).

Authorization

The authorization for the mutation should be the same as in !196462 (merged) which is admin_ai_catalog_item at time of writing.