The same button, two different answers
The product in question is an app for event organizers — weddings, parties, corporate events — where each event becomes its own record: schedule, budget, contacts, and finances. An assistant button is always visible, but it answers in two different ways depending on where it was triggered. Called from the general list of events, it sees everything the user has in progress — "what payments do I have pending?" adds up what's open across all events. Called from inside a specific event, the same question already comes filtered — "how much is left to pay the caterer?" knows, without needing to ask, that the caterer belongs to that event.
It sounds like a small detail, but it's the difference between an agent that helps and one that forces the user to do the work of providing context every time they ask something. Defining the scope by the screen the button lives on — instead of requiring the user to pick an event before being able to ask — is a product decision, not just a prompt one.
A suggestion is a draft, never an automatic action
The same agent also generates an initial schedule from the event type and date, flags budget items that tend to be missing for that size of event, and drafts a payment-reminder message to a vendor based on the contact and the outstanding balance. In none of these cases does the agent act alone: the suggested schedule needs to be confirmed item by item, and the reminder message is left ready for review — the user is always in control. An agent that directly executes whatever it "thinks" it should do fails fast and too expensively to operate without that guardrail.
When the product has a built-in commercial partner, the boundary has to be in the design
This specific app is sponsored: a partner company integrates its product catalog into the organizer's flow, and in exchange receives leads and usage metrics. The point that matters here isn't the sponsorship model itself — it's where the privacy boundary is drawn. The partner only receives a lead when the user themselves clicks "request a quote", and only sees aggregated metrics (most-searched category, city, month), never individual data about anyone's budget, contacts, or notes. This isn't a policy written on the side — it's a rule that lives in the data model and the API: the route that returns metrics simply doesn't respond below a minimum count, so no one can be re-identified by exclusion. In any product with an embedded third party — sponsorship, marketplace, partner catalog — that boundary needs to be in the architecture, not in the good will of whoever operates the partner dashboard later.
Where to start
The most common mistake when putting an AI agent into a product is treating it as just another screen — a generic chat dropped in a corner, with no sense of where the question came from or what it can do on its own. The approach that works is designing the scope before the prompt: where the button lives on each screen, what the agent can answer there, and what always needs to go through user review before becoming an action. Only after that does it make sense to discuss the model, cost per call, and latency.