---
title: "Server-Managed Conversations with OpenAI Conversations API"
description: "Use the OpenAI Conversations API with conversations.create, previous_response_id chaining, and auto_previous_response_id for server-side history management in AI agents."
canonical: https://callsphere.ai/blog/server-managed-conversations-openai-conversations-api
category: "Learn Agentic AI"
tags: ["OpenAI", "Conversations API", "Server-Managed", "Memory", "Python"]
author: "CallSphere Team"
published: 2026-03-14T00:00:00.000Z
updated: 2026-05-06T22:11:11.686Z
---

# Server-Managed Conversations with OpenAI Conversations API

> Use the OpenAI Conversations API with conversations.create, previous_response_id chaining, and auto_previous_response_id for server-side history management in AI agents.

## Two Approaches to Conversation History

The OpenAI Agents SDK supports two fundamentally different approaches to managing conversation history:

1. **Client-side sessions**: Your application stores and retrieves history using a session backend (SQLite, Redis, SQLAlchemy). The full history is sent with each API request.
2. **Server-managed conversations**: OpenAI's servers store the history. You reference it with an ID, and the server reconstructs the context. Your application only sends the new message.

Each approach has distinct tradeoffs. This post explores server-managed conversations and when they are the right choice.

## How Server-Managed Conversations Work

With client-side sessions, every API call includes the full conversation history in the request payload. For a 50-turn conversation, you are sending all 50 turns every time.

```mermaid
flowchart TD
    MSG(["New message"])
    WORKING["Working memory
rolling window"]
    EPISODIC[("Episodic memory
past sessions")]
    SEMANTIC[("Semantic memory
facts and preferences")]
    SUM["Summarizer
compresses old turns"]
    ROUTER{"Retrieve
needed memories"}
    PROMPT["Assembled context"]
    LLM["LLM"]
    UPD["Memory updater
writes new facts"]
    MSG --> WORKING --> ROUTER
    ROUTER -->|Past sessions| EPISODIC
    ROUTER -->|User facts| SEMANTIC
    EPISODIC --> SUM --> PROMPT
    SEMANTIC --> PROMPT
    WORKING --> PROMPT --> LLM --> UPD
    UPD --> EPISODIC
    UPD --> SEMANTIC
    style ROUTER fill:#4f46e5,stroke:#4338ca,color:#fff
    style LLM fill:#f59e0b,stroke:#d97706,color:#1f2937
    style EPISODIC fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b
    style SEMANTIC fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b
```

With server-managed conversations, OpenAI stores the conversation on their servers. Your API call includes only:

- The new user message
- A reference to the previous response (`previous_response_id`)

The server reconstructs the full context internally. This reduces your request payload size dramatically and simplifies your client code.

## conversations.create() and conversation_id

The Conversations API lets you create a named conversation container:

```python
from openai import AsyncOpenAI

client = AsyncOpenAI()

# Create a conversation
conversation = await client.conversations.create()
print(f"Conversation ID: {conversation.id}")
# Output: conv_abc123...
```

The `conversation_id` is a persistent handle for the conversation. You can use it across multiple requests to maintain continuity.

## previous_response_id Chaining

The core mechanism for server-managed multi-turn conversations is `previous_response_id`. Each response has a unique ID, and you pass it to the next request to chain them together.

```python
from openai import AsyncOpenAI

client = AsyncOpenAI()

# Turn 1
response1 = await client.responses.create(
    model="gpt-4o",
    input="My name is Alice and I'm planning a trip to Japan.",
)
print(f"Turn 1: {response1.output_text}")
print(f"Response ID: {response1.id}")

# Turn 2 — chain to Turn 1
response2 = await client.responses.create(
    model="gpt-4o",
    input="What month should I visit?",
    previous_response_id=response1.id,
)
print(f"Turn 2: {response2.output_text}")
# The model knows Alice is planning a Japan trip

# Turn 3 — chain to Turn 2 (which chains to Turn 1)
response3 = await client.responses.create(
    model="gpt-4o",
    input="And what's my name?",
    previous_response_id=response2.id,
)
print(f"Turn 3: {response3.output_text}")
# Output: "Your name is Alice."
```

The chain is cumulative — response3 has context from all three turns because each response links back to its predecessor.

## Using Server-Managed Conversations with the Agents SDK

The Agents SDK integrates server-managed conversations through the `auto_previous_response_id` setting:

```python
from agents import Agent, Runner

agent = Agent(
    name="ServerMemoryAgent",
    instructions="You are a helpful assistant with server-managed memory.",
)

# Turn 1
result1 = await Runner.run(agent, "I live in Tokyo and work as an engineer.")
response_id = result1.raw_responses[-1].id

# Turn 2 — pass previous_response_id
result2 = await Runner.run(
    agent,
    "What city do I live in?",
    previous_response_id=response_id,
)
print(result2.final_output)  # "You live in Tokyo."
```

### auto_previous_response_id=True

To avoid manually tracking response IDs, enable automatic chaining:

