In this briefing
  1. 01Long-term memory no longer has to depend on short-term events
  2. 02Resumption, compaction and approval ownership enter the Agent SDK
  3. 03Identity routing is an adjacent runtime boundary that needs separate verification
  4. What to watch next
  5. Sources and verification
Key points
  1. Amazon Bedrock AgentCore Memory added IngestData, which can send conversations or JSON events directly for long-term memory extraction without first saving them as short-term memory events.
  2. The same-day stable releases of the OpenAI Agents Python SDK and JavaScript SDK concentrated fixes on resumed sessions, approval ownership, handoffs and concurrent writes during compaction.
  3. Claude Code subsequently fixed an identity-routing regression caused by a particular gateway environment variable; the scope of that fix is limited to the stated variable and authentication configurations, and cannot be generalised to all agent-gateway failures.
Signal 01

Long-term memory no longer has to depend on short-term events

At midnight Shanghai time on 9 September, AWS released direct ingestion for Amazon Bedrock AgentCore Memory. The new IngestData API can distribute content to configured long-term memory strategies and create long-term memory records without creating a short-term memory event. It accepts conversational payloads with USER and ASSISTANT roles as well as JSON payloads such as behavioural events, activity logs and system events, and allows metadata to be attached.

The official announcement also sets out post-processing verification paths: developers can inspect extraction results through ListMemoryRecords or RetrieveMemoryRecords, receive real-time notifications through Kinesis, and use ListMemoryExtractionJobs to find and redrive failed extraction jobs. AWS says the capability is available in every region that already supports AgentCore Memory, but the announcement does not disclose memory-extraction accuracy, deduplication performance or production latency.

What this may mean for enterprise adoption

This change allows enterprises to design short-term interaction records and long-term business memory separately instead of binding both to the same kind of storage event. A production deployment still has to define provenance, retention periods, sensitive fields, deletion propagation and duplicate-ingestion rules; the ability to write directly to the long-term layer does not mean that the content written there is correct, relevant or suitable for long-term retention.

Signal 02

Resumption, compaction and approval ownership enter the Agent SDK

Within the same observation window, OpenAI released openai-agents-python 0.22.1 and openai-agents-js 0.17.1. Both stable versions added server-wide guardrails for MCP tools and fixed the preservation of serialised approval ownership when a run is resumed, failed resumed-session writes, and approval state before a handoff. The JavaScript version also fixed Git repository argument injection in the sandbox.

The Python version additionally fixed the preservation of concurrent writes during compaction, recovery after append failures when resuming handoffs, and the case in which a run could still be resumed after its accepted terminal output had not been persisted; empty tool arguments now fail closed. The release notes describe specific changes to SDK state machines and safety boundaries, but provide no comparative evaluation of throughput, task success rates or recovery time.

What this may mean for enterprise adoption

Long-running enterprise tasks may span interruptions, human approvals, subtask handoffs and multiple context compactions. Reliability therefore extends beyond whether generation can continue: after resumption, the same approval principal must still authorise the work, writes must not be omitted or duplicated, and terminal and persisted states must agree. Recovery tests and audit records need to cover these conditions; context-window size or a single demonstration is not enough to decide whether an agent is ready for production operation.

Signal 03

Identity routing is an adjacent runtime boundary that needs separate verification

In Claude Code 2.1.266, Anthropic fixed a regression introduced in 2.1.265. According to the release note, the undocumented CLAUDE_CODE_USE_GATEWAY variable, which previously took effect only when both ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN were set, began forcing Cloud gateway sign-in on its own in 2.1.265. Configurations that set it alongside an API key, apiKeyHelper or custom authentication headers consequently failed with ‘Not signed in to the Cloud gateway’. Version 2.1.266 once again ignores the variable when it is set on its own, and requires no configuration change from users.

This fix appeared in the same release window in which the OpenAI SDK releases concentrated on session resumption and approval ownership, but the products do not share a standard. The public material also establishes no direct causal relationship between identity selection and approval or recovery state. They can only be treated as adjacent engineering boundaries that require separate testing in a long-running execution chain, and they do not show that every enterprise agent gateway has the same kind of defect.

What this may mean for enterprise adoption

Enterprise acceptance records can cover model-call identity, gateway routing, tool approvals, session writes and terminal-state persistence together, while observing interruption recovery, credential changes and configuration rollback separately. The more important boundary is that these updates show only that vendors are fixing specific engineering conditions in their own products; they do not mean that different SDK implementations already share the same consistency semantics or a common state format.

Verification

Sources and verification

  1. openai-agents-python v0.22.1OpenAI GitHub · 2026-09-08T09:18:00Z · Project release
  2. openai-agents-js v0.17.1OpenAI GitHub · 2026-09-08T10:04:10Z · Project release
  3. Claude Code v2.1.266Anthropic GitHub · 2026-09-08T23:55:14Z · Project release

Golden Data has edited this briefing from the public materials listed above. The original sources govern facts and figures. The enterprise relevance sections are Golden Data editorial analysis and do not constitute an endorsement of any third-party product.

← Back to AI Daily Briefing