Providing Context to Your Agent

Before your agent meets a participant, it needs the same briefing any good human would want: what the business does, how it speaks, what's going on right now, and whatever you already know about the specific person on the other side. The quality of every conversation rests on that context.

Perspective gives you three places to put it.

Outline Knowledge – Everything that's true of every conversation: what the business does, brand voice, pricing, policies, product facts. Set once, at design time, and it applies to every participant.

URL parameters – Lightweight per-link signals appended to the invite URL, like campaign source or plan tier. Read automatically when the participant opens the link.

Invite context – Richer per-participant information attached to a specific invitation, like CRM attributes or a reference to a previous conversation. Stays server-side; never appears in the URL.

Most of the work lives in Knowledge. URL parameters and invite context handle the per-conversation details on top.

Start with Knowledge#

Knowledge is the single biggest lever you have on conversation quality. It lives in the Agent tab of your Outline, and it's the first place to look when the agent isn't saying what you'd want it to say.

Think of Knowledge as the briefing document you'd hand a new teammate before their first customer call. The more the agent knows about your business, the more naturally and accurately it can speak for you.

You don't edit Knowledge by hand. The design agent generates it when your outline is first created, and updates it whenever you ask for a change. You can feed it context in three ways:

• Point it at a website – Share a URL and the design agent pulls what's relevant into Knowledge (company description, pricing page, policies, FAQs).
• Upload documents – Product briefs, brand guidelines, pricing sheets, internal FAQs. The design agent reads them and lifts the salient facts into Knowledge.
• Just describe it – "Add our refund policy: refunds within 30 days, no questions asked." "The agent should know we're HIPAA-compliant and mention it when clinics ask about security." The design agent updates Knowledge in place.

Every refinement generates a new outline version, so you can see exactly what changed and when.

Typical things to put in Knowledge:

• What the business does – The product, who it's for, the core value proposition.
• Brand voice and tone – Formal or casual, words and phrases you use, the ones you avoid.
• Opening hours and availability – When support is live, when the team is off, what happens outside hours.
• Pricing and plans – Tiers, what's included, how to upgrade, what changed recently.
• Policies – Refunds, cancellation, data handling, SLAs — anything the agent might be asked about.
• Product facts – Current features, recent releases, known limitations.
• Context about the space – Industry background, competitors, typical customer situations.

Example — a Knowledge entry for a SaaS support conversation:

#### About usWe're Acme, a B2B scheduling tool for small clinics.Customers are usually office managers, not doctors.
#### Brand voiceWarm, plain-spoken, never salesy. We say "book"not "schedule", and "your team" not "your users".Avoid emojis and exclamation marks.
#### Support hoursMon–Fri, 8am–6pm ET. Outside those hours, promisea response within one business day.
#### Current pricing- Starter: $19/mo, up to 3 seats- Growth: $49/mo, unlimited seats, SMS reminders- Enterprise: custom, with SSO and HIPAA BAA

With this in place, the agent can answer pricing questions accurately, match your tone, and set the right expectations about response times — without the participant having to ask.

Guidelines shape how the agent behaves; Knowledge gives it the facts to behave well with. If the agent drifts off-brand or sounds generic, the fix is almost always to extend Knowledge, not to rewrite Guidelines.

See the Conversation Outline guide for a full tour of every outline field.

Add Per-Conversation Context with URL Parameters#

When you're sending the same link to many people but want the agent to know something different about each one — the campaign they came from, their plan tier, an A/B variant — append that information to the invite URL as query parameters.

https://perspective.ai/interview/abc123?plan=enterprise&source=newsletter

When the participant opens the link, the agent receives plan: enterprise and source: newsletter as context for this conversation. It can reference them naturally ("As an enterprise customer…") or use them to prioritize which topics to explore.

URL parameters are the right tool when the information is:

• Available to you at link-generation time – You're merging values into the URL from your email platform, CRM, or in-app invite flow.
• Lightweight – Short strings like a tier, role, campaign, or variant ID.
• Non-sensitive – URLs show up in browser history, server logs, and referrer headers. Don't put anything confidential in them.

Values are limited to 50 characters each. A small set of parameter names — name, email, invite, embed, and others that control the interview experience itself — are reserved by Perspective and aren't forwarded to the agent.

See URL Parameters for deeper use cases and worked examples.

Use Invite Context for Per-Participant Details#

When you're inviting specific people rather than sharing a public link, you can attach a block of context to each individual invitation. That context stays server-side: it never appears in the URL, can't be edited by the participant, and can hold substantially more information than a URL parameter.

Invite context is the right tool when the information is:

• Unique to this participant – CRM attributes like role, tenure, last-renewal date, or account health.
• A reference to past interactions – A short summary of an earlier conversation so the agent can pick up where it left off.
• An entitlement or account flag – is_power_user, has_seen_beta, billing state.
• Too long for a URL parameter, or confidential – Invite context allows up to 2000 characters per value.

Because context is bound to a specific invite, you can send a different conversation to every participant — one framed around their actual situation — without generating separate public links for each one.

See Inviting Participants for how to attach context when creating invitations.

Which One Should I Use?#

A single rule of thumb covers most cases:

• Same for every participant? → Put it in Outline Knowledge.
• Different per participant, with a specific invite for each one? → Put it in invite context.
• Different per link, distributed publicly or through a campaign? → Use URL parameters.

The three combine freely. A typical research conversation has product knowledge in the Outline, campaign source in the URL, and CRM attributes in the invite — all feeding into the same agent.

Best Practices#

Start with Knowledge. Generic or off-brand answers almost always mean Knowledge is under-filled, not that Guidelines need tweaking.

Keep Knowledge factual, not instructional. Facts about the business go in Knowledge. How the agent should behave goes in Interview Guidelines.

Don't repeat shared context in URL parameters. If every participant needs the same product background, putting it on the URL is a symptom of missing Knowledge, not a fix.

Never put secrets in URL parameters. URLs end up in browser history, analytics, and server logs. Anything confidential belongs in invite context or the outline.

Reach for invite context when a URL parameter would exceed 50 characters — or when the participant shouldn't be able to edit the value by rewriting the link.

Pick one home per key. If the same key appears in both the URL and invite context, invite context wins — but relying on that precedence is brittle. Decide up front where each key lives.

Test with realistic values. Open a preview link with representative URL parameters and, if you're using invites, send yourself a test invite with a realistic context payload before launching.

Common Pitfalls & Fixes#

Agent gives generic answers → Knowledge is under-filled. Add specifics about the product, pricing, voice, and policies the agent should speak from.

Agent repeats information participants already shared elsewhere → Pass what you already know as a URL parameter or invite context value. The agent will skip past it instead of asking.

Context the participant shouldn't see is visible in the address bar → Move it from URL parameters into invite context. The URL only carries a signed invite token, never the context itself.

URL parameter value truncated unexpectedly → Values are capped at 50 characters. Move longer values into invite context.

Same key set in two places with different values → Invite context wins over URL parameters. Standardize on one source of truth per key rather than relying on precedence.

Expected parameter doesn't reach the agent → Check the parameter name against Perspective's reserved keys (name, email, invite, embed, and other experience controls). Reserved names are consumed by the platform and not forwarded.

Availability#

Every Perspective AI conversation uses these three context sources — Outline Knowledge is available to all customers, URL parameters work on every invite link, and invite context travels with every invitation you create.