```python
from agents import Agent, Runner, RunConfig

agent = Agent(
    name="AutoChainAgent",
    instructions="You are a helpful assistant.",
)

config = RunConfig(auto_previous_response_id=True)

# The runner automatically chains responses
result1 = await Runner.run(agent, "My favorite language is Python.", run_config=config)
result2 = await Runner.run(agent, "What's my favorite language?", run_config=config)
print(result2.final_output)  # "Your favorite language is Python."
```

With `auto_previous_response_id=True`, the runner tracks the last response ID and passes it automatically on the next call. No session backend needed, no history management code.

## Building a Chat Application with Server-Managed Memory

Here is a complete chatbot using server-managed conversations:

```python
import asyncio
from agents import Agent, Runner

agent = Agent(
    name="ChatBot",
    instructions="""You are a friendly conversational assistant.
    Remember everything the user tells you across the conversation.""",
)

class ServerManagedChat:
    def __init__(self):
        self.last_response_id: str | None = None

    async def send_message(self, message: str) -> str:
        """Send a message and get a response, with automatic chaining."""
        kwargs = {}
        if self.last_response_id:
            kwargs["previous_response_id"] = self.last_response_id

        result = await Runner.run(agent, message, **kwargs)

        # Store the response ID for the next turn
        self.last_response_id = result.raw_responses[-1].id

        return result.final_output

    def reset(self):
        """Start a new conversation."""
        self.last_response_id = None

async def main():
    chat = ServerManagedChat()
    print("Chat started. Type 'quit' to exit, 'reset' for new conversation.\n")

    while True:
        user_input = input("You: ").strip()
        if user_input.lower() == "quit":
            break
        if user_input.lower() == "reset":
            chat.reset()
            print("Conversation reset.\n")
            continue

        response = await chat.send_message(user_input)
        print(f"Bot: {response}\n")

asyncio.run(main())
```

## Combining Server and Client-Side Approaches

You can use both approaches together. Server-managed conversations handle the immediate multi-turn context, while client-side sessions store long-term user data.

```python
from agents import Agent, Runner
from agents.extensions.sessions import SQLiteSession

# Client-side: persistent user preferences
user_session = SQLiteSession(db_path="./user_profiles.db")

agent = Agent(
    name="HybridAgent",
    instructions="You are an assistant with both short-term and long-term memory.",
)

class HybridMemoryChat:
    def __init__(self, user_id: str):
        self.user_id = user_id
        self.last_response_id: str | None = None

    async def load_user_context(self) -> str:
        """Load persistent user context from client-side session."""
        items = await user_session.get_items(f"profile:{self.user_id}")
        if items:
            return "User context: " + str(items[-1].get("content", ""))
        return ""

    async def send_message(self, message: str) -> str:
        # Load persistent context
        context = await self.load_user_context()
        full_message = f"{context}\n\nUser: {message}" if context else message

        kwargs = {}
        if self.last_response_id:
            kwargs["previous_response_id"] = self.last_response_id

        result = await Runner.run(agent, full_message, **kwargs)
        self.last_response_id = result.raw_responses[-1].id

        return result.final_output

    async def save_preference(self, preference: str):
        """Save a long-term preference to client-side session."""
        await user_session.add_items(
            f"profile:{self.user_id}",
            [{"role": "system", "content": preference}],
        )
```

## Server vs Client-Side: When to Use Each

### Use Server-Managed When:

- **Simplicity is a priority**: No session backend to manage, no history storage code.
- **You trust OpenAI with conversation data**: The data lives on OpenAI's servers.
- **Conversations are short to medium length**: Server-managed history works well for typical chat interactions.
- **You want minimal client-side code**: Just track one ID instead of managing a full history store.

### Use Client-Side Sessions When:

- **Data sovereignty matters**: You need conversation data in your own infrastructure.
- **You need custom storage**: DynamoDB, MongoDB, encrypted storage, etc.
- **Conversations are very long**: Compaction and custom pruning strategies require client-side control.
- **Multi-agent sharing**: Multiple agents reading from the same session is easier with client-side sessions.
- **Offline or air-gapped environments**: Client-side sessions work without internet connectivity to OpenAI.
- **Audit and compliance**: Full control over data retention, encryption, and access logging.

### The Hybrid Approach

For many production systems, the best approach is hybrid:

| Concern | Approach |
| --- | --- |
| Immediate conversation context | Server-managed (previous_response_id) |
| Long-term user preferences | Client-side session (SQLite/Redis) |
| Cross-conversation memory | Client-side session |
| Compliance and auditing | Client-side session |
| Quick prototyping | Server-managed |

The two approaches are not mutually exclusive. Use server-managed conversations for the easy case and layer in client-side sessions where you need more control.

**Sources:**

- [https://openai.github.io/openai-agents-python/running_agents/](https://openai.github.io/openai-agents-python/running_agents/)
- [https://platform.openai.com/docs/api-reference/responses](https://platform.openai.com/docs/api-reference/responses)

---

Source: https://callsphere.ai/blog/server-managed-conversations-openai-conversations-api