I've run into this exact problem with the runportalaction stuff, you can't just trust a script to behave in prod without proper job states and idempotency baked in. The wire vs asteroid split matters too, shared catalogs spread fixes across customers while per-customer discovery just lets everyone hit the same drift on their own. No matter how fancy the tool is it won't get you around portal rate limits, that's just physics at that point. If your runtime is stretching into multiple minutes for a high volume flow that's already telling you something is wrong. Defining inputs and outputs early is a good start but the real work is catching when the portal quietly breaks that contract after you ship, because drift happens live and only active monitoring catches it in time