The Problem

With my colleague, I maintain a GitLab CI/CD component library used by 800+ projects across the organization. Small team, manual work, difficult to scale.

We have great objectives but only limited time to experiment and implement the most important ones.

What if we could be more secure, faster, more productive, improve the quality of our work, and bring more value to the organization ?

Sounds like a dream, right?

That’s what we’re aiming for with autonomous agents.

The question: How do I & You multiply ourselves ?

The Experiment

Duration: 8-15 hours over 2 weeks (alpha)

Goal: Build an autonomous agent system that can take a JIRA ticket and deliver a ready-to-review merge request — including pipeline fixes along the way.

What if agents could:

  • Read a ticket and plan a CI/CD component from its spec
  • Implement it (code, YAML, configuration)
  • Update documentation and READMEs automatically
  • Push changes to the repository
  • Self-correct when the pipeline fails — classify the error, apply a fix, retry
  • Stop if stuck (guardrails against infinite loops)
  • Notify when the component is ready for review

And you know what? It worked.

The Journey: From Chaos to Structure

I’ll be honest — the first week was tough.

I felt totally overwhelmed. Too many possibilities, too many tools, some failed attempts. I was throwing prompts at agents without a clear plan, hoping something would stick. It didn’t.

Then came the turning point. A colleague showed me how she structured her agent workflows (THANKS A LOT !!) — clear steps, defined responsibilities, predictable outputs. It clicked.

I took that lesson and applied it: instead of treating agents as magic black boxes, I designed a structured, end-to-end workflow with clear commands, skills, and specialized subagents. That changed everything.

The Architecture: Two Commands, Full Automation

The system boils down to two skills:

Phase 1: /plan TICKET_ID

/plan TICKET_ID
  └─→ Spawns a business-analyst agent
      └─→ Reads the JIRA ticket
      └─→ Produces a structured plan file
          → tickets/{TICKET_ID}-plan.md

The agent reads the ticket, analyzes the requirements, and writes a detailed implementation plan. This becomes the blueprint for phase 2.

Phase 2: /implement TICKET_ID

This is where the real magic happens. The implement workflow orchestrates multiple subagents:

/implement TICKET_ID
     │
     ▼
[Steps 0-4] Create branch, apply changes, push
     │
     ▼
[Step 5] Pipeline Fixer (subagent)
     │  ├─ Run pipeline, poll for result
     │  ├─ If failed: classify error, apply fix, retry
     │  ├─ If stuck: STOP (guardrail)
     │  └─ If passed: proceed
     │
     ▼
[Steps 6-8] Update README, tag, version
     │
     ▼
[Step 9] Create Merge Request
     │
     ▼
[Step 9b] Pipeline Fixer (subagent, again)
     │  ├─ Monitor MR pipeline
     │  ├─ Fix + commit to branch if needed
     │  └─ Return final status
     │
     ▼
[Step 10] Completion Report
     ✅ MR URL + status + iterations used

The pipeline-fixer subagent is the backbone. It classifies errors into 6 priority classes — from cheap fixes (rename an input, fix a YAML path) to expensive ones (spawn a specialized operator agent) — and applies the cheapest fix first. If the same error persists after a fix, or if it hits 3 iterations, it stops and escalates to a human. No infinite loops.

What I Learned

Agents aren’t magic — they’re architecture. The difference between a frustrating agent experience and a productive one is structure. Clear inputs, defined responsibilities, guardrails, and predictable outputs.

Subagents are great for context management. With subagents, you can keep the context of the main agent and the subagent separate. This is great for context management and avoid the “context bloat” wasting your tokens and your money.

Start small, iterate fast. The first version was broken. The second was clunky. The third worked. Each version took a few hours, not weeks.

The Result

What used to take me 2-4 hours of manual work per pipeline change now takes minutes. I type two commands, review the merge request, and move on.

My workflow still has a lot of potential for improvement, but this first sprint was instrumental in getting a solid grasp of the concepts and possibilities.

Tools and What’s Next

Current stack: Claude Code for agent orchestration.

For now, I’m sticking with one tool to stay focused on the learning process — switching gears too early would slow me down.

What’s next: Exploring privacy-first, security-hardened, and open-source alternatives. The architecture is tool-agnostic — the workflow patterns transfer regardless of which agent runtime you use.

Do you want to know more ? Just reach out !

Here is my information: LinkedIn or drop me an email at kewinremy@protonmail.com.

Disclaimer: All these ideas are my own and not endorsed by my employer or anyone else.