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.

• Agent Activity 1 Agent run console that stops at approval steps for an inline Approve, Revise or Deny
• Agent Activity 2 Live agent run feed with Summary, Detailed and Raw monospace log views
• Agent Activity 3 Research timeline from search query via cited sources and repo files to a confidence rated answer
• Agent Activity 4 MCP call table attributing each tool call to its server, with the refused scope and a Grant
• Agent Activity 5 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 (344) Browse 344 Shadcn Application blocks across 24 categories.
• Shadcn Data Grid Blocks (39) Browse 39 Shadcn Data Grid blocks across 8 categories.
• Shadcn Solutions Blocks (74) Browse 74 Shadcn Solutions blocks across 10 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.
• Shadcn AI & Agents Blocks (18) Browse 18 Shadcn AI & Agents blocks across 2 categories.