A basic chatbot can look like a list of messages and an input field. An agent interface needs to explain more: whether work is in progress, whether a tool failed, and whether an action is waiting for the user's approval.
Those are interaction and state-management problems, not just styling problems. This walkthrough outlines a component plan using Cuelark UI, an open-source library of 107 shadcn/ui components. I work on Cuelark. The aim here is to explain the interface structure, not promise that installing a component gives you a working agent backend.
Start with the conversation loop
Begin with three pieces from the catalog: Conversation, Message and Prompt Input. Use them as the starting points for the conversation area, individual entries and user input.
Before wiring a model, define your application states. At minimum, distinguish an empty conversation, a request in progress, a completed response and a failed request. Decide whether users can submit another prompt while work is running, and what cancelling actually does on the server.
Keep user input if submission fails. Avoid showing a confident-looking completed response when the backend has only delivered part of it. These decisions live in your application's logic; the visual components don't establish them for you.
Install source, then inspect it
Cuelark follows the shadcn model: its homepage says components install through the shadcn CLI into your codebase, rather than requiring a Cuelark runtime package. Start at the current Cuelark UI documentation and use the installation instructions for your chosen component.
Inspect the generated source and dependencies before integrating it. Check how its props, exports and styles fit your project. This article intentionally avoids an invented CLI command or undocumented component API: copy the current command from the component's own page.
Bring in the smallest useful slice first. A readable conversation with reliable input behavior is a better foundation than a screen full of agent activity that isn't connected to real state.
Give tool activity a clear state
Next, consider Tool for displaying tool activity. In your application model, distinguish requested, running, succeeded and failed operations. Use stable identifiers so that an update changes the correct activity rather than appending a duplicate.
Show a concise label that explains what is happening. When a tool fails, explain what the user can do next without dumping raw internal errors or credentials into the conversation.
Do not label an operation successful merely because the model described an intention. The UI should reflect the actual tool result. Where a result is uncertain or incomplete, say so.
Treat reasoning as a user-facing explanation
The catalog also includes Reasoning. Plan this area around useful, permitted progress summaries: what the agent is checking, what information is missing and why it needs a decision.
A component named Reasoning is not a reason to expose hidden model reasoning, raw prompts or private intermediate data. Send only information your application is allowed to show. Keep explanations short enough that users can tell whether anything requires their attention.
If no progress summary is available, a clear working state is better than fabricated step-by-step activity.
Make approvals real, not decorative
Use Confirmation as the visual starting point for an approval step when an operation needs consent. Explain the proposed action, destination and consequences before offering a choice.
The server must enforce that approval. A button in the interface is not a security boundary. Bind consent to the exact pending operation, reject stale approvals, and make repeated clicks safe. If the action changes after approval, require a new decision.
For external actions such as sending a message, show the recipient and content. Don't treat a general chat instruction as permission for every later operation.
Test transitions before adding polish
Exercise empty messages, long replies, interrupted streams, failed tools and expired approvals. Check keyboard navigation and visible focus in the integrated application, not just an isolated demo. Test narrow screens and reduced-motion preferences too.
Cuelark's homepage describes keyboard support, accessible primitives and reduced-motion handling, but your composition still needs testing. Custom wrappers and event handlers can introduce problems even when the starting pieces are sound.
The useful outcome is a UI where users know what they asked, what the agent actually did and what still needs their decision. Explore Cuelark UI for the components, then connect them to explicit application states and backend checks. That's the difference between an attractive chat mockup and an agent interface people can understand.
