xmemory + Temporal: Long-running agents. Durable execution. Durable memory.

xmemory and Temporal are partnering to bring reliable execution and shared, structured state to developers building long running agents.

An agent starts a task in the morning. It researches a problem, calls tools, delegates work, and pauses for a human decision. By the time that decision arrives, the Worker running it may have restarted, the requirements may have changed, and another agent may have taken over part of the job.

This is becoming a familiar shape of agentic development. Developers at the frontier are giving agents work that spans hours or days, multiple sessions, and entire teams. As that responsibility grows, reliable execution and well-managed state become essential parts of the application. [1]

The longer the task, the more reliability matters

Every completed step represents time, compute, and progress towards an outcome. The longer an agent works, the more costly it becomes to start over. A network outage or Worker restart should not erase hours of investigation.

Temporal makes execution durable by recording Workflow events and completed Activity results. After a Worker restarts, it can reconstruct execution state and continue the Workflow. [2]

Activities handle external operations such as model and tool calls, with retries governed by configured policies. Long waits, including pauses for human approval, become a normal part of the Workflow. [3]

Replit already uses Temporal to orchestrate its coding agent. Integrations with frameworks such as Pydantic AI and Vercel’s AI SDK bring that same foundation to a growing ecosystem of agent developers. [1]

State has to stay useful, too

While execution moves forward, the agent’s understanding of the work changes. Requirements are revised, hypotheses are rejected, and tasks change hands. Each decision depends on having an accurate view of where things stand.

Consider a team investigating a software issue. One agent identifies a likely cause, another tests a fix, and a reviewer rejects it. Tomorrow, a new agent joins. It needs to know that the fix was rejected, why, and which questions remain open. If it treats the original proposal as the accepted solution, the team can repeat the same failed work.

xmemory gives developers an explicit way to model that knowledge. A memory schema defines the entities, fields, and relationships the application cares about, along with instructions for extracting and updating them. xmemory applies those rules to incoming information, validates the resulting records, and makes the stored state queryable. [4]

For this team, the schema can describe issues, proposed fixes, review outcomes, and their relationships. A review updates the recorded status of a fix; its outcome and rationale remain available to the next agent. Multiple agents can read from and contribute to that shared memory across runs. [5]

From one long-running agent to a team

The partnership brings these two responsibilities into the same application: [6]

Temporal · Durable execution

Continue the work.

Preserve Workflow progress, coordinate steps, and recover execution after interruptions.

xmemory · Durable memory

Carry the knowledge forward.

Extract, validate, update, and query shared domain records according to your memory schema.

A task can outlive a Worker, a session, or any one member of an agentic team. We want developers to be able to design around that continuity from the start, and spend more of their effort on what their agents can accomplish.

In practice: an agent team tracking AI events

We built a reference integration around a recurring job: discovering AI conferences, meetups, hackathons, and summits, then collecting the details a team needs to decide where to participate. Agents build a shared catalogue of events, deadlines, and topics; people add attendance plans. That knowledge accumulates across cycles and remains available to everyone working with it. The reference implementation shows how the parts fit together.

A domain constraint: one event per person, per day

The application has a concrete rule: a team member can be assigned to at most one event per day. The schema expresses attendance as a three-part relation connecting TeamMember, CalendarDay, and Event. Consider a person entering this statement:

Attendee TeamMember	Date CalendarDay	Event Event
Maya Chen	2027-03-03	ExampleConf 2027

(Illustrative input and its intended relation, following the repository’s attendance template. Names and plans are fictional.)

xmemory uses the schema to interpret that sentence as a link between three records. The date describes this person’s attendance: a conference may run for several days, while a teammate attends just one. Another teammate can attend on a different day, and the event’s own dates and details remain attached to the shared Event record.

The relation’s uniqueness key covers the attendee–date pair. The event sits outside that key, so assigning the same person to a different event on the same day creates a conflict. This is a domain constraint declared directly in the memory schema:

