The map is part of the prompt

Consider a synthetic interaction: a traveler moves the map to Bologna and asks, “Show me good restaurants around here.”

The words alone do not contain the destination. The map does.

If the assistant ranks results near the person's physical location instead, the search can be technically successful and completely useless. The failure is not language understanding or place data. It is disagreement between two parts of the interface about what “here” means.

In a map-based travel product, the map is part of the prompt.

Interaction state carries meaning

Travel questions often contain references that depend on the current screen:

• “Around here” refers to the visible map area or selected place.
• “Add this” refers to the active result or pin.
• “Is this too far?” depends on the current day and its other stops.
• “What should we do next?” depends on route order and time.
• “Search near Day 4” refers to that day's geographic base, not the device location.

The system needs a bounded interaction context that resolves those references. Useful fields can include the selected entity, map center and bounds, current trip or collection, active day, route segment, and the action the user can perform.

That packet should contain stable identifiers and coordinates rather than screenshots or arbitrary browser state. The backend must still verify that every referenced object is accessible to the current user.

Viewport intent and physical location are not interchangeable

Device location answers “Where is this person now?” Map center answers “Which area are they currently exploring?”

Both can be useful, but they represent different intent.

An explore search should normally favor the current viewport when the traveler deliberately moved the map. A near-me request can explicitly select physical location. A trip-day search should favor the day's route or overnight base. Falling back between them silently creates surprising results and can reveal more location context than the task requires.

The interface should make the active search area visible and offer a familiar recenter control. The assistant should not infer that every map movement permanently changes the trip or the user's saved preferences.

Geography should constrain generation

A model can suggest that two attractions belong together. Coordinates and route evidence can test whether that suggestion is geographically sensible.

Platix uses geographic bases to connect route planning, place research, and day scheduling. Candidate places are searched within a bounded area around the relevant day. Results outside that scope can be rejected or penalized. Activity ordering can be checked for material backtracking rather than relying only on the model's familiarity with place names.

This is especially important when names are ambiguous. A city, station, neighborhood, and attraction can share similar labels. Provider-backed identity and coordinates give the map and itinerary one object to discuss.

The model proposes relationships. Geographic evidence keeps those relationships anchored.

A route line is a claim

Drawing a line between pins looks simple. It can imply several different things.

A straight line shows geographic order, not a drivable route. A polyline from a route provider may represent a particular mode and set of conditions. A connection between overnight bases may show itinerary sequence without describing the transport the traveler will actually take.

The product should label these distinctions honestly. It should not describe a geometric line as current transit guidance or use one distance value for every mode.

Missing route evidence should remain visible as missing. The map can still show ordered stops while the itinerary asks the traveler to confirm the transfer.

Chat and direct manipulation must update one state

A traveler can change a trip through chat, drag and drop, a day editor, or the map itself. Those interactions should converge on the same structured graph.

If chat moves a stop but the map still uses an old local array, the route and itinerary disagree. If dragging a day updates the screen before persistence and then jumps back, the interaction feels unreliable. If selecting a map pin does not update the agent context, “tell me about this place” becomes ambiguous.

Optimistic UI can make direct manipulation feel immediate, but it needs rollback on failure and reconciliation with the authoritative backend version. Agent changes should follow the same mutation and version rules as manual changes rather than maintaining a parallel representation.

The map is a view of the trip, not a second trip.

Mobile changes the interaction contract

On a desktop, a map, itinerary rail, place panel, and chat can remain visible together. On a phone, those surfaces compete for the same screen.

A mobile design often uses sheets and explicit modes. The selected day or place must remain clear when the map is partially covered. Controls should preserve space for the primary travel task rather than reproduce every desktop editing tool at a smaller size.

The underlying context contract should stay the same. A search from the mobile day sheet and the corresponding desktop day should send the same day identity and geographic anchor. Responsive layout should not create a different planning policy by accident.

Location context needs privacy boundaries

Map interaction is useful analytics and sensitive behavior.

The agent needs current geographic context to answer the request. That does not mean every pan, zoom, center coordinate, or physical location must become durable user history. Operational context can remain ephemeral. Product analytics can use bounded event categories and coarse, necessary descriptors rather than a replayable location trail.

Physical location should be requested only for a feature that clearly needs it. A traveler exploring Italy from home should not have home location override the destination visible on the map.

Access control matters too. A marker for a private stop or collection cannot become visible merely because another user asks about the same area.

Test words and gestures together

Map-agent tests should cover the combined interaction:

• Move the viewport, then search “around here.”
• Select a pin, then ask a pronoun-based question about it.
• Switch days and verify that search follows the new day base.
• Recenter after exploratory map movement.
• Draw ordered stops with and without provider-backed route geometry.
• Edit through chat and confirm that map and itinerary update together.
• Deny access to private markers and unauthorized entity identifiers.
• Repeat the same cases across desktop and mobile context packets.

Testing the search endpoint alone cannot detect a stale selected place in the browser. Testing the map alone cannot detect a backend that discarded the viewport context.

The durable lesson

Maps are not decoration around a travel assistant. They express selection, proximity, route order, and the area the traveler is thinking about.

Treating map state as bounded, authorized input allows language and geography to reinforce each other. Provider evidence anchors names and routes. One structured trip graph keeps chat and direct manipulation aligned. Privacy rules prevent useful context from turning into unnecessary location history.

When the traveler says “here,” the whole system should agree on where that is.