How AI Put a Reliability Promise on Every AJO Service

Giving nearly every service behind Adobe Journey Optimizer a measurable reliability commitment — at a speed and scale that manual work could never have reached.

In our last post, From Gut Feeling to Grade Point, we walked through the Service Scorecard — the automated grade every AJO service earns across four dimensions of quality. One of those dimensions is Reliability Against Our Commitments: how much reliability margin a service is holding against the target it's promised to meet.

That dimension is only as strong as the reliability targets behind it. Today, with an SLO defined for 90%+ of AJO services, we have clear, standardized visibility into exactly what each service is expected to deliver — and how much margin it's holding against that target.

This is the story of how AI got us there — giving nearly every service behind AJO a precise, measurable reliability commitment, at a speed and scale that would have been out of reach any other way.

What a Reliability Promise Actually Is

Every service that powers AJO makes an implicit promise: it will be available when you need it, and it will respond quickly enough that you never notice it working. A Service Level Objective, or SLO, turns that implicit promise into a specific, measurable one — for example, “99.9% of requests succeed” or “messages are processed within a few seconds of arriving.”

An SLO is only useful if something is watching it. So each one is backed by alerts that page the right team the moment reliability starts eroding faster than it should — well before the erosion is large enough for a customer to feel it. Think of the SLO as the promise, and the alerts as the smoke detector wired to it.

The catch: a promise is only meaningful if it's the right promise. Measuring the wrong thing, or setting a target so loose it never trips or so tight it cries wolf, is worse than no SLO at all. Getting it right, service by service, is exactly where the difficulty lived.

The Careful Work Behind Every Good SLO

AJO already runs on strong, standardized telemetry and observability — every service emits a rich stream of signals about how it's behaving. The craft is in turning that signal into the right SLO for each service: choosing what matters most, setting a target that reflects reality, and proving it holds up. Done by hand, that's a sequence of careful, specialized steps:

• Pinpoint the right signals. Across a rich observability stack, identify exactly which measurements best represent this service's health, in each region it runs.
• Decide what to measure. A service that answers live requests is best judged on availability and latency; a worker processing a stream of events on freshness and completeness. Matching the measure to the service is a judgment call.
• Set a target grounded in reality. Calibrate against how the service actually behaves over recent history, so the target is both meaningful and genuinely achievable.
• Capture it in the standard format. Express the service definition, each objective, and the alerts in the shared, canonical shape AJO uses everywhere.
• Prove it out. Confirm the SLO would have behaved sensibly over the past several weeks — signalling real risk, not firing on every blip — before it goes live.

None of these steps is difficult on its own, but each one takes care, and each one takes time. Multiply that across hundreds of services that keep growing, and this detailed, per-service calibration becomes a long tail of specialized work — exactly the kind of meticulous groundwork that's easy to sequence behind the constant, healthy drumbeat of shipping features and meeting customer commitments. That's the work AI is now doing for us, at a pace that keeps up with AJO.

The SLO Generator: The Same Expertise, Driven by AI

The SLO Generator collapses all that careful work into a single guided command. A service owner asks for a service to be onboarded, and an AI-driven pipeline does the work end to end, pausing only at the moments a human should actually weigh in. Here's what it does under the hood.

1. Discover — find the signal automatically. The generator fans out across our observability systems to pinpoint exactly where the service reports its health. It reads the service's own deployment configuration to confirm its identity, and recognizes even non-obvious signal patterns that a quick manual look might pass over.
2. Classify & Generate — decide what to measure, then write it. This is the heart of the “AI reading the service” idea: the generator determines the type of service, and that classification decides what to measure. It then writes the full SLO definition and its alerts in one canonical shape — with alerting tuned to traffic, so a busy service gets layered alerts while a quiet one gets a single patient alert that won't fire on every blip.
3. Propose & Document — calibrate, prove, and raise it. The generator calibrates each target against about four weeks of real history — a level the service can genuinely meet, not a hopeful round number — then replays the SLO across the last 28 days as evidence. It packages all of it into a fully documented proposal so a reviewer can see the SLO would have held up before it goes live.
4. Verify & Reconcile — keep it honest, continuously. Onboarding doesn't end at “done.” After an SLO lands, the generator confirms it's live and healthy, and a daily reconciliation compares what's recorded against reality and quietly corrects any drift. The inventory stays trustworthy without anyone babysitting it.
5. Register & Productize — make it durable. Finally, the SLO is recorded in AJO's source of truth and exposed for lookup, so coverage sticks and every team can see exactly what each service promises. This is what turns a one-off definition into a lasting part of how AJO runs.

What the AI Actually Looks For

The classification step is where the intelligence shows. The generator reads how a service behaves and sorts it into a type — and each type comes with the right things to measure.

Two things make this reliable at scale. First, the mapping from type to what to measure is fixed and applied identically everywhere — a request-driven service is measured the same way no matter which team owns it. Second, it keeps a human in the loop by design: when a service doesn't fit a known pattern, the generator doesn't guess — it hands the service off to a person to look at. Human-in-the-loop is a well-established safeguard for exactly these judgment calls, and it's what keeps the inventory trustworthy — so an SLO means the same thing everywhere it appears.

Under the Hood: One MCP Toolbox

The SLO Generator ships as a single MCP toolbox — built on the open standard that lets AI assistants and agents call tools directly. Everything the pipeline does is packaged as purpose-built tools, organized into five stages:

A compact core chain runs the common path end to end from a single command, while the rest handle documentation, verification, reconciliation, and lookup. And because it's built on MCP, the same toolbox is available everywhere the work happens — to an engineer in their AI assistant, to an automated batch run across a whole capability, and to other agents. That last point is how the RCA Agent, next in this series, closes SLO gaps on its own.

What Changed: Speed, Scale, and Consistency

Speed. Onboarding one service dropped from a day or two of specialized manual work to a few minutes of mostly-automated pipeline. No hand-written definitions, no one-off scripts.

Scale. This is the number that matters most. Reliability coverage now spans 90%+ of AJO services — nearly every service whose behavior a customer could feel now carries a calibrated SLO. That's a jump manual onboarding would have taken years to reach, compressed into a fraction of the time. Because onboarding is now a command instead of a project, it scales the way AJO does: a single request can run the whole pipeline across an entire capability at once. Coverage that used to grow service by service now grows capability by capability.

Consistency. Every SLO comes out in the same shape — the same format, the same target-setting method, the same alert routing, the same 28-day proof. Reviewers stop re-checking mechanics and focus on the one question that actually needs a human: is this the right thing to measure for this service?

Correctness by default. Calibrated targets, traffic-aware alerts, and built-in guards against measuring noise mean the generated SLOs are ones worth keeping. The hard-won lessons — the stale-record trap, the noisy-alert problem, the wrong-template mistake — are encoded into the tool, so every service benefits from them, not just the ones onboarded by an expert.

Why This Matters to AJO Customers

This is the foundation under the Reliability dimension of the Service Scorecard. An SLO on nearly every AJO service means AJO can now watch its own reliability promises everywhere at once — and catch a service slipping against its commitment early, before that slip becomes something you'd notice in a journey or a campaign.

That discipline, running quietly underneath, is a big part of what lets your journeys, campaigns, and customer experiences behave the way you expect them to — day in and day out.

Authors: Dawud Abduweli Uyghurturk and Jigar Shah