AI Agent
Zeotap Agent is a conversational interface that carries out multi-step CDP work for you — building audiences, wiring up models and relationships, configuring orchestrations, and answering questions about what is already in your workspace.
Where to Find It
| Entry point | Use it for |
|---|---|
| Zeotap Agent in the sidebar | A full-page conversation with your session history beside it |
| The floating button, or ⌘J / Ctrl+J | A side panel over the page you are on, so the agent can see and act on what you are working on |
The side panel is the more useful of the two while you are mid-task: on the audience builder it opens by itself when you reach the filter step, and the filters it suggests can be applied straight into the builder. See the NL Audience Builder.
What the Agent Can Do
The agent works through the same tools the MCP Server exposes, so its reach is exactly that tool set — nothing hidden, nothing extra.
It can create and change:
- Models and schema — create models from a warehouse table or SQL, adjust columns, set sensitivity and PII types, and create relationships between models
- Audiences — build filter trees, estimate sizes before saving, and create audience canvases and publish them
- Computed attributes — define them on a parent model and refresh them
- Destinations and audience syncs — connect an audience to a destination with field mappings and a schedule, and trigger a run. When the destination does not exist yet, the agent sends you to Destinations to create it, so its credentials are never typed into a chat
- Orchestrations — create, validate, activate, pause, resume, and trigger them
- Identity graphs — create one, configure its identifiers and merge rules, set up golden records, and trigger a resolution run
- Stores — create a store, attach feeds, and refresh them
- Realtime events — declare a stream-sourced event on a parent model, edit it, and remove it
It can look at:
- Your models, relationships, computed attributes, audiences, destinations, and syncs
- Event volumes, contracts, contract violations, forwarding rules, and transformations
- Resolved profiles — look up an identifier in an identity graph, read the source rows behind a cluster, follow a relationship out from one, and explain why records merged or where a golden-record value came from
- A single model row by its primary key, and the rows related to it, in a workspace with no identity graph
- Your warehouse directly, with a read-only SQL query
Connecting a warehouse or an event source is not something the agent does. Creating one means handling credentials, so it stays a deliberate action you take under Warehouses. Once a warehouse is connected, the agent can introspect it and build everything on top.
Event configuration — forwarding rules, transformations, contracts — is read-only to the agent for the same reason: it can tell you what is configured and what is failing, but the changes are yours to make.
Using It
- Open Zeotap Agent from the sidebar, or press ⌘J to bring up the panel
- Click New Chat and describe what you want in plain language
- The agent looks around first — which models, columns, destinations and existing audiences your request refers to — and streams what it is checking as it goes
- Questions and lookups are answered straight away. For anything that would change your workspace, the agent stops and shows you a plan before it does anything
- Approve the plan, or ask for changes, and the agent carries it out and checks each result
- Keep talking to refine the result
The agent’s replies never load images: an image in a reply appears as its description, such as [image: chart]. Links in a reply stay clickable only when they point to an https:// address or to a page inside Zeotap, and an outside link opens in a new tab. Conversations with the agent are left out of product analytics and session recordings.
Approving a Plan
Zeotap Agent never creates, changes, deletes, runs or sends anything on its own initiative. However clearly you phrase the request — “create an audience of customers who bought in the last 90 days” — the agent first comes back with a plan card and waits.
A plan card collects everything the request needs into one approval:
| Section | What it shows |
|---|---|
| Steps | Every change, in order, with the names, filters, schedules and estimated sizes the agent will use. Beneath each step, in small type, the operation it runs and the values it acts on — for example the campaign it sends or the sync it starts |
| Assumptions | Anything you did not say that the agent had to decide — which model “customers” means, what counts as “high-value” |
| Impact | What happens beyond configuration: how many profiles are sent to which destination and how often, runs that start, anything that is removed |
Answer it with one of the buttons, or just reply in the chat:
- Approve — the agent carries out exactly those steps, then reads each result back and reports what it verified
- Request changes — describe what should be different; the agent revises the plan and shows it again
- Cancel — nothing is changed
Approval covers the plan as shown, and nothing more. For a step that sends, deletes, starts or publishes something, the values shown under it are enforced: the agent can carry out that step only on exactly what the card showed, so approving “send the spring campaign” cannot send a different one. If the agent later wants to do something the plan did not include — a first sync you did not ask for, removing a duplicate it noticed — it comes back with a new plan. If a step fails, it stops, tells you what was and was not done, and proposes how to continue.
When something is genuinely unclear, the agent asks before planning — all of its questions in one message, with the options it found in your workspace — rather than one question at a time. When a sensible default exists, it picks it and lists it under Assumptions instead, so one click confirms both its understanding and the plan.
Your approval and a guardrail are separate checks. Approving a plan does not bypass a guardrail: a step a guardrail holds for approval still pauses until a workspace admin approves it, and the agent tells you which steps completed and which are waiting.
Inside the audience builder, the audience canvas editor and the test scenario editor, suggestions arrive as cards you Apply to the editor yourself, so applying them is the approval there.
Example Requests
Building an audience:
“Create a high-value audience of customers who’ve spent over $1000 in the past year and sync it to Google Ads for retargeting”
Modelling:
“Make a model from the
analytics.orderstable, setorder_idas its primary key, and relate it to my customers model”
Answering questions:
“Which of my audiences have no active sync, and how large are they?”
Sessions
Each conversation is a session, listed beside the chat with its most recent message. Sessions are kept, so you can go back to one and continue where you left off.
| Action | What it does |
|---|---|
| Pin | Keeps a session at the top of the list |
| Rename | Gives the session a title of your own instead of a preview of its last message |
| End session | Closes the conversation; it stays readable |
Limits
A few limits keep one request, or one person, from running away with the agent:
- Steps per request. A single request can take up to 150 steps. Past that, the agent stops and says so. Send another message to continue where it left off.
- Time per request. A request stops automatically after 25 minutes, and a single tool the agent calls is given up to 10 minutes.
- Open conversations. You can have up to 10 conversations open at once, and a workspace up to 50. A conversation stops counting about half an hour after its last activity; going back to it counts it again. If you reach the limit, end a conversation you no longer need, or wait for an idle one to stop counting.
Your administrator can change these for your deployment.
When the agent declines
The model behind the agent has its own safety checks. If they stop a response, the agent tries once more. If the second attempt is stopped too, the agent tells you it can’t continue with the request. This sometimes happens with ordinary requests. Try rephrasing what you need, or start a new chat. Replies appear as they are written, so part of a stopped response may show briefly; it is removed as soon as the response is stopped, and it is not kept in the saved conversation. Each stop is recorded in the AI audit log.
Giving the Agent Context
Under Settings → General, Workspace context is free text — up to 4,000 characters — that is included in the agent’s prompt for every session in the workspace. Use it for the things it has no way of knowing: what your business does, which markets matter, naming conventions you want followed.
We are a DTC coffee brand. Key markets are DE and FR. Prefer concise, lowercase audience names.
Turning It Off
The agent is on by default. A workspace admin can switch it off under Settings → General, which hides it from the workspace and stops new sessions from starting. Existing conversations are kept and become readable again if it is switched back on.
Next Steps
- Guardrails — what the agent may do without asking, and what it may not
- NL Audience Builder — describing an audience and applying the result
- MCP Server — the same tools, from your own AI client