attendance:
  objects:
    attendee: {type: TeamMember}
    date: {type: CalendarDay}
    event: {type: Event}
  keys:
    one_event_per_person_per_day: [date, attendee]

(From the attendance relation. Descriptions and deletion settings omitted; participant definitions condensed.)

Another attendance statement	What the key means
Maya Chen attends ExampleConf 2027 on 2027-03-04.	A different date permits a separate attendance link.
Leo Martin attends ExampleConf 2027 on 2027-03-03.	A different attendee permits a separate attendance link.
Maya Chen attends another event on 2027-03-03.	The same attendee–date key cannot hold both event links.

(Illustrative consequences of the key, not captured write results. The backend test asserts that one attendance link remains after a conflicting write.)

The schema defines which combinations of person, date, and event are valid in shared memory. That rule remains in place as people record plans and agents add event knowledge. Questions such as “Who is attending ExampleConf on March 3?” can then connect attendance with the venue and topics researched by the agents. This is what programmable memory brings to the application: explicit domain rules governing the state the team shares.

A second memory instance stores run logs and notes about useful sources. Together, the two instances retain the team’s event knowledge and the agents’ experience of researching it.

Shared state makes the handoff explicit

Two agents divide the work.

Agent	Responsibility
Discovery	Searches the web, deadline directories, and event platforms, then records event names, websites, and sources.
Processor	Researches each waiting event and writes back its details and processing status.

Both use the OpenAI Agents SDK, with tools for web search, page fetching, and memory. Discovery’s tool list includes event writes and coordination-board reads, with no event-lookup tool.

The same approach makes the agents’ handoff explicit. Discovery writes an event without a processing status, and the Workflow queries for waiting records to pass to Processor. Processor adds the researched details and marks the event processed or failed.

The schema deliberately gives processing_status no default: rediscovering an event, or recording someone’s attendance, should leave its existing processing status intact. The regression test checks that a later discovery preserves the processed status and researched dates. The agents can contribute to a shared record without having to repeat the entire record in every write.

Temporal carries the cycle forward

A long-running Temporal Workflow orchestrates the two agents through the OpenAI Agents SDK integration and xmemory’s Temporal integration. [3] [6] Each cycle follows a small, explicit sequence:

Open a run and launch Discovery as a child Workflow.
Query the events memory for records waiting to be processed.
Launch a Processor child Workflow for each event, limiting how many run at once.
Record the outcome and use Continue-As-New to carry execution forward with a fresh Workflow history.

Model calls, page fetches, and memory operations do their external work through Activities. In the agent’s memory tool, the integration is a call to write_durable:

status = await _events(ctx).write_durable(
    text, extraction_logic="deep", max_wait=WRITE_MAX_WAIT, max_poll_interval=WRITE_MAX_POLL_INTERVAL
)

(The write call inside events_remember. Validation and error handling omitted; the repository defines the timeout constants and memory handle.)

The call starts extraction and waits for its result through a Workflow-managed polling loop. Once the write ID is recorded, the wait can resume after a Worker restart. Temporal also reuses Activity results already recorded in history during replay. [6]

The implementation treats retrying an unfinished write as a separate concern: its write policy excludes server, availability, and unknown errors from automatic retries, and the tool tells the agent to report a failed write without resubmitting the same text.

Operators can send Signals to request a cycle, pause execution, or queue an instruction for Discovery, and use a Query to inspect the Workflow. The system can run unattended while remaining steerable.

What carries forward

After a cycle completes, its findings remain available for questions such as “Which conferences in Europe have an open call for papers?” or “Who is attending an event in December?” The catalogue remains useful beyond the research cycle, whether the next reader is another agent or a teammate planning a trip.

The broader pattern is reusable: define the identity and update rules for the knowledge, make handoffs visible in shared state, and let Temporal orchestrate the work that changes it. Each agent can specialise in its task, with execution progress and accumulated knowledge preserved beyond its own run.

Build with xmemory and Temporal

Explore the Temporal integration guide and the events-agent reference implementation to see the schemas, workflows, and tools together.