An assistant feels useful before its final answer arrives when it shows what has actually happened: records found, a check completed, a decision waiting for approval. To build that experience, distinguish the agent's events from the connection carrying them to the browser.
LangChain and Databricks AppKit overlap, but “which one does SSE?” is too narrow a choice. Start with the runtime your workflow needs, then define the progress contract your interface can trust.
A useful stream tells the user what changed and what happens next.
THE CONNECTION IS NOT THE RUN
What survives a disconnect?
Follow one illustrative refund from progress to recovery.
The refund finished. The screen missed it.In this example, the application recorded completion before the connection dropped. A lost SSE response does not tell the browser whether the operation succeeded.
Explanation and primary sources
Read the lanes from agent to application to browser. The application checks access and records run state. Approval is a separate authenticated request. The disconnect example assumes that completion was recorded before the SSE connection dropped. Recovery reads the recorded run without blindly repeating the refund. These are illustrative application event names, not LangChain or AppKit API names. LangChain supplies agent events; AppKit also includes an app server and agent hosting, with the agents plugin in beta. Persistence and recovery must be implemented by the application.
Reviewed 22 September 2026 · Illustrative design, not a client result.Three responsibilities in one screen
The agent runtime produces updates. Your application decides which updates the user is authorised to see and translates them into product meaning. Server-sent events, or SSE, carry those messages over an HTTP response to the interface.
LangChain streaming exposes agent progress, model message chunks and custom updates. Those are useful inputs to an application. A Python iterator alone does not define your browser endpoint, access policy or reconnect behaviour.
AppKit's architecture includes a Node.js server, Databricks integrations and HTTP/SSE interfaces. Its current agents plugin also hosts agents and exposes a streaming POST /chat route. That plugin is beta; verify the installed version before copying an example. AppKit is more than a transport wrapper.
A simple approval example
Consider an assistant drafting a refund. In this illustrative event contract, the screen first receives status: checking_order, then approval_required, and finally completed after an authorised approval and a confirmed result. An error event means the interface should explain what can happen next.
These are proposed application event names, not LangChain or AppKit API names. AppKit documents its own approval event, appkit.approval_pending. An adapter would deliberately translate between the runtime's vocabulary and the UI's contract.
Give events a run identifier and sequence. Show the known stage while a tool runs; token output is optional. Keep private prompts, credentials and internal reasoning out of user-facing progress. Approval is a separate authenticated request to the server, checked again before the operation executes. Receiving an event never grants authority.
Choose around the work
Choose LangChain or LangGraph when its orchestration, integrations and existing team knowledge fit the workflow. Plan the application boundary explicitly: authenticated endpoint, event mapping, cancellation and stored run status.
Evaluate AppKit when the application lives in Databricks and its server, integrations and agent capabilities cover the job. Inspect stability at the plugin level. A SQL result stream, model token stream and agent lifecycle are different contracts even when they share SSE as transport.
They can coexist across an intentional service boundary, but a shared transport does not make them plug-compatible. Begin with one runtime and one event contract; add a bridge only when a concrete requirement justifies operating both.
Test the interrupted connection
SSE defines a text event stream, not durable execution. Browser EventSource reconnects, but the server must implement retention and replay for that reconnect to recover missed work. EventSource's native interface uses GET; a streaming POST endpoint needs a compatible SDK or a fetch-based streaming client.
Disconnect the browser halfway through the refund. Reconnect and ask for the recorded run state. The screen should discover whether work is waiting, finished or failed without blindly starting another refund. Also verify that the deployed proxy delivers chunks promptly rather than buffering the entire response.
That is the useful comparison: which approach lets your team implement and operate this contract clearly? Measure time to the first meaningful update and recovery behaviour on the same workflow before making speed claims.
Share the graphic with the engineer building your agent interface. Bring one slow or uncertain workflow, the current runtime and the point where users lose confidence. We can discuss the event contract and a small experiment to validate it.