Campaign Context Preparation — high-level customer experience consent
The high-level, least-privilege customer-experience and campaign consent loop that enables external brand agents to securely discover and request user context without exposing raw user data.
TL;DR: The high-level campaign context protocol allows external brand-side agents to request scoped user context based on explicit campaign goals, automatically discovering valid domains, reusing existing grants, and returning only encrypted exports without exposing plaintext.
Status as of 2026-06-15: see body.
Relations
- PCHP — the core consent handshake layer that this loop wraps.
- Consent Reverse-Auction — how priced bids ride alongside campaign context requests.
- Hermes Agent — the runtime that executes campaign-context queries.
1. High-level customer experience loop
As the agent-native Intention Economy matures, brands and advertisers need a secure, non-intrusive way to personalize interactions without harvesting raw user data or bombarding users with endless consent popups. The Campaign Context Preparation loop solves this at the protocol level.
Instead of forcing an external agent to coordinate multiple low-level consent queries, the high-level prepare_campaign_context tool exposes a single atomic entry point for external ads, campaign, and customer-experience (CX) agents. By declaring a plain-English campaign goal (e.g., "personalize travel experiences for someone considering a trip"), the protocol autonomously discovers, checks, and requests consent on a least-privilege basis.
2. Core architectural mechanics
The high-level campaign preparation process consists of four automated steps executed behind a single trust boundary:
Step A: Autonomous domain discovery
The protocol checks which user-side data domains exist (such as Having.vehicle, Wanting.travel, or Acting.finance) without reading their contents. This preserves user privacy while revealing what context is available.
Step B: Least-privilege scope selection
Based on the stated campaign_goal and any optional preferred_context hint, the tool maps the goal to the minimum necessary data scope. For example, a trip personalization goal maps to attr.shopping.receipts_memory.* rather than highly sensitive financial analysis fields.
Step C: Active grant reuse and polling
If the user has already granted consent for the chosen scope, the protocol immediately returns the approved state. If no grant exists, it initiates a new pending consent request and performs brief, bounded polling (up to 90 seconds) to allow the user's agent (Nav or One) to approve or decline the request based on their personal policies.
Step D: Cryptographic export delivery
Once approved, the tool fetches the metadata for the encrypted export. The protocol never returns plaintext user data or raw ciphertext. Instead, it delivers a secure, wrapped key bundle. A local connector holding the user's private key must decrypt the payload locally before producing recommendations, ensuring Hussh remains a zero-knowledge exchange.
3. Comparative positioning
| Dimension | Low-level consent tools | Prepare Campaign Context |
|---|---|---|
| Complexity | Multiple calls (discover → request → poll → export) | Single atomic call |
| Scope Choice | Explicitly declared by caller (risk of over-privilege) | Autonomously selected on least-privilege mapping |
| Consent Fatigue | High (prompts user for every separate resource) | Low (resolves and reuses active grants atomically) |
| Privacy Gate | Returns raw tokens or payloads if queried | Strictly returns metadata; requires local decryption |
Sources
- (none — synthesis only)