← ClaudeAtlas

iblai-api-agent-sessionlisted

Talk to a deployed ibl.ai agent directly over REST/SSE (or WebSocket) and manage its chat sessions — POST a prompt to the agent chat endpoint, attach arbitrary metadata (surfaced later as client_context), and list/read sessions and per-task history exports. The direct-transport counterpart to iblai-api-agent-chat's MCP wiring; use when you want raw streamed chat + session records rather than an MCP server.
iblai/vibe · ★ 15 · AI & Automation · score 80
Install: claude install-skill iblai/vibe
# iblai-api-agent-session Drive a deployed agent's **chat transport directly** and read its **sessions**. Where `/iblai-api-agent-chat` wires a hosted MCP server for conversation, this skill is the raw REST/SSE (and WebSocket) surface: POST a prompt, stream the reply, attach `metadata` that resurfaces as `client_context`, and list/inspect the resulting session records. Get `IBLAI_ORG`/`IBLAI_USERNAME`/`IBLAI_API_KEY` from `/iblai-api-login`. ## Auth & conventions - **Header:** `Authorization: Api-Token $IBLAI_API_KEY` on every request. - **Path vars:** `{org}` = `$IBLAI_ORG`, `{user}` = `$IBLAI_USERNAME`. - **Two hosts — chat is streaming/ASGI:** - Chat turn (SSE / WebSocket) → `https://asgi.data.iblai.app` - Session reads/writes → `https://api.iblai.app/dm/api/ai-mentor/orgs/{org}/users/{user}/v1` … i.e. `…/orgs/{org}/users/{user}/sessions/…` - Not connected yet? Run **`/iblai-api-login`** first. ## Concepts **Two independent context fields — one soft, one hard.** A chat turn can carry both `metadata` (soft) and `document_filter` (hard); they do different jobs and don't substitute for each other: - **`metadata` (soft)** — steers *how the agent reasons*. It's appended to the prompt and persisted; it never restricts which documents RAG can retrieve. - **`document_filter` (hard)** — steers *which documents RAG may retrieve*. It's a document-level allow-list applied in the vector store; it does not touch the prompt. Passing `metadata` alone narrows nothing in retr