How to Build Long-Running GPT-6 Astra Agents with Conversation State and Compaction

A long-running agent is not merely a chatbot with an enormous transcript. It is a stateful system that must preserve goals, completed work, tool results, permissions, and unresolved decisions while staying inside a finite context window. GPT-6 Astra provides a 1,050,000-token context window, persisted reasoning support, conversation state, and compaction—but architecture still determines whether a workflow remains coherent after hours or days.

Separate four kinds of state

Treating every event as conversation text makes recovery difficult. Maintain distinct layers:

1. Dialogue state: what the user and model said.
2. Task state: goals, plan, constraints, completed steps, and blockers.
3. World state: records in databases, files, tickets, and other external systems.
4. Execution state: tool call IDs, idempotency keys, approvals, retries, and checkpoints.

Only the first layer naturally belongs in a transcript. The other three should have application-owned representations. The model can help update them, but it should not be the sole system of record.

Two ways to continue a response

The simplest continuation mechanism is previous_response_id:

const first = await client.responses.create({
  model: "gpt-6-astra",
  input: "Draft an implementation plan for the migration."
});

const next = await client.responses.create({
  model: "gpt-6-astra",
  previous_response_id: first.id,
  input: [{ role: "user", content: "Start with the authentication module." }]
});

This creates a response chain. It is convenient for a session, but it is not a billing shortcut: OpenAI documents that prior input tokens in the chain are billed as input. Responses are stored for 30 days by default unless store: false is used.

For durable threads, use the Conversations API. A conversation can contain messages, tool calls, and tool outputs and can be reused across sessions, devices, or jobs. Conversation objects are not subject to the 30-day response TTL. A request cannot use both a conversation and previous_response_id; choose the state model deliberately.

Make a context budget before you need one

Context includes input, output, and reasoning tokens. Do not wait until the model hits the limit. Reserve space for the next tool result and final answer, then compact or prune before crossing your threshold.

A useful budget can allocate percentages to:

• durable instructions and tools;
• current task summary;
• recent conversational detail;
• retrieved evidence;
• expected reasoning and output;
• an emergency margin for unusually large tool results.

Large context also has pricing implications. The GPT-6 Astra model page documents a higher rate for requests whose input exceeds 272K tokens, applied to the entire request. That threshold makes early context hygiene financially important even when the full window is far from exhausted.

What compaction does

Compaction reduces prior context while carrying forward the information needed for future turns. OpenAI exposes an explicit /responses/compact endpoint and automatic context management. The returned compaction material is opaque: pass it forward as instructed rather than parsing it, editing it, or treating it as a user-facing summary.

Compact at semantic milestones:

• after research is synthesized and raw source exploration is no longer needed;
• after a code phase passes tests;
• after the user approves a plan;
• before starting a new independent phase;
• when measured context approaches your planned threshold.

Avoid compacting after every turn. It adds work, can discard useful local detail, and changes the reusable prompt prefix, which can affect prompt-cache behavior.

const compacted = await client.responses.compact({
  model: "gpt-6-astra",
  input: accumulatedItems
});

// Persist the returned compacted items and use them as the base for later work.

Use the current SDK reference for exact types; beta and SDK surfaces may evolve. The durable rule is to preserve the opaque output unchanged.

Checkpoint the work, not just the words

A production checkpoint should record:

• user-visible goal and latest accepted scope;
• completed steps and verification evidence;
• pending tool calls and approval state;
• external resource identifiers and versions;
• important decisions with provenance;
• the response or conversation identifier;
• a monotonic checkpoint version.

Suppose an animation workflow has approved a script, generated character references, and begun scene assembly. The agent should store asset IDs, approvals, and scene status in application data. A platform such as Elser AI is a natural destination for creative assets, but the orchestration layer still needs explicit state so a resumed agent does not regenerate approved scenes.

Recovery after interruption

Design for at-least-once execution. A connection can disappear after a tool acted but before the client received the result. Every state-changing tool should accept an idempotency key or support a read-before-write check. On resume:

1. load the latest committed checkpoint;
2. inspect external state for uncertain operations;
3. reconcile tool results by call or idempotency ID;
4. rebuild the context from compacted state plus recent events;
5. ask the model to continue from explicit pending work.

Never tell the model “continue” with no structured status after a crash. It may repeat actions or infer the wrong milestone.

Keep compaction and business memory separate

Compaction is optimized context for the model. Business memory is a durable, inspectable record for your application. Maintain a concise human-readable task ledger alongside opaque compacted items. The ledger lets operators audit decisions, migrate models, and recover if a response chain is unavailable.

A good ledger contains facts, not persuasive prose. For example: “Customer approved plan v7 at 14:32 UTC” is stronger than “The customer seemed happy with the plan.” Store source IDs for claims drawn from tools.

Quality controls for long runs

Test more than final-answer accuracy. Measure:

• goal retention after 20, 50, and 100 turns;
• duplicate side effects after injected disconnects;
• correct resumption after compaction;
• tool-result provenance;
• authorization persistence and expiry;
• cost per milestone;
• drift between the task ledger and external state.

Include adversarial tests where an old message conflicts with a newer instruction, a tool returns a huge payload, or an approval expires while the agent is paused. Long-running reliability is mostly about transitions.

FAQ

Should I use Conversations or previous_response_id?

Use previous_response_id for straightforward response chaining. Use a Conversation when you need a durable object reused across sessions or jobs. They cannot be supplied together in the same request.

Does a one-million-token window eliminate compaction?

No. Cost, latency, relevance, and the documented long-context pricing threshold all make context management useful before the hard limit.

Can I edit compacted content?

Treat compacted items as opaque. Keep your own editable task ledger separately.

What does store: false change?

It disables the default storage of the response. Your application must then carry the needed state explicitly and satisfy its own retention and recovery requirements.

Conclusion

Durable GPT-6 Astra agents combine API-managed conversation continuity with application-owned task and execution state. Chain or persist responses deliberately, budget context before it becomes expensive, compact at milestones, preserve opaque compaction items, and make every external action recoverable. The result is an agent that can resume work safely—not one that merely remembers a long chat.