Search for "AI chat UI" and you'll find dozens of component libraries. They look promising - sleek message bubbles, typing indicators, file upload buttons. Install one and the reality sets in. These are chat templates with a fresh coat of paint. They handle text in, text out. The moment your agent calls a tool, shows reasoning, needs approval, or returns structured data, you're on your own.
Agent frameworks take the opposite approach. They give you the orchestration layer - tool calling, memory, planning - but leave the interface as an exercise for the reader. You end up building a custom frontend from scratch, wiring up websockets, managing streaming state, and handling all the edge cases that make agent UIs actually work.
Even when you have both - a decent UI library and a capable framework - you're still missing one crucial piece: the runtime. Who handles durable execution when tools fail? Who persists state across sessions? Who manages the streaming protocol, the tool orchestration, the observability? You do. And suddenly you're building infrastructure instead of building your agent.
We built ui.inference.sh because none of these pieces work in isolation. A complete agent product needs all three: components that understand what agents actually do, a runtime that handles execution reliably, and tight integration between them. Drop your agent into your product. Hook it up. Ship it.
The Complete Solution
ui.inference.sh closes this gap. It provides agent-native UI components that understand tools, approvals, widgets, and streaming - not as afterthoughts but as core features. Combined with inference.sh handling the runtime, you get end-to-end infrastructure for shipping agent products.
The Agent component is the centerpiece. It's not a chat template extended to handle agents. It's built specifically for agent interaction patterns. Tool invocations render with full lifecycle visibility - pending, running, awaiting approval, completed, failed. Streaming works out of the box. File uploads integrate naturally. Reasoning steps collapse and expand. The patterns agents need are built in, not bolted on.
1<Agent2 proxyUrl="/api/inference/proxy"3 config={{ agent: 'your-org/your-agent@abc123' }}4/>That's a complete agent interface. The runtime handles execution, tool orchestration, state persistence, and streaming. The component handles display, interaction, and feedback. Your code focuses on what makes your agent valuable.
What the Components Handle
Tool invocations display the full lifecycle of agent actions. When your agent calls a tool, users see the tool name, parameters it was called with, execution status, and results. No custom rendering code. No state management for tracking tool progress. The component handles pending states, progress indicators, success displays, and error handling.
Human-in-the-loop pauses execution and presents approval requests. The agent shows what it wants to do. Users approve, reject, or modify. The decision flows back to the runtime automatically. Building approval gates into your agent doesn't require building approval UI - the component supports it natively.
Widget rendering turns structured agent output into interactive UI. Agents can generate forms, selections, cards, and data displays. The widget renderer interprets these definitions and produces live components. User interactions flow back to the agent. Rich interfaces emerge from simple structured output without custom component development.
Streaming shows responses as they generate. Not just text streaming - tool calls stream their status, reasoning streams as it happens, the full agent thought process becomes visible. Users see progress immediately instead of waiting for complete responses.
Client-side tools execute in the browser while maintaining the same interaction patterns as server-side tools. An agent can scan page elements, read form state, or interact with local data without that information leaving the user's device. The demo at ui.inference.sh shows an agent helping configure a pricing form - reading fields, filling values, all client-side. The same tool invocation UI patterns apply whether the tool runs on a server or in the browser. Users see consistent feedback regardless of where execution happens.
Two Configuration Approaches
The components support two ways to configure agents, matching different team needs.
Ad-hoc configuration defines everything in code. You specify the model, system prompt, tools, and behavior directly. This works well when agents are tightly coupled to application logic and developers need full control.
1<Agent2 proxyUrl="/api/inference/proxy"3 config={{4 core_app_ref: 'openrouter/claude-sonnet-4@abc123',5 system_prompt: 'You help users configure their account.',6 tools: myTools,7 example_prompts: ['Set up my profile'],8 }}9/>Template configuration references an agent defined on inference.sh. You specify just the agent reference - everything else comes from the platform. Update agent behavior through the dashboard without deploying code. Product managers can modify prompts and tools while developers focus elsewhere.
1<Agent2 proxyUrl="/api/inference/proxy"3 config={{ agent: 'okaris/shadcn-image@54mh5vvf' }}4 description="I generate images from descriptions"5 examplePrompts={['a cat wearing a top hat']}6/>Both approaches use the same UI components. The visual experience is consistent regardless of where configuration lives. Start with ad-hoc configuration during development, then move to templates when you need non-technical team members to iterate on agent behavior. The migration path is straightforward because the UI layer doesn't change.
The Runtime Connection
UI components alone aren't enough. Displaying tool invocations requires something executing tools. Showing streaming requires something streaming. The components are designed to work with inference.sh, which handles the infrastructure that makes agents reliable.
Durable execution means tool failures don't crash agent loops. State persists across invocations. Close the browser, come back tomorrow - the conversation continues.
Tool orchestration provides 150+ apps as tools through one API. Structured execution with approvals when needed. Full visibility into what ran.
Observability gives real-time streaming and logs for every action. When something goes wrong, you trace exactly what happened.
The components display what the runtime provides. The runtime provides what agents need. Together they solve the complete problem - from execution to interface. You're not building infrastructure. You're building what makes your agent different.
This integration goes deeper than API compatibility. The components understand inference.sh's streaming protocol natively. Tool states flow through automatically. Approval flows connect without custom wiring. The pieces are designed to work together, not adapted after the fact.
shadcn-Style Ownership
The components follow shadcn's model: you copy code into your project. No npm packages to version-manage. No fighting library opinions. The code is yours to read, modify, and extend.
1npx shadcn@latest add https://ui.inference.sh/r/agent.jsonThis copies the agent component and dependencies into your components directory. Tailwind CSS styling. React hooks and context for state. Standard patterns you can customize without learning a framework.
Want different message bubble styling? Edit the file. Need custom tool renderers for specific tools? Modify the component. The code is right there, not hidden in node_modules.
Stop Building Chat Templates
The pattern repeats across the industry. Team needs agent interface. Team finds chat library. Team extends chat library to handle agent behavior. Team spends months on UI work instead of agent work. Team ships late, maintains custom code forever.
ui.inference.sh breaks the pattern. Components that understand agents. Runtime that handles infrastructure. Your team focuses on what the agent does, not how to display it or keep it running.
The registry is live at ui.inference.sh. Browse components, try demos, copy what you need. The pricing assistant shows client-side tools in action. The image agent shows template configuration. Every component includes source code showing exactly how it works.
Agent UIs shouldn't be the hard part. The interesting work is building agents that solve real problems. Let the infrastructure be infrastructure.
FAQ
How is this different from Vercel's AI SDK UI components?
Vercel's AI SDK provides excellent primitives for streaming chat interfaces. The components focus on the core chat pattern - messages, streaming text, basic attachments. ui.inference.sh extends into agent-specific territory: tool invocation lifecycles, human-in-the-loop approval flows, widget rendering for dynamic UI, and deep integration with agent runtime features like durable execution and observability. If your agent just chats, either works. If your agent uses tools, needs approvals, or generates interactive UI, ui.inference.sh handles patterns that chat-focused libraries don't address.
Can I use the UI components with a different backend?
The components are designed for inference.sh, which provides the streaming protocol, tool execution, and state management they expect. You could adapt them to other backends by reimplementing that functionality, but you'd be rebuilding significant infrastructure. The value is the combination - polished UI plus capable runtime. Separating them means taking on the runtime work yourself, which is exactly what we built inference.sh to avoid.
What if I need components you don't provide?
Since the code lives in your project, you extend it like any other code. The components use standard React patterns - hooks, context, composition. Add custom tool renderers by extending the tool invocation component. Build specialized message types by following the message component patterns. The shadcn model means you're not waiting for library updates or working around package limitations. Your codebase, your extensions.