Does BuildShip Remember Between Runs? Thread IDs, Cron Triggers, and What Actually Persists

Short answer: partly, and only if you set it up that way. A BuildShip assistant can keep a conversation going across interactions when you hand it the same thread ID every time. A scheduled BuildShip workflow, on the other hand, wakes up blank on every run unless the workflow itself loads the thread ID and the state it needs from storage first. Nothing about a cron trigger carries memory forward on its own.

That split catches people off guard because both halves feel like the same product. One is a chat feature. The other is how scheduled execution works.

Every BuildShip run starts fresh

BuildShip is a visual backend builder. You connect nodes into a workflow, and it runs as a serverless function on Cloud Run. A serverless execution has no memory of the executions before it. When a run finishes, its variables, its intermediate results, and whatever the AI node said all disappear with it. The next run starts from the workflow definition and whatever inputs the trigger supplies.

The scheduled trigger makes this explicit. BuildShip's Custom Schedule (Cron) trigger fires a workflow on a cron pattern, in a chosen timezone. The docs note that this trigger has no input or output mapping, and that "Get Data" is not supported on it. In plain terms: a cron run arrives with nothing from the past. No previous outputs, no previous thread, no list of what last night's run already did.

So if your scheduled workflow asks an AI node to triage new support tickets every morning, Monday's run has no idea what Friday's run triaged. If it enriches new leads, it will happily enrich the same leads again unless something outside the workflow tells it not to. The workflow is not forgetful in a buggy sense. It was never given a memory in the first place.

Thread IDs: the memory BuildShip does have

BuildShip's assistant nodes, for OpenAI, Claude, and Groq, work differently from the workflow around them. Each one accepts an optional Thread ID. Pass the same thread ID and the node reloads that thread's chat history and continues the conversation. The Groq assistant docs describe it directly: chat history is stored in the BuildShip Storage attached to the project, and providing a thread ID loads the previous messages; after each response, the latest messages are appended so the history is preserved for future interactions.

The OpenAI and Claude assistant nodes work the same way. A thread ID can be any unique identifier. Skip it and a new thread starts automatically, with a fresh ID returned as a node output. The docs say client applications should store that ID and reuse it for future interactions.

This is real continuity, and it is useful. A chatbot backed by a BuildShip workflow can remember the conversation it had with a visitor yesterday, as long as the visitor's thread ID is passed back in. A support assistant can pick up where a thread left off. The mechanism works.

But notice what it depends on: somebody has to store the thread ID and pass it in again. The node does not remember which thread belongs to whom. Your application, your database, or your workflow has to keep that mapping.

Where scheduled runs fall through the gap

Now put the two halves together. A scheduled workflow fires on cron, with no input. The assistant node inside it starts a new thread unless it receives a thread ID, and nothing in the trigger supplies one. So a scheduled run that calls an assistant node starts a brand-new conversation every single time, unless the workflow first reads a stored thread ID from durable storage and passes it in.

That is the step most people miss. The thread feature exists, but a cron run will not use it by itself. The workflow has to be built to fetch the thread ID at the start of the run and save it at the end. If that read-and-write step is missing, the assistant treats every run as a first meeting.

And even when the thread ID is wired up correctly, thread history is only conversation history. It records what was said in that thread. It does not record what previous runs did: which leads were already enriched, which tickets were already escalated, which decisions were already made. Those are a record of completed work, not a transcript, and that is where most "my agent keeps redoing work" complaints come from.

Three ways to give a scheduled BuildShip agent a real memory

1. Store the thread ID and read it first. If the workflow's job is a continuing conversation, keep the thread ID in a database, a sheet, or BuildShip Storage, and make the first step of every run load it. Pass it to the assistant node, and save it again at the end of the run. This gives the assistant continuity across runs, and it is the lightest fix when the conversation itself is the work.

2. Keep a record of completed work outside the workflow. For a scheduled agent that processes items, the durable fix is a system of record: a table of what was already processed, with IDs, timestamps, and outcomes. Each run reads that table before it acts, skips what is already done, and writes back what it just finished. BuildShip connects to databases like Firebase, Supabase, Postgres, and MongoDB, so the storage itself is not the hard part. The hard part is treating the table as part of the workflow and making the read-before-act step non-optional.

3. Give the agent a shared memory layer. The two fixes above work, but they are per-workflow plumbing. Every new scheduled agent needs its own thread handling and its own ledger, and none of them can see what the others learned. A hosted memory layer changes that shape. Vilix AI is a cloud-hosted memory layer your agents reach over MCP, so there is no infrastructure to run and no per-workflow database to maintain. The same memory follows the agent across BuildShip, n8n, Claude, ChatGPT, and every other tool you connect, and it stores full conversation history, not just extracted facts. It is free forever on the free plan, with a 7-day Pro trial that needs no credit card, and you can export or delete everything at any time.

The practical difference: instead of each scheduled run waking up blank and asking you to re-brief it, it starts from what every earlier run already knew, including runs from your other tools.

The bottom line

BuildShip remembers conversations when you pass the same thread ID, and nothing at all between scheduled runs unless you build that persistence yourself. The cron trigger carries no state forward, workflow variables die with the run, and thread history is a transcript, not a record of finished work.

If your scheduled agent keeps starting from zero, the fix is not a better prompt. It is a memory the run can read before it acts and write to after it acts.