Skip to main content

Overview

The Conversational Agent is Podium’s AI-powered shopping companion engine. It gives developers two endpoints — synchronous and streaming — that turn a user message into an intelligent, context-aware conversation with access to the full commerce stack. The agent:
  • Knows the user — loads their intent profile, interaction history, and conversation memory before every turn
  • Uses tools — can search products, get recommendations, record interactions, update profiles, and create orders mid-conversation
  • Streams responses — delivers progressive text deltas, tool execution events, and product cards over Server-Sent Events
  • Remembers everything — persistent conversation history with automatic summarization keeps context across sessions
  • Is configurable — persona, tone, rules, enabled tools, and model are all overridable per request

Endpoints

Both endpoints share the same request body.

Request Schema

Synchronous Response

POST /companion/agent/chat returns a complete JSON response after the agent finishes thinking, executing tools, and composing its reply.

Streaming Response

POST /companion/agent/chat/stream returns a text/event-stream with progressive events as the agent works.

Event Types

Where spendSummary is: { dailySpent: number, dailyLimit: number, txMax: number }

SSE Client Example

Built-in Tools

The agent has access to 7 commerce tools that map directly to Podium API operations. Each tool is callable by the AI during conversation — no developer code needed.

Tool Selection

By default, all tools are enabled. Restrict the tool set per request to control what the agent can do:
This is useful for:
  • Browse-only mode: Enable only search_products and get_recommendations
  • Profile-building mode: Enable update_profile and record_interaction
  • Full commerce mode: Enable all tools including create_order

Conversational Order Flow

When a user expresses purchase intent, the agent uses a multi-turn state machine to collect the required information: The order state persists across messages, so the user can provide information across multiple turns naturally.

Memory & Context

Persistent History

Every conversation turn (user message + agent response) is stored in persistent memory. On each new message, the agent loads:
  1. Intent profile — the user’s preferences, constraints, avoidances, and behavioral signals
  2. Conversation history — recent messages (up to maxHistory turns)
  3. Conversation summary — a compressed summary of older conversations
  4. Agent state — any in-progress workflows (e.g., pending orders)
History is persisted across sessions — not just held in memory. When a user returns hours or days later, the agent has full context from previous conversations.

Automatic Summarization

Summary extraction happens automatically at conversation milestones: When summarization triggers, Podium:
  1. Generates a summary of older messages
  2. Trims the history to keep only recent turns
  3. Stores the summary for future context
This keeps the agent’s context window efficient while preserving long-term knowledge about the user.

Agent Summary → Intent Profile

Summaries are stored on the user’s intent profile (agentSummary field), making conversation insights available to other parts of the platform — recommendations, the agentic product feed, and downstream analytics. Memory is also stored as a structured AgentMemory object on the user’s profile. This structured memory — preferences, goals, concerns, avoidances, products tried, and category-aware price ranges — feeds directly into recommendation scoring, reason tag generation, and proactive nudges. See Memory & Intelligence for the full schema and scoring details.

Personas

Configure the agent’s identity and behavior per request:
Different verticals can share the same agent infrastructure with entirely different personalities and expertise.

Proactive Nudges

Beyond reactive conversations, Podium’s agent can proactively re-engage users through scheduled nudges. The nudge system runs as a background cron job and generates personalized outreach based on user signals.

Nudge Types

How It Works

  1. User selection — the system identifies users eligible for nudges based on activity signals (days since last conversation, profile completeness, recent purchases)
  2. Signal gathering — for each eligible user, the system collects their profile, loved products, recent purchases, conversation summary, and profile gaps
  3. Nudge generation — AI generates a personalized, contextual message using the user’s full signal set
  4. Delivery — the nudge is published to configured channels (Telegram, email, push) and logged
  5. History integration — nudge messages are appended to the conversation history so the agent has full context if the user replies
Nudges are logged and rate-limited to prevent over-messaging. Each nudge includes the nudgeType for analytics.

Quick-Reply Chips

The agent can suggest contextual quick-reply options to keep the conversation flowing. Chips are returned in the done event:
Quick replies are contextually generated based on: Quick replies are suggestions, not constraints — the user can always type a freeform message instead.

Durable Chat History

Conversations are persisted to durable storage. You can retrieve a user’s full chat history for display in your UI or for analytics:

Response

History is ordered newest-first. Page backward through the conversation by passing the last message’s id as the before parameter.

Purchase Mode & Spend Controls

The agent classifies each product by purchase mode, determining how the transaction is executed:

Spend Controls

For x402_platform purchases, the agent enforces spend limits to protect users: Purchase flow:
  1. User expresses purchase intent
  2. Agent resolves the product’s purchase mode
  3. For x402_platform — agent checks spend limits and emits confirmation_required with product details and current spend summary
  4. User confirms → agent executes the purchase
  5. If limits would be exceeded → agent emits spend_limit_exceeded with the reason and reset timing

First-Return Greeting

For returning subscribers, the agent can generate a personalized greeting that references their history, preferences, and recent activity. This creates a warm re-engagement experience instead of a generic “How can I help you?” Send a greeting request:
The agent uses the user’s AgentMemory to generate the greeting — referencing products they’ve tried, concerns they’ve mentioned, and goals they’re working toward. The response arrives through the standard streaming or synchronous endpoint.
Use first-return greetings when your app detects a returning user. The __greeting__ message is a special trigger — it’s not displayed to the user, it just signals the agent to generate a personalized welcome.

Example: Full Integration

Endpoint Summary