Definition: An agent session is one bounded run of work with an AI agent: it opens with nothing in it, collects every message you send and every action the agent takes inside a shared context window, and ends when you close it or start a fresh one. Anything the agent should still know tomorrow has to be written to agent memory, because the session itself does not survive.
TL;DR: An agent session is one bounded run of work: open, fill, close. Everything said and done inside it stays visible to the agent, and everything outside it is invisible unless it was saved to memory. Sessions are built from turns, and one turn is your message plus everything the agent does before handing back. Build one free →
You already work this way. A phone call with your bank is a session. It starts cold, the person on the line learns your situation as you talk, and the moment you hang up that shared understanding is gone unless someone wrote it into your file. An agent session behaves the same way: the call is the session, and the file is agent memory.
Why Agent Sessions Matter in 2026
The session is the unit that decides what an agent knows at any given moment. Models do not carry anything between requests on their own, so every request re-sends the session transcript as text. That single fact explains most of what feels strange about working with agents: why one can recall something you typed twenty minutes ago and be completely blank about the same thing in a new window, why a long conversation gets slower and pricier as it goes, and why a fresh session usually gives cleaner answers when you switch topics. It also explains where the real design work lives. If a fact matters beyond today, it belongs in persistent memory or a project, not in the chat. Teams measure this way too: agent observability counts runs and cost per session, and an agent handoff is defined entirely by what does or does not cross a session boundary.
How an Agent Session Works
A session is a growing transcript. The agent keeps no private running state between your messages. At the start of every turn it re-reads the whole transcript, decides what to do, acts, and appends the result to the bottom. The transcript is the session's memory, and it grows until the session closes or the older parts get compacted.
- The session opens empty. The only thing in it is the agent's standing instructions, its system prompt, plus whatever it pulls in from agent knowledge or a connected project.
- You take a turn. You type one message. That message is appended to the transcript.
- The agent runs its loop. It reads everything so far, decides a next step, and calls one of its tools. This is the agent loop, and it can go around several times inside a single turn.
- The turn ends. The agent replies and hands control back. Every intermediate step, including failed tool calls, stays in the transcript so the next turn can see it.
- The context fills. Transcripts have a ceiling. When it gets close, older turns are summarized or trimmed by context compaction so the session can keep going.
- The session closes. Nothing in the transcript survives unless the agent wrote it to agent memory, saved it into a project, or passed it forward through an agent handoff.
What Counts as a Turn
A turn is one user message plus everything the agent does before handing control back to you. It is not the same as one request to the model. A single turn can contain a dozen model requests and tool calls, all invisible to you, and it only ends when the agent stops and waits.
SESSION (opens empty)
│
├─ TURN 1 you: "Find the Riverside contract and summarize the renewal terms."
│ ├─ model request 1 -> decide: search for the document first
│ ├─ tool call -> search_documents("Riverside")
│ ├─ model request 2 -> read the results, pick the right file
│ ├─ tool call -> read_document(doc_113)
│ └─ model request 3 -> write the summary [hands back to you]
│
├─ TURN 2 you: "What changes if we renew for two years?"
│ └─ model request 4 -> re-reads all of TURN 1, answers [hands back]
│
└─ SESSION CLOSES transcript is gone unless it was saved
Two useful things follow. First, cost and speed track the transcript, not your last message: turn 2 above is more expensive than turn 1 even though you typed less, because all of turn 1 gets re-sent with it. Second, the end of a turn is the natural checkpoint for a person to step in, which is exactly where human-in-the-loop approvals belong.
Agent Session vs Agent Memory
People use "the agent remembers" for two different things, and the difference is what breaks expectations. A session holds the current run and disappears; memory holds what should outlive it and is deliberately written.
| Trait | Agent session | Agent memory |
|---|---|---|
| What it holds | Everything said and done in this one run | Facts, preferences, and project data worth keeping |
| Lifespan | Opens and closes with the run | Persists into every future session |
| Where it lives | In the context window, re-sent every request | Stored outside the model, retrieved when relevant |
| When it fills up | Older turns get compacted or dropped | Keeps growing, indexed and searchable |
| Cost per message | Rises as the transcript grows | Flat, because only the relevant part is retrieved |
| Best for | The task in front of you right now | Anything the agent should still know next week |
The model underneath is stateless: it starts every request from zero. The session transcript is what makes it feel stateful, and memory is what makes it feel like it knows you.
Connection to Taskade
Every Taskade AI Agent works in sessions, and what makes them useful is what sits outside the session. Your projects are the memory layer. An agent reads them when a run opens and writes results back before it closes, so the next session starts with the work already in place instead of a blank transcript. That is the Memory, Intelligence, and Execution loop in practice. Inside a session an agent can reach its built-in tools, pull data across 100+ bidirectional integrations, and route each step to the right model from 15+ frontier models from OpenAI, Anthropic, Google, and open-weight providers. Automations open their own sessions: when a trigger fires in Taskade Automations, the agent runs a full session unattended and stores the outcome in a project. For a step-by-step tour of how a chat run behaves in the product, see AI Chat in Learn Taskade, and for what an agent keeps between runs see agent memory in Taskade Genesis.
What You Would Build in Taskade
You already run something like this by hand: a shared inbox where requests arrive, someone reads each one, and the useful part gets copied somewhere it will not be lost. Picture a client intake desk in Taskade. A form drops each new request into a project. An agent opens a session per request, reads the message, checks the client's history in the same project, drafts a reply, and writes a short structured record back: who asked, what they need, what happens next, who owns it. The session then closes and takes nothing with it, which is the point. The record is in the project, visible on any of the 7 project views, ready for the next run or the next teammate. Nothing is trapped in a chat window that only one person saw. Describe yours and build it free →
Related Concepts
- The Agent Loop: what runs inside a single turn
- Agent Memory: what survives after the session closes
- Context Window: the ceiling a session grows against
- Context Compaction: how long sessions keep going
- Agent Handoff: passing work across a session boundary
- Stateless vs Stateful: why the model starts blank every time
- Human in the Loop: approvals at the end of a turn
- Agent Observability: measuring cost and quality per session
- AI Agents in Taskade: agents that read and write your projects
Frequently Asked Questions About Agent Sessions
What is a session in AI chat?
A session is one bounded conversation with an AI agent. It begins empty, accumulates your messages and the agent's actions in order, and ends when you close it or open a new one. Everything inside is visible to the agent; everything outside is not, unless it was saved to agent memory first.
What is the difference between a turn and a session?
A session is the whole run. A turn is one exchange inside it: your message plus everything the agent does before handing control back. One session holds many turns, and one turn can contain many model requests and tool calls that you never see individually.
Does an AI agent remember previous sessions?
Only what was deliberately saved. The transcript itself is discarded when the session ends. Agents keep continuity by writing facts to persistent memory or into a project, then reading them back when the next session opens. In Taskade, your projects are that layer, so a new run starts with the work already there.
When should I start a new session?
Start fresh when you switch topics. A long transcript that is full of an unrelated problem pulls the agent toward that problem and costs more per message. Starting clean gives sharper answers. Save anything worth keeping into a project first, or use an agent handoff to carry a summary forward.
Why do long sessions get slower and more expensive?
Because every message re-sends the whole transcript. The agent has no private running state, so a request in turn 30 carries turns 1 through 29 along with it. As the context window fills, compaction summarizes the older turns to keep the session usable.
How many turns can one session hold?
There is no fixed number. The limit is the total size of the transcript, not the count of exchanges, so ten turns with large documents attached can hit the ceiling faster than a hundred short ones. When the limit approaches, older turns are summarized rather than the session simply stopping.
Do Taskade agents keep working between sessions?
Yes. An automation opens a fresh session on its own whenever its trigger fires, runs the work unattended, and writes the result back to a project. You do not have to be present, and the next session you open by hand sees whatever the automated run left behind.