For AI Agents
Hand your agent this brief or the ReUI MCP, not a screenshot. Installs with a ReUI Pro or Ultimate license.
When to use
- A live step feed of one agent run that the person who started it can approve, pause or stop
- The research trail behind an answer: the search query, numbered sources, repo files and confidence
- A record of what a run touched and settled: MCP calls per server, refused scopes and failed items
When not to use
- Operator pages across many runs: a run queue, an approval inbox or tool access settings: use the Agents blocks
- The conversation around the run: the message thread, the prompt composer and the replies: use the AI Chat blocks
- A dated history of what people did, such as activity feeds, milestones or release notes: use the Timeline blocks
Agent notes
- Each page.tsx pads a top aligned
min-h-svhwrapper aroundAgentActivity, whose root caps atmax-w-xlormax-w-2xl; drop the wrapper in your layout - Each run is replayed from the block's data file on
setTimeouttimers; drive the same state from your agent's events instead - Each block calls
toastfromsonnerbut mounts no toaster, so those messages stay hidden until your layout renders one
Third-party API docs
- Sonner v2: API reference, docs, used by 5 of 5 blocks
https://web.dev.reui.io/blocks/ai-agents/agent-activity.mdsearch({ query: "agent activity", type: "block", category: "agent-activity" })Shadcn Agent Activity Blocks: Run Feeds, Approvals and Tool Call Logs
An agent that works for 40 seconds and returns an answer is indistinguishable from an agent that guessed. The difference is visible only in the run: which steps it took, which files or records it touched, which tools it called and on whose authority, and where it stopped to ask.
These 5 blocks are that surface. A run console that halts at an approval and takes Approve, Revise or Deny inline. A live feed you can drop from a readable summary down to a raw monospace log. A research trace that shows each source landing before the answer does. A table attributing every tool call to the server that served it, including the one that was refused. And an outcome report for after it finishes.
None of them are a chat UI, and that is deliberate. They are the part a chat transcript cannot show: what happened between the prompt and the reply.
All Agent Activity Blocks
Open any block on its own page for a live preview, the components it is built from, and the install command.
- Approval Run Console Agent run console that stops at approval steps for an inline Approve, Revise or Deny
- Live Run Feed Live agent run feed with Summary, Detailed and Raw monospace log views
- Research Timeline Research timeline from search query via cited sources and repo files to a confidence rated answer
- MCP Call Audit MCP call table attributing each tool call to its server, with the refused scope and a Grant
- Run Outcome Report Agent run outcome report with a done, failed or skipped badge per item and a scoped retry
A Spinner Is Not a Status
Every one of these blocks answers the same question in a different shape: what is it doing right now, and what has it already done?
The run console keeps one list with 3 zones: finished steps above, a single live band with a Progress bar, and the queue below capped with an N more after these line, so a 30 step run stays one screen tall. The live feed instead narrates, naming the file, command, query or issue each step touched.
That feed carries 3 density modes rather than one. Summary reads as prose for someone checking in, Detailed is the default, and Raw drops to fixed column monospace lines like an edit with its path and a plus and minus count, which is the view an engineer actually wants when something went wrong.
Steps land over time in all of them, with Skeleton rows holding the space a pending step will occupy, so the layout does not jump as the run fills in.
Stopping for a Human
Human in the loop is easy to draw and hard to build, because the interesting part is what happens to everything downstream of the answer.
The run console marks steps that will need you before they arrive, with a Needs you badge sitting on a queued row, so nobody discovers an approval by watching a spinner stop. When the live band is blocked it swaps in either the Approve, Revise and Deny buttons or an InputGroup answer field, depending on whether the agent needs a decision or an answer.
Denying is where the block earns its place. Every step gated behind that approval is restamped as skipped and struck through, so a decision propagates through the plan instead of leaving orphaned steps that will never run. Revising routes differently again.
The outcome report carries the same idea after the fact: a blocked item names the permission it wants, and clearing that blocker rewrites the row to say the blocker is cleared rather than silently re-running.
Which Tool, Which Server, Whose Permission
As soon as an agent has more than one MCP server attached, activity is no longer one list. It is a question of attribution.
The MCP call table gives every call a server, a tool, a result and a duration, with a running tally of calls across servers. Calls stream in over Skeleton rows on uneven timers, which is what a real run looks like, and a ToggleGroup filters down to refusals only.
The refusal is the row that matters: a call declined for a scope it did not hold, with a Grant control that re-queues it for the rest of the session. A server that disconnected mid run wears a dropped badge rather than vanishing, because a call that never returned is not the same as a call that was never made.
It carries 3 separate Empty states, for no servers connected, no refusals left after granting, and nothing refused in the first place. Those are 3 genuinely different messages, and collapsing them into one is the usual mistake.
Showing the Work, and the Ending
Two blocks handle the bookends: where an answer came from, and what a finished run actually achieved.
The research trace is a vertical ReUI Timeline running from the search query through cited sources, each with its publisher mark, to the repo files it checked and the answer it produced with its stated confidence. Sources land one at a time on their own timers, and each row exposes copy and open actions on hover.
The outcome report is an Item ledger inside a ReUI Frame. Every row carries its state, the evidence behind it as a command, a diff or a record, a verified or unsupported verdict, and a duration. States run to 4, because cancelled is not failed and a report that conflates them is lying about the run.
Its retry is scoped rather than global: re-running one failed item also settles the items that were blocked behind it, and the finishing toast reports how many recovered and how many still failed. Keep what succeeded snapshots first, so the whole thing is undoable.
All Shadcn Block Groups
Browse the full ReUI Shadcn blocks library by product surface. Each group bundles category-level blocks you can mix and match across your project.
- Shadcn Application Blocks (303) Browse 303 Shadcn Application blocks across 23 categories.
- Shadcn Data Grid Blocks (47) Browse 47 Shadcn Data Grid blocks across 9 categories.
- Shadcn Charts Blocks (52) Browse 52 Shadcn Charts blocks across 10 categories.
- Shadcn Solutions Blocks (76) Browse 76 Shadcn Solutions blocks across 11 categories.
- Shadcn AI & Agents Blocks (22) Browse 22 Shadcn AI & Agents blocks across 3 categories.
- Shadcn eCommerce Blocks (87) Browse 87 Shadcn eCommerce blocks across 13 categories.
- Shadcn Marketing Blocks (67) Browse 67 Shadcn Marketing blocks across 8 categories.
Frequently Asked Questions
Do these work with my agent framework?
Are these a chat UI?
Is the activity real, or a static screenshot?
Which block should I start from?
Can I show which MCP scopes an agent was refused?
How do I install an agent activity block?
Start building with ReUI Pro today.
Every Pro block, every style, and every future addition, with one license for unlimited projects.
From $249, once. Lifetime updates.