Users say what they want.
The agent does it.

The Product Agent is the agent you embed in your product. It executes real workflows inside your live product, bound by the same APIs and permissions as your UI. It acts for the user: calls your actions, updates records, takes them to the right page. Or it works in tandem with them, filling a form on screen and handing control back for review. Every turn is grounded in user context, usage and knowledge.

The agent acts through actions. Each one calls your API, submits a form, navigates, or renders Generative UI in the chat. You define the description and input schema. Your code implements the handler. The handler runs in the user's browser with their session, so the agent can only do what that user can. It chains actions to finish a request, and you can require the user's confirmation before one runs.

The agent and the user work on one screen. Your app shares live UI state, like a form or settings panel, through Shared State, and the agent writes changes back. A user can fill part of a form and ask the agent to finish it, or ask for a change and watch the panel update. The agent prepares the work and hands control back. The user reviews and submits.

The context engine assembles it for each prompt. User context: who the signed-in user is, with the attributes you pass through identify(). Usage: where they are right now and what they're doing. Knowledge: your help center, docs, files, videos and glossary, which also tell the agent how to run an action the right way. User memory: what was said earlier in the conversation, so users don't repeat themselves.

The agent lives in your front end: one SDK snippet, plus identify() so it knows the signed-in user. The Agent Builder builds its actions, installed one of two ways. The Developer plugin works in your codebase: typed actions, versioned and code-reviewed like everything else you ship. The Remote plugin builds against your live product in a Chrome browser, so building changes no product code. Nothing reaches your users without your team's approval.

Yes. The Product Agent works beside your product-specific agents over A2A. It reads each agent's skills from its Agent Card, hands a task to the one whose skills match the request, and shows the result in the conversation. It can forward the signed-in user's identity with each task, and it connects up to 20 agents. Over MCP, it uses tools and data from your servers. Loosely coupled, so both sides evolve independently.

Actions call your APIs through handlers in your code, not clicks pinned to screen elements, so a redesign doesn't mean rebuilding them. If pages move, update the navigation routes the agent uses to take users there. When you ship a feature, add an action for it the way you'd add an endpoint. Every save creates a version. You publish it once the handler is deployed, and a rollback is one publish away.

Each action has evals that check real phrasings reach the right action and fill the right fields. The Playground runs whole flows against mock responses, so nothing touches live systems. To test as different users, sign in as test accounts with different roles and plans: identify() passes each one, so the agent acts with that user's permissions. Flag those sessions as test traffic to keep them out of your analytics.