Stop Asking LLMs to Do Math: Client-Side Functions in Flutter GenUI with bloc_signals

The catalog is actually the easy part—especially since modern LLMs are already trained extensively on tool calling and JSON schemas. When an agent connects to an A2UI renderer, advertising registered catalog functions and their CommonSchemas is no different than handing a standard function-calling schema to Gemini or Claude. The models pick up the bindings immediately and rarely hallucinate the arguments once they have typed schemas.

Where I see teams hesitate initially isn't the catalog—it is the paradigm shift regarding boundaries:

1. The "Oracle Fallacy": In early GenUI demos, the tempting illusion is that the LLM should handle everything end-to-end. Treating the model as an all-knowing oracle instead of a semantic layout compiler makes developers reluctant to draw a hard architectural line between creative layout and deterministic computation.
2. Fear of Async Plumbing: Teams that haven't worked with synchronous signals naturally assume that wiring client-side execution means building complex StreamController pipelines, debouncers, or manual setState() webs across generated widgets. Once they see that the catalog function compiles directly into a native computed() signal—updating the leaf widget in the exact same frame with 0ms latency and zero microtasks—that resistance evaporates into relief.

Telling the agent what functions exist is just schema advertising. The real win is deciding up front that your app's math, device hardware, and business rules belong to the local processor, not the token budget.

Great question, Paul. It depends on whether the call happens via Inbound RPC or Reactive UI Binding, but in both cases it fails explicitly and loudly rather than silently swallowing the error into a ghost screen.

Here is what happens under the hood:

1. Inbound RPC (CallRendererFunctionMessage)

If the remote agent sends a direct RPC message requesting a function that doesn't exist in the catalog, A2uiSurfaceBloc intercepts it and immediately returns a structured RendererFunctionResponseMessage with a typed error:

{
  "functionCallId": "call-123",
  "error": "Function not found: computeRocketTrajectory"
}

The agent gets immediate feedback that the tool isn't registered, and the client application continues running without a hitch.

2. Reactive UI Bindings ({"call": "unknownFunction"})

When a streamed component binds a dynamic property (like a Text or Card) to an unregistered function:

• catalog.invoke() throws a typed A2uiCatalogResolutionError: Function not found: <name>.
• Inside the signals graph, the computed() signal captures this as a SignalEffectException.
• In debug mode, this flags immediately in your logs and DevTools console, identifying the exact missing function name so you don't spend hours wondering why a field is blank.
• In the Flutter widget tree (bloc_signals_genui_flutter), component resolvers are wrapped in defensive error boundaries. The individual offending node renders its fallback error state (or standard debug error tile), while the rest of the surface tree continues to mount and render cleanly.

No silent black holes or phantom state!

It is wonderfully rewarding to see the comment section turning into an architectural playbook!

You hit on a profound point about agent feedback loops: when an agent receives a typed error like A2uiFunctionCallError(code: "FUNCTION_NOT_FOUND", ...) or an explicit schema rejection, the model actually has an actionable gradient to self-correct—it can read the error payload, inspect its catalog prompt, and retry with a valid function call.

With a silent ghost screen or a deceptive $0.00, the feedback loop is completely broken: the agent thinks it succeeded, the user thinks the app is broken, and nobody has a stack trace.

Finding that balance between expressive catalog grain size, defensive typed boundaries, and synchronous signal performance is really where modern Generative UI transitions from "cool tech demo" to durable production engineering.

Thanks for reading through the threads and pulling together the key lessons!

You have put your finger right on the critical difference between a pedagogical tutorial snippet and a production-grade catalog function.

You are 100% right to worry: in real-world commerce, a silent fallback to 0.0 is dangerous because displaying a $0.00 price tag or a free cart item is the worst kind of defect—it looks plausible to the user, but it is completely wrong.

Here is how schema validation and path failures are handled in practice across the two layers:

1. Inbound RPC: Strict Schema Validation

When the remote agent calls a function directly over the wire via CallRendererFunctionMessage, the A2UI engine validates the incoming JSON against the function's argumentSchema before execute() is ever invoked. If the agent sends a string where a number was required, or omits a required field like unitPrice, the engine rejects the call immediately and returns an explicit A2uiFunctionCallError (with code: "INVALID_ARGUMENT") back to the agent. The function never runs with junk data.

2. Reactive UI Expressions: Don't Fall Back, Throw!

In the article's snippet, I wrote (args['unitPrice'] as num?)?.toDouble() ?? 0.0 for brevity, but in production code, you should never silently default a missing required field.

Instead, your production execute() should assert required invariants:

@override
Object? execute(Map<String, Object?> args, DataContext context, [CancellationSignal? signal]) {
  final rawPrice = args['unitPrice'] as num?;
  if (rawPrice == null) {
    throw ArgumentError.notNull('unitPrice');
  }
  // ...
}

Here is what happens when it throws:

• If an agent references a nonexistent DataModel path (like /cart/missing_item/qty), context.resolveSignal() resolves that path to null.
• When execute() runs, it detects the missing value and throws an ArgumentError.
• Inside the reactive graph, the computed() signal captures the exception.
• In Flutter, NodeResolver catches the failed evaluation at the component boundary and displays an explicit error fallback (for example, displaying an error tile or "Price unavailable" skeleton) rather than deceptively painting a green $0.00.

The Rule: Fail Loud on Broken Contracts

If an optional field is missing (like a coupon discount), defaulting to 0.0 is sound domain logic. But if an essential, structural input is missing or malformed, fail loud at the boundary. A broken component card is easy to spot in testing and telemetry; a silent $0.00 invoice is a financial disaster!

Spot on, and this touches the first law of client-server security: never trust the client for final transactional authority.

Client-side functions exist for responsive user ergonomics and 120 FPS visual feedback, not for final financial settlement.

It is the exact same invariant web developers have lived with for thirty years:

• Your client-side JavaScript (or Dart in Flutter) calculates cart totals and renders the discount instantly so the user doesn't wait through a spinner while typing or dragging sliders.
• But when the user taps "Place Order", your backend API / payment gateway calculates the authoritative price against the database and applies the verified coupon rules before charging the card. Nobody lets a browser POST {"total_to_charge": 0.00} directly to Stripe!

In bloc_signals_genui, this is why we separated Path A (Interactive Actions) and Path B (Bidirectional RPC):

1. Local expressions like calculateCost handle instant preview arithmetic in the UI signal graph.
2. When an authoritative action occurs (like applying a restricted promo code or checking out), SubmitAction emits an A2uiRendererAction or invokes callAgentFunction() to validate against the server before committing state.

The phone gives you 0ms interactive rendering; the server keeps the ledger honest.