Sync Medic: An AI Agent That Retries Failed Syncs Within Limits

The rail follows the AI agent rails method, and the recovery process is in failed sync retry with an AI agent. It picks up where the Audience Sync Steward stops, once a sync has a named approval.

Rail at a glance

The Sync Medic's rail gives the model no write access, because rules in the execution service decide every retry. The model writes the diagnosis, and nothing it says can authorise an attempt.

What it does and who uses it

The Sync Medic separates failures a patient retry can cure from failures that need an engineer.

Illustrative run: at 02:14 an approved audience sync to an advertising platform fails partway, with 503 and then 429 responses. The execution service confirms that version, audience hash and destination match the approval. It runs a fresh consent check, waits with backoff and retries, and the sync finishes. The model adds a short diagnosis for the morning review. The next night the same destination returns 401, which is no transient fault, so on-call receives a proposal to check the credential. On the third night the consent check removes three people. The hash no longer matches, so the retry stops and goes to on-call.

The retry decision is a checklist in code, and each row must pass. The last three rows are illustrative choices.

Reverse ETL tools draw similar lines. Hightouch's documentation, checked on 1 November 2026, says it does not retry requests rejected as invalid (400, 401, 403, 422) and gives 429 responses a larger budget 4.

Why this level

The Sync Medic can reach L4 on this one action because the retry adds nothing new. The same people, already approved, go to the same destination, so the blast radius equals what a named approver accepted. That holds only while version, hash and destination stay unchanged and consent has been re-checked. Anything else counts as a new activation.

The Rule of Two 1 is met by splitting the work. Error text comes from outside systems, so the model's session reads untrusted input, but it holds no payload and no tool. The action path can change state and contains no model. No single session holds all three properties.

Each destination starts at L3, with on-call approving retries. It moves to L4 on written replay evidence and the platform lead's sign-off. A duplicate delivery, an untested model or tool change, or an open incident drops it back, under the rail level rules. L4 is as far as the ladder goes, and it covers this retry alone.

Three ways it fails, and the control for each

Automatic retries go wrong when a repeat is not the same event.

How to evaluate it

Replay is the honest test for a retry agent: take historic failures, run them against a test destination and compare outcomes.

• Mean time to recover, compared with how the same incidents went by hand.
• Duplicate deliveries, counted at the test destination, with a target of zero.
• Failed retries, which show whether the error classes are right.
• Refusal tests. Change the hash, version or destination, drop the consent check, or exceed the cap. The execution service must refuse each one, even when the model asks.
• Diagnosis accuracy, sampled by on-call, because the note guides the morning's work.

Where it runs

Rules alone run the retry path, so no model needs customer data to keep syncs moving. A model, private by preference, writes the explanation from logs, and the boundary architecture patterns show how to keep it apart from execution. PrivyCDP records each AI-assisted action in an immutable audit ledger with its authorising actor, yet the medic is not a bundled agent.

Related

• Failed sync retry with an AI agent: how the vendor tools compare.
• AI agents for platform and data pipeline operations: why L4 is reachable early here.
• Rail card template: includes a filled Sync Medic example.

For the method behind these limits, start at the AI agent rails hub. Your own retry conditions can go straight into the rail card template.