Integration concept

SolarflareDB for the OpenAI Agents SDK.

Keep session history for conversational continuity. Add a source-backed temporal context database for durable knowledge across users, sessions, handoffs, and agents.

Conceptual integration · official Agents SDK sessions reviewed August 19, 2026

Extend session history with durable context

The OpenAI Agents SDK supports session memory for conversation history across runs. SolarflareDB should complement that working history rather than duplicate it: use the session implementation for the ordered conversation and use SolarflareDB for extracted durable facts, entities, episodes, relationships, provenance, and temporal interpretation across sessions.

Integration statusConceptual Python adapter and tools. The prototype does not ship a production OpenAI Agents SDK package.

Expose remember and query as typed tools

Two narrowly scoped tools are enough for a first integration. remember_context accepts a durable observation plus source identity. query_context accepts the question, subject scopes, current/as-of mode, and context budget.

@function_tool
async def remember_context(ctx: RunContextWrapper[AppContext], episode: str):
    return await ctx.context.solarflare.memory.remember(
        agent=ctx.context.agent_id,
        episode=episode,
        source={"type": "session", "id": ctx.context.session_id},
    )

The application—not the model-supplied arguments—must bind tenant, authenticated user, session, and allowed scopes.

Avoid copying every session item into long-term memory

Conversation history is useful for continuity, but wholesale duplication creates token bloat and noisy retrieval. Write durable context after explicit user statements, confirmed decisions, successful tool outcomes, or a controlled extraction step. Preserve the source session item IDs so a retrieval result can point back to the evidence.

Place provenance-aware context before the agent run

The host application can query SolarflareDB before a run and inject a compact structured context block into instructions or input. Alternatively, the agent can call the query tool when the task requires memory.

Record which memory IDs and source episodes were supplied to the run. This enables evaluation of whether the retrieved context improved the outcome and supports deletion or correction tracing.

Treat memory tools as privileged data access

  • Derive tenant and subject scopes from authenticated application context.
  • Never let a prompt choose an arbitrary tenant or graph identifier.
  • Cap query complexity, result count, and context tokens.
  • Use idempotency keys for repeated handoffs and retries.
  • Log tool call, policy decision, bookmark, and selected memory IDs.
  • Use deny-wins revocation for access and keys.

See the model in motion.

Run the local product simulation or review the underlying architecture and pricing proposal.