A one-off model call is enough for a short transformation. A useful assistant often needs more: it should be able to answer a follow-up in the context of the same task. IaGenify SDK sessions give those calls a shared home, so the application can keep the conversation together instead of rebuilding it from scratch each time.
Create an assistant once, then continue the thread
An assistant session starts with a model and its settings. The application can provide a role, instructions, an optional output schema and a memory preference. It then calls `generate()` as the conversation progresses.
const assistant = await api.models.create({
model: "your-model",
settings: { role: "Research assistant" },
memory: true,
});
const first = await assistant.generate({
inputs: [{ type: "text", content: "Summarize this topic." }],
});
const followUp = await assistant.generate({
inputs: [{ type: "text", content: "What should I read next?" }],
});The second call belongs to the same assistant. The application does not have to treat it as an unrelated request or manually concatenate every previous message into each new input. That makes multi-step tasks easier to express and gives the SDK a clear place to manage context.
Memory stays an application choice
Not every call should retain a conversation. A title generator or a translation may be intentionally stateless; a support conversation or a research thread may benefit from continuity. The `memory` option lets the application choose that behavior when it creates the assistant.
The session model also gives applications a consistent way to think about model and agent conversations. A session has an identity, context and a sequence of turns. The interface can show or manage that work as a conversation, and a program can continue it with a later call.
Context without carrying the whole transcript everywhere
As a conversation grows, forwarding the complete transcript on every request becomes cumbersome. A session gives the platform a stable place to associate its turns and apply the context rules for the next response. Applications can focus on the current input and the result they need.
That does not mean memory should be invisible. Developers still decide whether the assistant has memory, what information they send and when a new conversation should begin. The session is a mechanism for continuity, not a substitute for deciding what context belongs in an interaction.
A foundation for longer-running work
Persistent sessions make it possible to build on earlier turns: ask a clarifying question, revise an answer, or continue a task later. They also give a product a stable unit to associate with its conversation history, rather than leaving all continuity to an open browser tab.
A conversation is useful when the next turn can build on the last one, and the application stays in control of what should be remembered.
This session foundation arrived early in the SDK's development and remains central to the experience: assistants are not just prompts sent to a model, but ongoing interactions that an application can shape and continue.
Frequently asked questions
What is an assistant session?
It is a model resource with its settings and a place for related generation calls to share context.
Is memory always enabled?
No. The application selects whether to enable it when creating the assistant.
Do I need to resend every previous message?
The session lets related calls continue together, so application code does not need to rebuild the full transcript for each follow-up.
Should every model call use memory?
No. Use it for interactions that need continuity; stateless transformations can remain independent.