4 weeks ago
160
Every engineering organization has those tasks: complex, repetitive, and time-consuming, but absolutely critical to get right. Onboarding a new microservice into an established GitOps deployment workflow is a perfect example. It involves generating bespoke manifests, updating delivery pipelines, configuring image automation, and making sure every piece references the right namespaces, ports, and hostnames. If you miss a step, the deployment breaks. Do it manually and you can lose hours, sometimes a whole day, to a setup that follows the same pattern every time.
This is an example of the kind of work AI agents were built for. With GitLab Duo Agent Platform, you can create a custom agent that understands your specific application, your specific GitOps workflow, and your specific conventions, and then performs that complex onboarding for you. Better still, the agent itself, along with all the artifacts it generates, is versioned, managed, and governed by GitLab, so you get the speed of automation without giving up enterprise control.
In this tutorial, you'll learn how to build one of these custom agents from scratch, from generating the system prompt to seeing the new microservice running on a Kubernetes cluster. You can follow along with the content below.
Use case: Onboarding a microservice for TanukiBank
To make this concrete, we'll work with a fictitious bank called TanukiBank. The bank's web application offers checking accounts, savings accounts, home loans, mortgage and auto loan calculators, and a Pay & Transfer page. The Pay & Transfer page has a Quick Transfer panel, with a goal to allow users to transfer money from one account to another. This panel currently is not implemented so nothing happens when clicking the Transfer button because its underlying microservice doesn't exist yet. Our job is to build that microservice and onboard it into TanukiBank's existing GitOps workflow using a custom agent.
The application and the GitOps process
TanukiBank's code lives in a GitLab group with a services subgroup that holds each microservice (home mortgage calculator, auto loan calculator, and so on), plus two top-level projects, Tanuki Bank - Delivery and Flux Config, that handle the deployment to a Kubernetes cluster.
The GitOps workflow itself works like this: Every microservice has a pipeline that builds a container image and pushes it to its built-in container registry. The Flux Image Automation Controller, running on the Kubernetes cluster, watches those registries for changes and, when it detects one, updates the corresponding manifest in the Tanuki Bank - Delivery project. That triggers a delivery pipeline which builds and signs a new container image and stores it in the delivery project's registry. Finally, the Flux CD Controller keeps the running pods in the Kubernetes cluster in sync with the delivery project’s container registry across each environment. All Flux manifests live in the Flux Config project.
This is a clean workflow, but onboarding any new microservice means touching all of those moving parts in exactly the right way. So, creating a custom agent to do the onboarding for us would make our lives much easier!
Generating the system prompt
A custom agent is only as good as its system prompt, so rather than writing one from scratch, we let GitLab Duo do the heavy lifting. From the tanukibank group, we open GitLab Agentic Chat and ask it to study the group, its subgroups, and their contents, and then draft a system prompt for an agent that can onboard new microservices. We are basically asking Duo to thoroughly understand and learn about the well-established GitOps workflow of this application. That way, Duo can create a system prompt that captures enough detail to automate the onboarding of a new microservice into this application’s GitOps workflow.
GitLab Duo ingests the files, reads the manifests and config files, examines the Dockerfiles, maps out dependencies, and then produces a thorough system prompt complete with reporting instructions, rules to follow, and recommended tools to enable. We save this output for the next step.
Something important to note is that the system prompt generated by GitLab Duo is specific to this application’s GitOps workflow at this moment. If, in the future, the GitOps workflow for this application were to change, then this system prompt would need to be re-generated by rerunning this step.
Creating the custom agent
Next, we create a new blank project called application-agents. This project will manage our custom agents, including who can administer them and where they can run. Follow these steps:
- From AI > Agents, we select the Managed tab.
- Click on the New agent button to create a new agent named TanukiBank Microservice Onboarder, give it a short description, and make it public.
- We select the tools recommended by GitLab Duo.
- Paste in the generated system prompt.
- Create the agent.
Once the agent is created, we enable the agent in both projects that drive the GitOps workflow: Tanuki Bank - Delivery and Flux Config. Opening the Agentic Chat panel in each and confirming that TanukiBank Microservice Onboarder appears in the agent dropdown verifies the setup.
Creating a new microservice with the Developer flow
Before testing the agent, we need an actual microservice to onboard. So, let’s create a new one. We head to the services group, create a new project called intra-account-transfers, and put the GitLab Duo Agent Platform's Developer foundational flow to work.
We open a new issue in the project and in its description, we list a series of specifications for the microservice. We then click the Generate MR with Duo button, which launches the Developer flow. The agent reads the spec, implements the microservice, creates a branch and a merge request, and links the MR back to the issue. After verifying the implementation works locally with a quick curl command, we merge the MR. The pipeline runs and pushes the new container images to the project's registry.
At this point, the new microservice exists, but the broader GitOps workflow has no idea about it. The manifests/dev directory in the Tanuki Bank - Delivery project contains nothing for intra-account-transfers, the delivery pipeline doesn't reference it, and the image-update-automation.yaml file in the Flux Config project has no entries for the new microservice.
Using the custom agent
After enabling our TanukiBank Microservice Onboarder in the newly created intra-account-transfers project, we go to Tanuki Bank - Delivery, open the Agentic Chat panel, select our custom agent from the agent dropdown, and ask it to onboard the new service, providing the service name and hostname.
The agent gets to work. It locates and reads the new microservice's Dockerfile to determine its port, generates the appropriate manifests, and updates the relevant pipelines. Along the way, it asks for approval before creating commits and merge requests, which we grant.
Then the agent opens two MRs, one in Tanuki Bank - Delivery and one in Flux Config, and finishes with a summary of everything it did, including links to the MRs, service details, files created and modified, and recommended next steps.
The results
We review the changes in both MRs, merge the Flux Config MR first to update the Flux components, then merge the Tanuki Bank - Delivery MR. To verify the deployment, we create a new environment in GitLab named intra-account-transfers-dev connected to the Kubernetes cluster, select the appropriate namespace and Flux resource, and save.
The environment view shows the freshly started pods, and a kubectl listing in a terminal confirms three new pods are running. A final curl against the public hostname itransfers2.ocpgitlab.com returns the correct response. The microservice is live, and the onboarding that could potentially consume hours of careful manual work took minutes.
Benefits
Building a custom agent on top of the GitLab Duo Agent Platform delivers value on multiple fronts. It compresses complex, multi-project setup work into minutes, freeing engineers to focus on higher-value problems. It captures organizational knowledge and context, your specific GitOps conventions, naming patterns, and pipeline structures, into a reusable asset that any authorized team member can invoke.
Because the agent is defined in a managed project, its access, visibility, and scope are controlled the same way you control any other GitLab resource, which keeps platform teams comfortable. And every artifact the agent creates, every manifest, every commit, every MR, lives in GitLab, fully versioned and auditable. You get the speed of AI automation without sacrificing the governance and traceability your enterprise requires.
Build a custom agent today
Onboarding new services into a mature GitOps workflow is a good example of the kind of task that's complex enough to demand careful attention but repetitive enough to be a drain on engineering time. A custom agent built on the GitLab Duo Agent Platform changes that calculus: It understands your application and organizational context, follows your conventions, and produces consistent, reviewable changes, all while remaining versioned, governed, and secure inside GitLab.
You can try GitLab Duo Agent Platform as part of a free trial of GitLab Ultimate today! Or, if you already have access to GitLab Duo Agent Platform, learn more about it with our Get Started guide.