Imagine comparing two events inside an AI conversation. You change the time filter, remove one event, and ask, “Which of these leaves enough time for dinner?” The panel shows your new shortlist. The assistant answers about the old one. Every individual control may be working; the two interfaces are working from different state.
Disclosure: An AI agent researched and drafted this article from my public project documentation and the linked MCP sources. The example and state-synchronization design below are illustrative recommendations, not a report of a defect or a claim about undocumented implementation details.
My AfroTech Guide case study describes a community-built public guide and a connected AI experience for discovery, comparisons, planning, and editable introduction drafts. Its MCP App UI lets supported hosts display structured records and plans. Public website features and connected AI features have different release scopes, and real-device and host acceptance remain separate checks.
That combination makes an easily missed product question concrete: after someone changes an interactive panel, what does the assistant know when the conversation continues?
An interactive result creates another source of context
The MCP Apps specification, marked stable on January 26, 2026, defines an optional extension for interactive interfaces delivered through MCP. This is an ongoing shift toward tools people can manipulate inside a conversation, rather than a newly announced release this week.
A user can now express intent in two places: a message and a control. Selecting a record, changing a filter, or clearing a shortlist can change the meaning of the next sentence without adding a new chat message.
For an event planner, “these” might mean the selected cards, the visible search results, or the events already saved to a plan. Those are different sets. A useful interface should make the active set visible and carry that meaning into the context supplied to the assistant.
I would start with an explicit definition for each view. A comparison panel could treat “these events” as the selected record IDs. A search panel could describe its visible results and filters while saying that nothing is selected. If the product cannot resolve the reference reliably, asking which set the user means is better than guessing.
Publish a coherent snapshot after a committed change
The SDK's updateModelContext documentation describes making app state available for future model turns without immediately triggering a response. It also says that typically only the latest update is sent, with each update replacing the previous context.
That behavior has a practical consequence: a sequence of tiny updates should not be treated as an event log the model is guaranteed to replay. Sending “removed event A” followed by “changed time filter” may leave the later context without enough information to reconstruct the shortlist.
For this hypothetical planner, I would publish a compact snapshot containing the view name, current filters, selected IDs, brief labels for those IDs, and a local state revision. Include the selected count as a convenience, while keeping the IDs available to resolve the records. Clearing the selection should publish an explicit empty selection.
Send the snapshot after the application has accepted the change into its own state. A pending search should be described as pending. Otherwise the assistant may receive new filters paired with results from the previous request.
The snapshot need not contain every record on the screen. It should carry enough meaning for the next question and identifiers for fetching details when needed. Smaller context can reduce unnecessary payload, but token and latency savings should be measured in the actual host workflow.
Make late results and failed updates visible
Suppose the user quickly chooses a morning filter and then an afternoon filter. The morning request finishes last. If the application accepts every response in arrival order, both the panel and the assistant's context can regress to a view the user already replaced.
I would associate each request with the state revision that created it and reject a result that no longer belongs to the active view. This is a proposed application design, not an automatic guarantee supplied by MCP.
Context delivery also needs its own failure handling. The SDK documents acknowledgment, rejection, timeout, and connection-loss outcomes. An acknowledged update is still different from observing a correct answer on the next turn. Test both the delivery path and the resulting conversational behavior.
If delivery fails, keep the local selection intact and make the limitation visible. An application can offer a retry or a concise way to restate the selection. Silently pretending that the assistant received the change leaves the user with no way to understand an outdated answer.
Keep selecting, discussing, and saving separate
A person choosing three cards has expressed an interest in discussing them. That interaction alone should not be described as a saved itinerary, an RSVP, or permission to contact someone.
The distinction fits the documented guide: record identity carries into plans, and a save is only described as complete after backend confirmation. The product also keeps editable introduction drafts separate from sending messages. A context snapshot should preserve these differences, for example by identifying a shortlist as unsaved.
I will discuss the build behind this independent guide in Building AfroTech.guide, listed on my official AFROTECH speaker profile. The project is community-built; that speaking engagement does not make the guide an official conference service.
For testing, exercise the second turn after changing a filter, clearing a selection, receiving a late result, and reconnecting. Check what the assistant refers to, and whether its account of saved state agrees with the backend. Passing a render test alone cannot establish that the conversational handoff works.
This matters wherever interactive AI panels support comparisons: directories, catalogs, dashboards, and planning tools. Each visible change can alter the user's next question. Treating that handoff as part of the interface gives people a conversation that follows their decisions instead of making them narrate every click.
Top comments (0)