Memory and scheduling

Two runtime capabilities make agents useful beyond single questions: memory, which keeps conversations coherent and lets agents accumulate knowledge, and scheduling, which lets agents run recurring work without anyone prompting them.

Conversation sessions

Every conversation with an agent is a session. The runtime persists session state automatically, so a multi-turn exchange — over chat, a channel like Slack, or a workflow — picks up where it left off, even across agent restarts or multiple replicas of the same agent.

Two housekeeping behaviors are worth knowing:

• Sessions expire when idle. A session untouched for a while (about 30 minutes by default) is discarded, and the next message starts fresh. This is deliberate: it prevents a session polluted by accumulated errors from degrading the agent indefinitely.
• Long conversations are compacted. When a conversation approaches the model's context limit, the runtime summarizes the oldest half of the exchange and continues with the summary in place of the raw messages. The agent keeps the gist of earlier turns without hitting a hard wall.

Long-term memory

Optionally, an agent can be given long-term memory that persists across sessions. When enabled:

• Knowledge distilled during conversations (including content flushed during compaction) is written to the agent's memory store.
• The agent gains memory_search and memory_get tools, letting it recall relevant facts from past sessions using combined semantic and keyword search, with newer memories weighted above older ones.

This turns an agent from a stateless responder into one that improves its context over time — for example, remembering the conventions of a system it has triaged before.

Scheduled runs

Agents can execute tasks on a recurring schedule — a daily report, an hourly check, a weekly summary. A schedule pairs a cron-style expression (@daily, @hourly, every 15 minutes) with a task prompt, and optionally a delivery destination so results post to a channel like Slack or Telegram when the run completes.

Schedules come from two places:

• Configuration — defined when the agent is set up, as part of its deployment.
• The agent itself — agents have built-in schedule tools, so a user can say "check this every morning and post the result here" in a conversation, and the agent creates the schedule, capturing the current channel as the delivery target. Agents can also list and remove the schedules they created (configured schedules cannot be deleted by the agent).

Scheduling behavior

• No overlap — if a run is still in progress when the next trigger fires, the new run is skipped rather than stacked.
• Durability — in platform deployments, schedules are backed by the cluster's native job scheduling, so they survive agent restarts.
• Traceability — every fire, completion, and skip is emitted as an audit event (for example schedule_fire and schedule_complete), so scheduled activity is as observable as user-driven activity.