Automating Product Support

Automating Product Support

Kablamo uses Claude to cut release admin time by 80%+ for Arts & Leisure

Kablamo uses Claude to cut release admin time by 80%+ for Arts & Leisure

About us

About

About us

About us

Kablamo built an automated Release Agent on Claude that turns release day into a machine-checked, self-documenting process — and we put it to work for Arts & Leisure, where every release of their bespoke travel-itinerary platform carries direct revenue risk.

Industry

Travel & Consumer

Service Offerings

Ongoing Product Care | Generative AI & Agentic Systems | Agentic Generation and Automation | Business Process Automation | DevOps & CI/CD | Human-in-the-Loop AI Workflows

Technologies Used

Claude Code (custom Release Agent), MCP integrations to Atlassian Jira and Confluence and to GitHub, local markdown files for handoffs and work manifests, GitHub Actions, AWS (underlying platform)

“Our tools didn't match the experience we sell. Kablamo changed that. Now everything from our itineraries to our day-to-day actually feels like Arts & Leisure, and with Kablamo we finally have a team behind the platform we can count on.”

“Our tools didn't match the experience we sell. Kablamo changed that. Now everything from our itineraries to our day-to-day actually feels like Arts & Leisure, and with Kablamo we finally have a team behind the platform we can count on.”

The Challenge

The Challenge

A&L sells bespoke travel itineraries, and the platform Kablamo built generates those itineraries, which makes its reliability a direct input to sales revenue.

The platform itself was stable, with ongoing support already running on only a few hours a month. Kablamo saw an opportunity to improve how releases were run, which relied on manual work spread across disconnected systems: Confluence checklists, Jira fix-version linking and ticket transitions, GitHub release notes, and rollback image preparation, all updated by hand every time. It was slow, and it was easy to miss a step.

A database change once reached the shared test environment without the metadata that triggers it, so the application started cleanly and then failed on a core booking view. It was caught before production but required rework to resolve.

Incomplete records compound that kind of failure because responding to an incident starts with establishing what actually shipped, and a rollback must be ready before anyone needs it. Under time pressure, small emergency releases were the most likely to be run with a shortened process, which is exactly when the full process matters most.

The Approach

The Approach

With A&L's platform already running smoothly, Kablamo turned its attention to how it operated day to day.

Kablamo looks for recurring manual toil as an opportunity to improve the developer experience: wherever operational work can be done reliably by a machine, we automate it. For speed, it executes every automatable release step. For quality, it runs the same validation suite on every release and reviews code before merge. For governance, it creates and tags versions on tickets and commits and writes cross-linked release documentation to A&L's standards as the release happens.

Certain actions are withheld by design, so the agent cannot trigger a deployment or confirm that the product owner has been informed. The same principle governs the agents running unattended. When one reaches a decision that isn't theirs to make and nobody is present, it parks the decision where a person will find it rather than treating silence as approval. It runs on local markdown files for handoffs and work manifests, and integrates through MCP with Atlassian (Jira and Confluence) and GitHub.

The Results

The Results

Speed. Release admin time dropped from hours to minutes — an 80%+ reduction — and the Release Agent is now the standard way every A&L release is run, across a product that ships roughly 15 times a year. 

Quality. The same validation suite now runs on every release regardless of size. The code review agent also catches defects before merge that the test suite and type checker structurally cannot, rather than becoming new work flagged after production release. In one deployment, the pre-flight checklist caught that GitHub Actions was in a partial outage while GitHub overall reported healthy - so deployment was paused and the client notified before an unreliable release went out.

Governance. Every release produces a full audit trail of what shipped, what was deliberately held back and why, and which checks passed or fell short. The most recent release recorded a change that shipped but was left untagged because its ticket wasn't finished, plus eleven related tickets checked and confirmed out of scope. That level of detail is what makes it an audit record rather than a change log. Documentation is now produced during the release rather than reconstructed after it, so context stays current for the work that follows.

Have a project in mind?

By submitting, you agree to our Privacy Policy.

Let’s talk.

If we can't move the needle,

we'll tell you.

Tell us what you’re trying to build. We’ll give you a straight answer.

Have a project in mind?

By submitting, you agree to our Privacy Policy.

Let’s talk.

If we can't move the needle,

we'll tell you.

Tell us what you’re trying to build. We’ll give you a straight answer.

Have a project in mind?

By submitting, you agree to our Privacy Policy.

Let’s talk.

If we can't move the needle,

we'll tell you.

Tell us what you’re trying to build. We’ll give you a straight answer.