React for AI Copilots and HITL Interfaces

Because trust is built or lost at the interface. A model can be excellent and still fail in front of a user if the screen freezes during a slow response, hides what the agent is doing, or buries the approval step. Streaming output, visible tool-call progress, honest failure states, and a real review path are what make people rely on an AI system instead of quietly working around it. The interface is where the system's behavior becomes legible to the person responsible for it.

It comes down to where the feature lives and who owns the server layer. Use React when you are embedding AI into an application you already run, since a component talking to your backend is the lighter, faster path. Reach for Next.js when the AI feature is a standalone product that needs its own routing, server rendering, and route handlers to proxy model calls. A plain SPA only makes sense for a tiny one-off embed with almost no review or dashboard state. We pick based on the feature, not on fashion, and we cover the Next.js trade-off honestly on the Next.js page.

For the streaming transport we read Server-Sent Events or a fetch stream with a ReadableStream reader, and we often sit the Vercel AI SDK (useChat, useCompletion) on top so abort handling, message bookkeeping, and reconnection are not hand-rolled. Run state, the structured shape of a single agent run with its pending tool calls and partial messages, lives in Zustand or Redux Toolkit. The request-shaped data around it, thread history, saved sessions, and queue items, goes through React Query or SWR so caching and invalidation are handled once. We choose per surface rather than forcing one tool everywhere.

Everything a model writes is treated as untrusted input. We never inject raw output through dangerouslySetInnerHTML. Markdown is parsed and then constrained to an allowlist of tags and attributes, the resulting HTML is sanitized with DOMPurify, links are constrained, and code blocks render as inert text. The result is that prompt-injected content cannot run a script, smuggle an event handler, or trigger a real action from inside a rendered message. The safe-render layer is a deliberate part of the architecture, not an afterthought.

When a dashboard holds thousands of agent runs or a review queue that keeps growing, we virtualize the list with react-window or TanStack Virtual so only the rows in view actually mount. We pair that with memoization on row components and tight re-render boundaries, so a streamed update to one run does not re-render the whole table. The effect is an operational view that stays smooth as the data grows, instead of one that degrades the moment real volume arrives.

Yes. Approve, edit, and reject queues with full context and an audit trail are one of the most common things we build, and usually the line between a safe agent and a risky one. On the front end this is a queue of items awaiting a decision, each mirroring an interrupt point in the agent service, with every decision recorded against who made it and when. The same review surface is where role gating matters most, so the right people see the right actions.

The interface does not talk to a model directly. It connects to a Node streaming API that proxies the model, holds credentials, and shapes the event stream, and that service calls the Python agent service where the agent logic, tools, and interrupts live. React renders the stream and the review surface, while the server layers own the secrets, the orchestration, and the decisions that count. That separation keeps keys out of the browser and lets the same interface sit in front of whatever model or agent runtime you run.

Reviewers, operators, and read-only viewers see only the data and actions their role allows. Gating happens in the component tree so the UI reflects the role, and it is enforced again at the API so a hidden button is never the only thing protecting a privileged action. Every consequential decision, an approval, an edit, a rejection, is written to an audit log with the person and the timestamp, which is the basis for any later compliance or incident review. We design sensitive workflows, including healthcare ones, to be HIPAA-aware. We do not claim certification, but we build with the access controls and isolation that sensitive data calls for.

Yes. We watch how people actually use the interface and keep tuning flows, copy, states, and performance, because the first version of an AI interface is never the last. Real usage surfaces the slow paths, the confusing states, and the review steps people skip, and we fix those on real traffic. We build and run. We do not just build and hand off.