Foundry · Ark
01 / 10
Paytm · Foundry / Ark platform

Ark × Travel:
the SDLC, run by agents.

Eight software-delivery use cases across Travel — Flights, Bus, Hotels, Trains, Sonar, Check-in, Figma and Vuln — now run as Ark agent flows. This is what they delivered, what it replaces, and what it saves.

8 use cases live 2,795 agent sessions 84% succeed
1 September – 9 October 2026 · tenant: travel (ocl) · Flights · Bus · Hotels · Trains · Sonar · Check-in · Figma · Vuln
The picture at a glance

Not a pilot. The default way Travel ships.

From 1 September to 9 October, Ark agents ran the software-delivery loop across eight Travel use cases — 98% of runs engineer-initiated, most ending in a pull request a human only needs to review.

0
Travel use cases with live Ark automation
0
Agent sessions, 1 Sep – 9 Oct
0
Succeed (of sessions that concluded)
0
Unique agent PRs delivered
Every headline number here is measured from the control plane. (The per-use-case slides add an eng-hours estimate and state its one assumption, ~3h/session, on each slide.)
Success & failure — the honest cut

2,358 of 2,795 sessions succeeded.

Every session, per use case, across the window: green = completed, red = did not complete (failed, stopped or still in flight).

How to read the ~15% that didn't complete

Of 2,795 sessions, 2,358 completed (84.4%); the rest are a mix of failedstoppedstill running over five weeks — including sessions interrupted by the Sep–Oct control-plane / arkd reachability issue (being fixed). Flights 85%, Bus 89% and Sonar 99% lead; Figma ran clean; Hotels 76%, Trains 72% and Check-in 74% sit lower, and Vuln (low volume) at 40%.

The eight use cases

One engine, eight Travel surfaces.

Flights

ADLC + platform CI/CD as agent flows, end to end.
663
PRs delivered
85%
success

Bus

Backend system flow + Cursor-driven UI changes.
553
PRs delivered
89%
success

Hotels

Hotels system ADLC + test-generation as agent flows.
339
PRs delivered
76%
success

Sonar

Sonar findings auto-fixed continuously on Trains FE + Check-in.
225
PRs delivered
99%
success

Trains

Slack-triggered SDLC + daily H5 perf watcher.
86
PRs delivered
72%
success

Check-in

Crash → auto-fix PR on travel-checkin-platform.
15
PRs delivered
74%
success

Figma

Figma designs → front-end code on flights-adlc.
90–95%
Figma match
1
PR delivered

Vuln

Security findings → PRs; hardening on Trains (code vs config).
1
dedicated PR
in prog.
Trains first
DevOps · Flights Platform CI/CD

The Release Train — 35 pipelines → one gated train.

From a pipeline per service and a human clicking Build, to one gated train — an ephemeral stack brought up, automated regression run against it, then torn down — that records what shipped and explains itself when it breaks.

Before — 35 manual pipelines

A person clicking through each one

  • 35 services, one multi-branch pipeline each, two manual clicks (Build, Deploy) per release.
  • No record of which commit produced which image — nothing could answer “what’s running in prod?”
  • Hotfixes shipped to prod, never merged back, silently lost on the next release.
  • Every red build = 20–40 min of a senior engineer reading logs.
Now — one gated train

Triggered once, records everything

  • One train, 7 stages, triggered once — Jenkins starts it; no one clicks Build or Deploy.
  • Ephemeral env: a real stack is brought up, automated regression (backend + mweb) runs against it, then it’s torn down — cleanup on every path, pass or fail.
  • Hard gates now enforced that used to live in people’s heads — Build (lint/tests), Regression, ancestor-of-master, production-branch, and QA sign-off — each blocks or refuses, recorded per commit.
  • One record per commit: which gates passed, which image each service got, which commit produced it — queryable, not remembered.
  • On a break, the pipeline explains itself in Slack, log quoted, before anyone asks.
35→1
pipelines → one train
2→0
manual clicks / release
5
hard gates enforced
only changed
services rebuilt
Flights Release Train, Oct 2026. Ephemeral env = real-stack bring-up → regression → teardown, triggered once under a release lock. Regression currently reports; making it blocking is a deliberate next step.
DevOps · when it breaks

A pipeline that explains its own failures.

When a stage fails, only the logs that bear on it are gathered; a model reads them, finds the one thing that broke, and posts a verdict with proof to Slack — every claim quoting the log word for word, or saying it could not tell rather than guessing.

Re-run

Infrastructure hiccup — nothing to fix.

Fix code

A person must change something.

Wait

Another release holds the train.

Needs a human

It could not tell — and says so.
per-commit
image ↔ commit, traceable
4 verdicts
every failure classified
20–40 min → 0
manhunt → Slack message
What it means

Travel's delivery is no longer bounded by headcount.

Eight use cases, 2,795 sessions, 84% success across five weeks — and the marginal cost of the next use case is days of config, not a platform build. Agents delivered 1,883 unique PRs this window, 98% engineer-initiated; engineers spent their time reviewing, not scaffolding.

8 live use cases 84% success 1,883 unique PRs 98% engineer-initiated near-zero cost per next use case
Ark × Travel · Bhurva Sharma · Foundry / Ark platform · data 1 September – 9 October 2026