Welcome to the NZRT Wiki Podcast. Today we’re looking at Agentic CI/CD Pipelines.

So what makes these pipelines “agentic”? The short answer is that Claude-powered agents aren’t just passive observers in the pipeline — they actively analyse, verify, make decisions, and execute actions. They’re not scripts that blindly run commands. They think about what’s happening and respond accordingly.

The first thing worth knowing is the design philosophy here: less is best. All pipelines reuse the same three core files from the agents framework — the run script, the agent module, and the configs file. There are no new services to stand up, no new infrastructure to manage.

Now let’s talk about the two types of pipelines NZRT runs.

The first type is called Deploy and Agent Verify. This is triggered whenever code is pushed to the main branch on GitHub. After the deployment happens over SSH, a Claude Haiku model steps in to analyse the deploy state and returns either a pass or a fail result. The second type is called Business Event Pipelines. These are triggered either on a schedule via Windows Task Scheduler or by events coming in through a Nextcloud trigger bus. Named pipelines hand off plain-English goals to existing ReAct loop agents, and those agents figure out which tools to use to complete the goal.

Let’s look at the full pipeline catalogue. There are six pipelines in total. The deploy verify pipeline uses Haiku directly and fires on every push to main, annotating the GitHub Actions run with a pass or fail result. The product sync pipeline uses the pam agent, runs daily at two in the morning and also responds to Dolibarr events, and writes a sync log to the shared marketing folder. The backup verify pipeline uses the dan agent, runs every morning at six, and writes a backup verification file to the shared database folder. The daily finance pipeline uses the fin agent at seven in the morning, writing a finance summary to the shared finance folder. The weekly analytics pipeline uses the dai agent every Monday at eight and produces a weekly report in the shared analytics folder. And finally, the health diagnose pipeline also uses dan, but this one is event-driven — it fires when cPanel reports a failure and writes a diagnostics file to the shared database folder.

Let’s go deeper on the Deploy and Agent Verify flow, because it’s a neat piece of work. After your SSH deploy step completes, GitHub Actions sets up Python, installs the Anthropic library, and runs the verify deploy script from the agents framework folder. That script connects to cPanel over SSH, collects three things — the git log, file permissions, and script timestamps — then passes all of that to Claude Haiku in a single-turn call. The whole thing takes about two seconds and costs roughly a tenth of a cent per deploy. If Haiku is satisfied, the pipeline exits cleanly and GitHub shows a green notice annotation saying agent verification passed. If something looks wrong, it exits with a failure code and GitHub shows a red error annotation with Haiku’s diagnosis text. One thing you’ll need to add is a new secret in the NZRT-Scripts repository — the Anthropic API key — so the runner can authenticate.

Now for Business Event Pipelines. You run these by calling the pipeline runner script with the name of the pipeline you want. For example, you’d call it with product sync, or backup verify, or pass a list flag to see all available pipelines. This runner is a thin wrapper over the existing run script — it doesn’t modify the tested entry point, it just maps pipeline names to agent codes and goal templates, then hands off to the ReAct loop in the agent module.

Scheduling is handled by Windows Task Scheduler, not cPanel cron. The reason for this is that agents need access to the Anthropic API key and other system credentials, and those live locally on the laptop. The laptop is the convergence point. To get everything set up, you navigate to the agents framework folder and run the setup scheduled tasks PowerShell script once as Administrator. After that you can verify the tasks were registered by querying the task scheduler and filtering for NZRT entries — you’ll see the task name, its status, and when it’s next scheduled to run. If you want to test one immediately, you can trigger it manually by name without waiting for its scheduled time.

The last piece of the puzzle is the trigger bus. For events that don’t come from GitHub — things like cPanel failures, new products added in Dolibarr, or files uploaded to Nextcloud — NZRT uses a Nextcloud folder as a lightweight message bus. A polling script in the agents framework checks this folder every five minutes and watches for new trigger files. When it finds one, it fires the appropriate pipeline. No ports to open, no extra infrastructure — Nextcloud’s desktop client is already syncing, so the folder is always available.

To summarise the key files you care about: verify deploy lives in the agents framework folder and handles the GitHub Actions verification. Run pipeline also lives there and is your entry point for named pipelines. Poll triggers handles the Nextcloud event bus. Setup scheduled tasks is the one-time PowerShell setup script. And the deploy workflow file in the dot-github workflows folder is where the GitHub Actions changes live.

The key design decisions worth remembering: Haiku for deploy verification because it’s fast and cheap. The pipeline runner wraps but never modifies the tested run script. Windows Task Scheduler because credentials live locally. And Nextcloud as the message bus because the infrastructure is already there.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.