Looking for 3 real Make automation cases for a free pilot audit

Hire a Pro Offer Help
, ,
1

UPDATE — The original free pilot audit phase has now been completed.

I’m now offering professional Make workflow audits, reliability reviews, workflow rescue, and controlled automation pilots.
The original topic title remains from the initial validation phase.

Hi everyone :waving_hand:

I’m Hilario Aguilar, founder of Imperial AI Infrastructure.

I help businesses and automation teams review, troubleshoot, and strengthen Make workflows before they go live — or when an existing automation appears to run successfully but the real-world outcome is uncertain.

My focus is automation reliability and evidence-based verification.

I can help with:

• Duplicate prevention and idempotency
• Retry and failure handling
• Silent failure detection
• Webhook and API workflow review
• Google Sheets workflow validation
• Human-review gates for uncertain AI decisions
• Audit trails and evidence logging
• Read-back verification
• Workflow documentation
• Pre-launch QA
• Existing automation rescue and debugging

A principle I use in every review:

Execution Success ≠ Outcome Verified

A Make scenario showing “success” does not necessarily prove that the intended business result actually happened.

My work focuses on closing that gap.

I can work with an existing Make scenario or help build a controlled pilot for a new business automation.

English written communication available.
Spanish native / bilingual communication available.

Based in Minnesota, USA.

If you have a Make workflow that works but you are not completely sure whether it is reliable, traceable, or safe to scale, send me a message with:

  1. What the workflow is supposed to do
  2. What applications it connects
  3. What problem or uncertainty you are seeing

I’ll review the situation and tell you whether an audit, repair, or controlled pilot makes sense.

— Hilario Aguilar
Imperial AI Infrastructure

11

Retry duplicates and “completed but nothing happened” are where I’d start. For each critical action, check whether it has a stable idempotency/correlation key and whether it leaves an outcome receipt outside Make, somewhere the scenario’s own run history can’t lose. Might be worth making those two checks the spine of the short report?

17

Hi Captain Harlock,

Thanks — this is very helpful, and your two suggested checks line up closely with what we’ve been finding during the reliability review.

We’re currently treating these as two separate failure classes:

  1. Retry/duplicate risk → stable idempotency or correlation identity before the critical action.
  2. “Completed but nothing happened” → an external outcome receipt that survives independently of Make’s own execution history.

I especially like your suggestion of using those two checks as the spine of the short report. We’re going to incorporate that framing into the review.

One question: when you say an outcome receipt outside Make, what have you found most practical in real deployments — a database audit row, an external event log, a destination-side read-back, or some combination of those?

Thanks again for taking the time to point us in that direction.