ai_call answers each call independently
There is no history/conversation field on an ai_call step's config. Call it twice in a row and the second call knows nothing about the first, unless you explicitly build that yourself.
If you're building anything chat-like — a support widget, a follow-up-question assistant, anything where a user expects "remember what I just said" — you need one of the two patterns below. Pick based on what continuity actually needs to survive.
Pattern 1 — client-side resend
The calling app keeps the running conversation in memory and resends it on every call, as one of the ai_call step's own context fields (a text-type field, formatted as alternating turns — e.g. "Developer: ...\nAssistant: ..."). There's no special API for this: it's just another context field, the same as any other.
- Good fit: a single-page chat widget where losing history on a reload is acceptable.
- Simple to build — no new entity, no extra step.
- Downside: history only lives as long as the page does, and grows unbounded the longer the conversation runs (every prior turn gets resent, in full, every time).
Pattern 2 — entity-backed history
Create a small entity to hold the conversation:
| Field | Type | Purpose |
|---|---|---|
| session_id | string | Groups turns belonging to the same conversation. |
| role | string | "user" or "assistant". |
| text | string | The turn's content. |
| created_at | date | Orders turns correctly. |
- Good fit: continuity needs to survive a page reload, or the conversation needs to be resumable from a different device or session.
- More robust: doesn't depend on the client always resending everything correctly.
- Costs one extra step (the list_entities lookup) and one extra entity to maintain.
Which one to pick
Ask yourself: does this conversation need to survive a reload or work across devices? If yes, use the entity-backed pattern. If the whole interaction happens in one browser session and starting over on refresh is fine, client-side resend is simpler and sufficient.