Workflow Catalog Group

Vision

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

Team members

Engineering Manager & Engineers

Name	Role
Sam Beckham	Engineering Manager
Florie Guibert	Senior Frontend Engineer
Jaydip pansuriya	Backend Engineer
James Rushford	Frontend Engineer
Justin Ho	Senior Frontend Engineer
Keeyan Nejad	Backend Engineer
Luke Duncalfe	Staff Backend Engineer
Vanessa Otto	Senior Frontend Engineer

How to reach us

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

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

What we’re working on

Right now, we’re working on the first iteration of the Workflow Catalog (the MVP). You can track this work in the MVP epic.

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

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

MoSCoW Prioritization

To effectively prioritize work within our epics, we use the MoSCoW method. Each issue is assigned one of four labels: ~MoSCoW::MustHave, ~MoSCoW::ShouldHave, ~MoSCoW::CouldHave, or ~MoSCoW::WontHave. This framework helps us distinguish between work that must ship versus features that may be deferred, and provides clear guidance on what to work on next. You can see this prioritization on our MoSCoW board

Must Have

Issues labeled Must Have are critical requirements that must be completed before we can consider the feature complete. These represent the minimum viable functionality and should always be the highest priority.

When to pick up: These issues should be tackled first and are never optional.

Should Have

Issues labeled Should Have are important features that we aim to ship with the main feature. However, they can be cut if we need to reduce scope to meet deadlines. These represent valuable functionality that significantly improves the user experience.

When to pick up: Only after all Must Have issues are completed, assigned, or blocked.

Could Have

Issues labeled Could Have are nice-to-have features that would enhance the product but aren’t essential for the current release. These are typically features where we’re unsure how much work they’ll require or how much value they’ll provide. They’re more likely to be included in future iterations, used as onboarding tasks for new team members, or handled by community contributions.

When to pick up: Only when you need something small to fill a gap and can see a quick path to completion.

Won’t Have

Issues labeled Won’t Have represent features or requests that we’ve decided not to implement for this release (or potentially ever). Rather than closing these issues immediately, we tag them for clarity and keep them as a record of conscious decisions. This helps distinguish between “completed” and “deliberately not pursued.”

When to pick up: Never. These issues serve as documentation of our decisions rather than actionable work items.

Communication

The Workflow 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_workflow_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_workflow_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 Workflow Catalog relies on the Workflow Service as a foundational backend service. Most Workflow 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 Duo Agent Platform team.

Collaboration Requirements:

• All Workflow Service contributions must be developed in close partnership with the Duo Agent Platform 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 Duo Agent Platform 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 Duo Agent Platform contacts

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.

Team meetings

Workflow Catalog: Group meeting

• Time: Every Tuesday at 05:30 UTC and 15:00 UTC. It’s held twice in one day to allow APAC, EMEA, and AMER timezones to attend.
• 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.