Relay.app Is Gone, and So Is Everything It Remembered About Your Work

Relay.app shut down in September 2026. Free users lost access on August 15, paying customers on September 14, and then it was over: the shutdown notice went up on relay.app, and every account, workflow, and run history was permanently deleted. Founder Jacob Bank and part of the team moved to Google's Chrome team. Good product, talented team, and it still died, because standalone automation vendors keep getting absorbed by bigger platforms.

You probably already knew that. Here is the part nobody is talking about.

The shutdown deleted memory, not just software

When an automation platform closes, the conversation focuses on rebuilding workflows: export your triggers, rebuild your steps somewhere else, find a new vendor. That is the easy part. Workflows are logic. Logic can be retyped.

What cannot be retyped is everything the platform remembered about how those workflows actually behaved in the real world. Run history. Which inputs worked and which broke. The corrections you applied after a bad run. The patterns your AI steps learned about your customers, your data, your edge cases. Years of accumulated operational knowledge lived inside the platform, and when the platform shut down, all of it went with it.

Operators rebuilding on a new platform discovered something quietly brutal: their rebuilt workflows worked, but they started from zero. The new system knew the steps. It did not know what the old system had learned. Every mistake the old system had stopped making came back.

This is what run-to-run amnesia looks like at platform scale. You have probably been living a smaller version of it all along: your scheduled agent wakes up blank every morning and re-learns the same lessons from scratch. A platform shutdown is just that problem wearing a suit. Same disease, bigger funeral.

Memory lived inside the platform because that was convenient

Here is why it hurt so much. Relay users, like most automation operators, kept their agents' operational knowledge exactly where the platform told them to keep it: in run histories, in step outputs, in the implicit state that accumulates when software runs the same process a thousand times. The platform was the memory. It held the context, the logs, the corrections, the history. And it was all deleted on September 14 because the platform was the only place it existed.

This was never a Relay-specific flaw. It is how most automation stacks are built. Your n8n execution history, your Zapier task history, your Make scenario logs: all of them live inside the vendor's walls. Your agent's memory is your vendor's data, and your vendor's data has an expiry date you do not control. Companies get acquired, pivot, sunset products, or just die. The average lifespan of an automation tool in your stack is shorter than the lifespan of the knowledge it holds.

The lesson from Relay is not "choose better vendors." It is "stop storing your agents' memory in a place that can die."

What operators should have exported first

Taskade's migration guide for ex-Relay users got the priority right: migrate the flow that touches revenue first, and export everything before access ends. But "export everything" deserves a sharper definition than a workflow JSON.

The workflow definition is the least valuable thing you own. It is the recipe. What matters is the ledger of how the recipe behaved: which runs succeeded, which failed and why, what you changed after each failure, the decisions an AI step made on ambiguous inputs and whether they were right. That is the stuff that cannot be retyped from memory, because most of it was never written down anywhere except inside the platform's run history.

If you are running automations today on any platform, the exercise is worth doing now, not during a wind-down countdown. Ask: if this platform announced its shutdown tomorrow, what would I lose that I could not rebuild? If the answer includes anything your agents learned by running, you have memory locked inside a vendor. Export it while you still can, and move it somewhere the vendor's fate cannot reach.

The fix is a memory layer that survives its tools

The way out of this trap is architectural, not sentimental. Memory should not live inside any single tool in your stack. It should live in a layer of its own, one that every tool reads from and writes to, and that survives any individual tool dying, being replaced, or getting acquired.

This is the same argument operators make for portable databases over vendor-locked datastores, applied to agent context. Your agent's memory should be infrastructure, not a feature of a product. When Relay died, the operators who kept their run knowledge in their own systems lost a tool. The ones who kept it in Relay lost a tool and everything it knew.

A hosted memory service over MCP is one way to get this. Your agents, across n8n, Make, Zapier, or whatever you migrate to next, read and write the same shared memory through a standard protocol. The memory does not live in any of those tools, so none of them can take it with them when they die. You export it anytime in a portable format, or delete it yourself. It is yours, not the platform's.

Vilix AI works this way: cloud-hosted with zero infrastructure to manage, the same memory available to every tool over MCP, full conversation history rather than just extracted facts, a free plan that is actually free forever, and a 7-day Pro trial that does not ask for a card. Your data stays portable: export everything or delete it whenever you want. The point is not the product name. The point is the architecture: memory that outlives the tools that use it.

FAQ

Could Relay users have saved their run history?

Relay offered an export, and migration guides urged users to export before the deadlines. Whether that export included full run history and learned context is a separate question from whether workflows were exported. Most operators export the recipe and leave the knowledge behind.

Is this only a shutdown problem?

No. Every migration is a memory wipe. Every vendor switch, every tool replacement, every "we are moving from Zapier to Make" project quietly deletes accumulated operational knowledge. Shutdowns are just the version with a deadline.

What should I keep in an external memory layer?

Decisions and their outcomes, corrections after failures, learned patterns about your data and customers, and the full run history that lets an agent understand what "normal" looks like for your operation. The test: if a new tool cannot function without it, it does not belong inside the old tool.

Relay's shutdown is a story about a good product losing to platform gravity. For operators, it is also a warning: the memory your automations depend on should never live in a place that can shut down. Put it in a layer you control, connect it over an open protocol, and the next time a tool in your stack dies, you will lose the tool, not what it knew.

Start with a free plan at Vilix AI. Free forever, no credit card.