Skip to main content
A session is the dashboard record for a Felan request or automation run. It keeps the prompt, transcript, status, and delegated agent activity together. When a request needs shell, filesystem, repository, or browser access, Felan routes those tools into a separate agent workspace. See Security architecture for the runtime and workspace boundaries.

​
Start a session

Select New Session, enter a request under What should Felan do?, and submit it. Felan creates the session, shows startup progress, and opens its detail view. While the first response runs, Felan asynchronously creates a concise title from the initial request. Until the title is ready, or if it cannot be created, the session uses a short preview of the request as its display title. A title you rename remains authoritative, and later follow-ups do not replace it. Scheduled and event-driven sessions retain their automation or event title. Write requests as outcomes with useful constraints. For example:

​
Start a session through the API

Use a team API key to create the same kind of root conversation from an external tool:
The API returns 202 Accepted with a public session summary. The initial status is pending; poll the session detail until it becomes running or a terminal status. Session summaries contain:
  • id and lifecycle timestamps
  • kind, parent_session_id, and persona_id
  • prompt, generated title, and status
  • llm_cost_usd, num_turns, num_tool_calls, and model
Session detail adds children, containing summaries for direct delegated children. Runtime metadata, credentials, internal session keys, container identifiers, log paths, and private errors are not part of the public DTO.

​
Follow live work

The session detail view shows:
  • A title that can be renamed
  • The person who submitted the initial request
  • The current status and elapsed duration when available
  • The live transcript
  • Errors when a run fails
  • Delegated subagent activity associated with the root session
  • A Kill action while the selected session is running
Session statuses include pending, running, completed, failed, timed_out, and cancelled. Pending and running sessions can produce more work. Completed, failed, timed out, and cancelled sessions are terminal.

​
Poll session progress through the API

Use GET /api/v1/teams/{team-slug}/sessions/{session-id} for current status and direct child summaries. List sessions with GET /api/v1/teams/{team-slug}/sessions; the optional status filter accepts a session status or all, and limit ranges from 1 to 100. Read transcript events with:
Events are ordered by sequence. Both event sequences and next_cursor are decimal strings, preserving values larger than JavaScript’s safe integer range. Start without after_sequence, process the returned events, and pass next_cursor into the next request. Continue immediately while has_more is true; otherwise poll again while the session is pending or running. The transcript limit ranges from 1 to 1,000 and defaults to 100. Each event includes a sanitized raw_event projection for message and tool content. Provider, credential, request, signature, sender identifier, and repeated conversation metadata remain internal.

​
Continue the conversation

Running or completed root conversational sessions provide a follow-up composer below the transcript. Use it when the next request depends on the same conversation and workspace context. Start a new session when the work is unrelated or should have an independent history. The public API provides two different ways to influence work:
  • POST /messages adds a conversational follow-up to a running or completed main root session. It preserves the conversation and workspace context.
  • POST /steer changes the direction of a currently running target without creating a new conversational turn.
Both bodies use { "message": "..." }. Use POST /kill to request cancellation of a running target. Accepted actions return { "data": { "accepted": true, "session_id": "..." } }.

​
Repository and network context

API-created sessions inherit the team’s dashboard configuration. Felan uses the team’s connected source-control providers and authorized cloud repositories when repository work is requested. Environment settings and Private Connectivity are also inherited; configure them for the team in the dashboard before starting the session. The session create request itself contains only the prompt.

​
Session retention

Session prompts, transcripts, delegated activity, and stored session artifacts follow the team’s current plan retention window: 30 days for Individual and 90 days for Trial and Team. The window is measured from each session tree’s last activity. The complete terminal tree must be strictly older than the cutoff. Felan checks the current plan before atomically deleting the root, delegated sessions, and transcripts. Exact session-scoped Agent Storage artifacts are deleted after the database transaction on a best-effort basis. Conversation summaries, financial usage records, and unrelated team data follow separate policies. Completed database deletions are irreversible. Scheduled retention enforcement deletes eligible sessions automatically; operators can run a non-mutating report first and must monitor storage-cleanup failures. Production operation requires verified 30-day retention for the shared Axiom logging dataset.

​
Find previous sessions

The sidebar shows recent sessions. Select All sessions to open the full list, where you can:
  • Search by session title, prompt content, agent persona, or status
  • See status and last activity
  • Keep each session’s position stable while several sessions produce live activity
  • Distinguish conversational, delegated, scheduled, and event-originated work by its origin indicator
  • Open a session to inspect the transcript

Automate a request

Turn repeatable instructions into a scheduled or event-driven session.