Service · Agentic UI

Agentic UI for Angular: assistants with visible controls

An assistant is useful when it helps a person complete a real task. I build assistant workflows into Angular applications with visible actions, explicit permissions and tests. We start with the user's work and measure whether an assistant improves it.

Discuss your assistant workflow ↗
Start with
One repeatable task and a manual baseline.
You receive
A working integration, decision record, tests and eval scenarios.
Measure
Task completion, errors, latency, cost and user control.
GeoAtlas assistant with a visible sequence of map actions and undo buttons for supported commands.
My GeoAtlas prototype: action cards beside the map. Model replies in this capture are replayed from a recorded session; this image is not a live-model benchmark.

A workflow people
can inspect.

  • A shared command core. Typed parameters, availability rules and permissions govern commands from menus, the keyboard and the assistant. Model output goes through application validation.
  • Visible actions. Previews and confirmation rules for consequential actions; undo for commands that support it. Stop prevents further steps where cancellation is supported. It does not reverse completed changes or external effects.
  • Understandable context. Show the context sources used and document what leaves the browser, including user text, identifiers and any relevant geometry. Result limits reduce exposure; they do not replace a data review.
  • Failure states. Clear handling for unavailable models, refused actions, timeouts, limits and partial completion, with a manual path still available.

Controls in the application.
Evaluation around the model.

A server-side gateway keeps provider credentials out of the browser and can enforce tool allowlists, budgets and step limits. Signed state can detect tampering; authentication, authorization, encrypted transport and data retention remain separate responsibilities.

Recorded conversations test the interface and protocol deterministically. Live-model evals measure task completion and tool use on defined scenarios. Neither proves that a model will behave correctly in every situation.

A local or cloud model can sit behind the same integration boundary. Changing providers still requires contract checks and new evals for behaviour, latency, cost and data handling.

Protocols where
the product needs them.

AG-UI provides an event vocabulary for agent interfaces. Using selected event types is not proof of full protocol compatibility: the supported subset needs documentation and tests.

MCP and MCP Apps can expose tools and interfaces to compatible hosts. WebMCP remains experimental and needs a browser-support check. The Agentic UI article explains these boundaries and links to the primary specifications.

The application's command API stays separate from provider adapters so that changing a model does not require redesigning every screen.

Scope a useful
first delivery.

We identify one task, the actions the assistant may take, the data it needs and the checks required before release. You receive the implementation, recorded test fixtures, evaluation scenarios, and a note on costs, privacy and remaining limits.

Timing depends on existing APIs, permissions and the reliability the task requires. We agree on the assessment and delivery scope before estimating it. An assistant is one option; a fixed workflow may be the better result of the assessment.

GeoAtlas is my own experimental implementation. Its technical case study records the command architecture, dated measurements and their limitations.

Which task should become easier?

Describe what users do today, what makes it difficult and any existing prototype.

contact@clearcraft.dev ↗