cloudflare / cloudflare/agents
First-class external transcript provider for AIChatAgent
- Dominant language
- TypeScript
- Stars
- 5.6k
- Forks
- 711
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 53
Description
From our perspective, `AIChatAgent` gives us a better level of base control for this kind of product than `@cloudflare/think`. We already have our own context management, search, memory, persistence model, and product-specific chat workflow. `AIChatAgent` feels closer to the right abstraction for us.
The main issue is transcript ownership.
`@cloudflare/think` supports a custom storage/session provider, so we can make Postgres the canonical transcript store. However, Think also brings a higher-level session/context lifecycle that we may not want to adopt for every part of our system.
On the other hand, `AIChatAgent` gives us more direct control over the chat flow, but as far as we can tell it does not currently provide a first-class way to replace its internal transcript storage with an external provider.
That leaves us with an awkward tradeoff:
- Use Think to get external storage provider support, but accept a higher-level lifecycle model
- Use AIChatAgent to keep more direct control, but double-write transcripts into both DO SQLite and Postgres
For our use case, double-writing transcripts is the core problem. It creates consistency risks, complicates reconnect/retry/partial-generation behavior, and makes cross-chat search depend on a second canonical copy in Postgres anyway.
We are fine with Durable Objects storing transient runtime state, including resumable stream buffers and recovery state. We just do not want the Durable Object to also be the long-term canonical transcript database.
Would Cloudflare consider supporting a first-class external transcript provider for `AIChatAgent`, similar in spirit to Think’s storage provider model, where message history can be owned by an external database such as Postgres?
The important part for us is that the external provider would be the authoritative transcript store used by the chat protocol lifecycle, rather than just a secondary sync target.
This would let us keep the simpler `AIChatAgent` control model while avoiding permanent double storage for chat history.
Contributor guide
Assessment
This issue has not been assessed yet.