Short links as infrastructure: the case for treating redirects like environment variables

There is a quiet pattern showing up in the agent code we see in production. URLs that used to be string literals are turning into short link calls. The agent does not hold the destination. It holds the short code. The short code resolves to whatever destination is current.

It is the same pattern that turned hardcoded passwords into environment variables and environment variables into secret managers. The thing the code holds gets thinner and more stable. The thing that actually changes — the value behind it — gets moved out to a place where humans and other systems can update it without redeploying.

Three places this shows up

Outbound webhooks

An agent posts a webhook to a customer endpoint. The customer migrates from one cloud to another. Without a redirect layer, every agent that holds the old URL fails until someone redeploys. With a redirect layer, the customer updates the destination on the short link, the agent keeps shipping, no one notices.

Generated deliverables

An agent produces a report and emails the user a link. The report lives on a signed URL that expires in seven days. The user reads the email three months later and clicks. Without a redirect, broken link. With a redirect that the agent updates each time it regenerates the report, the user gets the latest version every time.

Promo URLs in print and email

A campaign goes out to ten thousand people. Halfway through the week, the landing page moves. With a redirect, the campaign keeps converting. Without one, half the audience hits a 404 and you are answering support tickets instead of reading the dashboard.

The contract that makes it work

For this pattern to be safe, the redirect layer needs a few properties teams often skip when evaluating shorteners:

• Immutable codes. Once a code is taken, it never gets reassigned to a different owner.
• Atomic destination updates. The swap is either old or new, never half-and-half mid-traffic.
• Audit trail. Every destination change is logged with who, when, and what changed. This is essential the day a destination change breaks a downstream pipeline at scale.
• Health visibility. You can tell, per link, whether traffic is still flowing.
• Failure isolation. A bad destination on one link must not take down the redirect tier for every other link.

How Filoo handles this

Every destination change writes to a separate history table so you can see every URL a code has pointed at and when. The PATCH endpoint is atomic at the database level — the next click hits the new destination, the previous click hit the old one, there is no window where both are valid. Codes are scoped to a username, so two agents on the same plan cannot accidentally claim the same slug. Per link stats are exposed over a clean JSON endpoint, not a screenshot.

If you are scaling out an agent platform and your team is still treating URLs as inline string literals, this is the smallest amount of plumbing you can install that materially reduces incident pressure. Five endpoints, one SDK, one bearer token. Try it before the next destination migration forces you to rebuild it under load.