AI Catalog Group

Vision

The AI Catalog Group is focused on developing AI Catalog, a catalog of Agents, tools, and flows that can be created, curated, and shared across organizations, groups, and projects.

Team members

AI Catalog

How to reach us

Depending on the context here are the most appropriate ways to reach out to the AI Catalog group:

• Slack Channel: #g_ai_catalog
• GitLab group @gitlab-org/ai-powered/ai-catalog/engineering (just engineers)

What we’re working on

TBD

How we work

We’re just getting started and will be defining how we work as we settle in to the new team. Here are some links to get us started:

• Root Epic: For grouping all the work and setting out a roadmap
• Issue board: For all in-flight issues
• Team tasks: For all non-product related team issues
• Async updates
• Team Wiki: For product decisions and useful information

DRIs

When working on a large project, we’ll split it into epics and issues. The Directly Responsible Individual (DRI) for each epic serves as the single point of accountability for that domain. The DRI doesn’t necessarily do all the work, but owns the success of their epic.

DRI responsibilities:

1. Answer questions about epic status, scope, and technical decisions
2. Maintain accurate epic and issue descriptions
3. Monitor and communicate delivery health status
4. Curate the issue list. Include what’s needed and remove what isn’t
5. Keep delivery dates and issue statuses current
6. Coordinate with other DRIs when work spans multiple epics

How we handle requests for help

When a customer is experiencing an issue with the catalog, our support team will raise a request for help. If you wish to raise a request for help please read this readme for instructions on how and when to do so.

To handle requests for help in a timely manner without distracting the whole team, we nominate a goalkeeper for each milestone. The goalkeeper is responsible for ensuring that incoming requests, questions, and issues are triaged and directed to the appropriate people or teams.

Each milestone, we assign a new goalkeeper and open a goalkeeping issue.

You can find more information in the issue template.

Communication

The AI Catalog Team communicates based on the following guidelines:

• Always prefer async communication over sync meetings.
• Don’t shy away from arranging a sync call when async is proving inefficient, however always record it to share with team members.
• By default communicate in the open.
• Prefer public channels (#g_ai_catalog) over private message for work-related Slack messaging.

Frontend-Backend collaboration

We aim to foster high levels of collaboration between frontend and backend engineers to ensure development velocity and code quality.

• Schema-first development: Before implementation begins, frontend and backend engineers collaborate to design a GraphQL API schema based on UI requirements, user experience needs, and performance considerations.
• Parallel development processes: Once the schema is agreed upon, the frontend can proceed using mock data, mock endpoints, or API stubs that match the agreed schema. The backend can focus on implementing the data model, business logic, and actual API schema.
• Maintaining alignment: We value great communication. When requirements or schema need to change, we communicate early through the relevant GitLab issue or in #g_ai_catalog so our frontend or backend counterparts stay informed of all changes and can provide feedback early to avoid late-stage blockers.

AI stage collaboration

The AI Catalog relies on the Workflow Service as a foundational backend service. Most AI Catalog features require new capabilities to be developed within Workflow Service, which means our engineers will need to contribute directly to that codebase in partnership with the other teams within Agent Foundations.

Collaboration Requirements:

• All Workflow Service contributions must be developed in close partnership with the Agent Foundations team
• Our implementations must align with their service architecture and vision
• We commit to supporting Workflow Service’s broader goals and adhering to their technical standards

Collaboration Process:

• Reach out to relevant Agent Foundations contacts (listed below) during the planning phase
• Join their #g_duo-agent-platform channel
• Follow our async communication preferences by default, but schedule sync meetings when needed and ensure key outcomes are documented in GitLab issues

Primary Agent Foundations contacts

Planning cadence

We plan and align our work to GitLab’s product milestones. Milestone planning happens during the week before the start of the next milestone.

~Deliverable and ~Stretch labels

Every issue assigned to a milestone is triaged and labeled either ~Deliverable or ~Stretch. These labels apply to issues only. Epics should never be tagged ~Deliverable or ~Stretch (see Epics in a milestone).

• ~Deliverable: work the team has committed to complete within the milestone. These issues must have a weight.
• ~Stretch: work that has been triaged but is not committed. Stretch issues are picked up once all ~Deliverable issues are complete (see Prioritization).

The ~Deliverable label serves multiple purposes:

• Commitment signal: Communicates to stakeholders and customers that we intend to complete this work in the milestone
• Prioritization: Helps team members identify which issues should be worked on first
• Focus: Clarifies which work is essential vs nice-to-have for the milestone

Who applies it and when

The Engineering Manager applies the ~Deliverable and ~Stretch labels during the planning process before the start of a milestone. This decision is made in collaboration with the Product Manager based on:

• Team capacity for the milestone
• Issue estimates and complexity
• Strategic priorities and customer commitments

Epics in a milestone

Epics are not tagged ~Deliverable or ~Stretch; those labels apply to issues only.

• An epic committed to the current milestone should only contain issues that are also committed to that milestone.
• If an epic is larger than a single milestone, it should be broken down into sub-epics (iteration 1, 2, etc.) so that each iteration fits within a milestone.

Prioritization

Issues with the ~Deliverable label take priority over other work in the milestone. Team members should:

1. First, work on assigned ~Deliverable issues in the current milestone
2. If all ~Deliverable issues are complete or blocked, pick up ~Stretch issues from the milestone
3. Consult with the Engineering Manager if priorities are unclear or if a ~Deliverable issue needs to be deprioritized

During the milestone:

• If a ~Deliverable issue becomes blocked or cannot be completed, communicate this early in #g_ai_catalog or the relevant issue
• The Engineering Manager may adjust ~Deliverable and ~Stretch labels during the milestone based on changing priorities or capacity

Weighting

Issues are weighted using the Fibonacci sequence (0, 1, 2, 3, 5, 8+):

• Weight 1: Simple issues with minimal uncertainty (good for new contributors)
• Weight 2: Straightforward issues requiring multiple code/test updates
• Weight 3: Larger issues with some complexity but manageable scope
• Weight 5: Should typically be broken down
• Weight 8+: Placeholder weights indicating need for breakdown; too large or uncertain for immediate implementation

Our tech stack

• GraphQL backend and frontend. All new schema items must be marked experimental to let us making breaking changes when we need.
• GraphQL subscriptions rather than polling.
• Read the AI Catalog Backend Architecture design document (authored February 2026).

Team meetings

AI Catalog: Group meeting

• Time: Every Tuesday, alternating weekly between 05:30 UTC and 15:00 UTC.
• Purpose: This meeting serves as a general sync meeting to bring up any current issues and blockers.
• Agenda: Google Doc (internal only)
• Recordings: Google Drive (internal only)

View page source - Edit this page - please contribute.