Proposal: Server-Side Functions and Unified Function RPC (Reframing ActionResponses)

[jacobsimionato]

Note: This issue presents an architectural design document proposing to replace the draft A2UI v1.0 wantResponse and actionResponse event features with Catalog-Defined Server-Side Functions. The complete design proposal is included verbatim below for review and discussion.

---

Issue Description

In draft A2UI v1.0, synchronous event responses were introduced by adding "wantResponse": true and "responsePath" to component action.event declarations. As identified during specification review, this approach introduces three architectural issues:

1. The Informal Schema Contract Gap: Setting wantResponse: true returns an untyped any payload on the wire. Components that bind responsePath to this return value rely on an unverified, out-of-band agreement between catalog designers and server implementers.
2. Functional Redundancy: Allowing an action response to mutate the data model via responsePath duplicates the capability of the standard updateDataModel message, creating ambiguity for implementers.
3. Inexpressive Error Handling: The draft actionResponse.error object accepts only a flat code and message string, making it impossible to return structured validation errors without treating failures as protocol-level successes.

This design proposal resolves these problems by:

• Preserving A2UI v0.9's asynchronous, fire-and-forget semantics for action.event and removing all draft v1.0 response properties (wantResponse, responsePath, and actionResponse).
• Formalizing Server-Side Functions in catalog definitions (FunctionDefinition) with an orthogonal separation between implementation location ("executedAt": "client" | "server") and invocation authorization ("callableFrom": "clientOnly" | "serverOnly" | "clientOrServer").
• Requiring explicit JSON Schema contracts for input arguments (args), return values (returnType), and structured errors (errors).
• Introducing short-circuit exception evaluation for nested function expressions and new client-to-server RPC messages (callServerFunction / serverFunctionResponse).

---

Design Document: Server-Side Functions and Unified Function RPC

A2UI v1.0 Proposal: Server-Side Functions and Unified Function RPC (Reframing ActionResponses)

This proposal replaces A2UI v1.0's draft wantResponse and actionResponse event features with Catalog-Defined Server-Side Functions.

By formalizing server-side computations as catalog-registered functions alongside client-side functions, we eliminate the informal schema contract gap, preserve A2UI v0.9's clear separation between fire-and-forget events and data-model mutations, and provide a unified, statically typed RPC mechanism for checks, queries, and synchronous interactions.

---

1. Executive Summary and Motivation

Problems with Draft v1.0 ActionResponses (wantResponse / responsePath)

1. The Informal Schema Contract Gap: In draft A2UI v1.0, setting "wantResponse": true on an event action returns an untyped "value": any payload on the wire. Components that bind responsePath to this return value rely on an unverified, out-of-band agreement between the catalog designer and the server implementer.
2. Functional Redundancy: Allowing an action response to mutate the shared data model via responsePath duplicates the capability of the standard updateDataModel message, creating ambiguity for agent implementers.
3. Inexpressive Error Handling: The draft actionResponse.error object accepts only a flat code and message, making it impossible to return structured validation errors without treating failures as protocol-level successes.

The Reframed Approach: Unified Catalog Functions

Instead of adding synchronous response properties to event actions, this proposal:

1. Preserves v0.9 Action Semantics: action.event remains an asynchronous, fire-and-forget notification sent from the renderer to the agent. All draft v1.0 fields (wantResponse, responsePath, and actionResponse) are removed.
2. Distinguishes Implementation Location (executedAt) from Invocation Boundary (callableFrom):
   • executedAt specifies where the function is implemented and executed ("client" or "server" — strictly one or the other; a single function cannot be executed on both). If an application requires similar logic on both client and server, it is modeled as two separate functions with distinct names.
   • callableFrom specifies who is authorized to invoke the function ("clientOnly", "serverOnly", or "clientOrServer").
3. Establishes a Common Schema Contract: Every catalog function definition declares explicit JSON Schema contracts for both input arguments (args) and return types (returnType).
4. Supports Errors and Exception-Like Short-Circuiting: Both client and server functions can return structured errors instead of values. When functions are nested in expressions, an error returned at any point immediately short-circuits evaluation, propagating the error to the caller like an exception.
5. Adds Explicit Client-to-Server RPC Messages: Introduces a new callServerFunction message (renderer-to-agent) and a symmetrical serverFunctionResponse message (agent-to-renderer).

---

2. Architectural Design: Separation of Responsibilities

graph TD
    subgraph Catalog / UI Component
        ACT[Component Action Slot]
    end

    ACT -->|1. event| EVT[Fire-and-Forget Event]
    ACT -->|2. functionCall| FUNC[Unified Function Invocation]

    EVT -->|renderer_to_agent: action| A_SRV[Agent / Server]
    A_SRV -->|agent_to_renderer: updateDataModel| R_DM[Renderer Data Model]

    FUNC -->|executedAt: client| C_EXEC[Local Renderer Execution]
    FUNC -->|executedAt: server| S_EXEC[callServerFunction RPC]
    S_EXEC -->|renderer_to_agent: callServerFunction| A_SRV
    A_SRV -->|agent_to_renderer: serverFunctionResponse| S_EXEC

Loading

This proposal establishes three clean, orthogonal communication channels:

• Events (action.event): One-way, asynchronous user interaction notifications sent from renderer to agent. They do not block UI execution and do not return payloads.
• State Mutations (updateDataModel): Authoritative, imperative state synchronization sent from agent to renderer.
• Functions (action.functionCall): Synchronous computations, validations, queries, or checks triggered by interactive components. Whether a function runs locally on the renderer or remotely on the agent is determined transparently by the catalog's executedAt property ("client" vs. "server"), while authorization to invoke it is governed by callableFrom.

---

3. Formal Schema Definitions

3.1 Common Function Definition Schema (catalog_definition.json)

Every function declared in a catalog must conform to a common schema that defines its implementation location (executedAt), its invocation boundary (callableFrom), input arguments, return type, and optional error schemas:

{
  "FunctionDefinition": {
    "type": "object",
    "description": "Defines a client-side or server-side function in the catalog.",
    "properties": {
      "executedAt": {
        "type": "string",
        "enum": ["client", "server"],
        "default": "client",
        "description": "Indicates where the function is implemented and executed. Must be either 'client' or 'server'—a single function cannot be executed on both. If a system requires similar logic on both the client and server, it should be modeled as two separate functions with distinct names."
      },
      "callableFrom": {
        "type": "string",
        "enum": ["clientOnly", "serverOnly", "clientOrServer"],
        "default": "clientOnly",
        "description": "Indicates who is authorized to invoke this function—whether it can be called from the client, the server, or either."
      },
      "args": {
        "$ref": "https://json-schema.org/draft/2020-12/schema",
        "description": "JSON Schema defining the expected arguments for this function."
      },
      "returnType": {
        "$ref": "https://json-schema.org/draft/2020-12/schema",
        "description": "JSON Schema defining the return value of this function. MUST be specified for functions with executedAt: 'server'."
      },
      "errors": {
        "type": "object",
        "description": "Optional mapping of error codes to structured JSON Schemas representing error details.",
        "additionalProperties": {
          "$ref": "https://json-schema.org/draft/2020-12/schema"
        }
      }
    },
    "required": ["executedAt", "callableFrom", "returnType"],
    "additionalProperties": false
  }
}

Distinguishing executedAt and callableFrom

• executedAt ("Where is it implemented?"): Exclusively "client" or "server". There is no need for a function that executes on either/both; if client-side and server-side checks share similar intent, they should be declared as two distinct functions (e.g., validateEmailClient and validateEmailServer).
• callableFrom ("Who can call it?"): Specifies caller authorization. For example:
  • A function with "executedAt": "server" and "callableFrom": "clientOnly" is a server-side check or query that UI components can invoke.
  • A function with "executedAt": "client" and "callableFrom": "serverOnly" is a local renderer utility that the agent can execute remotely via callFunction.

Example Catalog Declaration

{
  "functions": {
    "validateEmailAddress": {
      "executedAt": "server",
      "callableFrom": "clientOnly",
      "args": {
        "type": "object",
        "properties": {
          "email": { "type": "string", "format": "email" }
        },
        "required": ["email"]
      },
      "returnType": {
        "type": "object",
        "properties": {
          "isValid": { "type": "boolean" },
          "normalizedEmail": { "type": "string" }
        },
        "required": ["isValid"]
      },
      "errors": {
        "VALIDATION_ERROR": {
          "type": "object",
          "properties": {
            "reason": { "type": "string" }
          }
        }
      }
    }
  }
}

3.2 Component Action Binding Schema (common_types.json)

Interactive components bind their action slots to either an event (agent notification) or a functionCall (unified function invocation):

{
  "Action": {
    "type": "object",
    "properties": {
      "event": {
        "type": "object",
        "description": "Dispatches an asynchronous, fire-and-forget event to the agent.",
        "properties": {
          "name": { "type": "string" },
          "context": { "type": "object" }
        },
        "required": ["name"],
        "additionalProperties": false
      },
      "functionCall": {
        "type": "object",
        "description": "Executes a catalog-defined function on the client or server.",
        "properties": {
          "call": { "type": "string" },
          "args": { "type": "object" }
        },
        "required": ["call"],
        "additionalProperties": false
      }
    },
    "oneOf": [
      { "required": ["event"] },
      { "required": ["functionCall"] }
    ]
  }
}

3.3 New Wire-Level Messages (renderer_to_agent.json and agent_to_renderer.json)

When a component triggers a functionCall whose catalog definition declares "executedAt": "server" (and whose "callableFrom" permits client invocation), the renderer transmits a callServerFunction message and awaits a serverFunctionResponse message.

Renderer-to-Agent: callServerFunction

{
  "version": "v1.0",
  "callServerFunction": {
    "functionCallId": "call_srv_8821",
    "call": "validateEmailAddress",
    "args": {
      "email": "user@example.com"
    }
  }
}

• functionCallId (string, required): A unique identifier generated by the renderer for this invocation.
• call (string, required): The registered name of the server-side function.
• args (object, optional): The arguments payload, validated against the function's catalog args schema.

Agent-to-Renderer: serverFunctionResponse

{
  "version": "v1.0",
  "serverFunctionResponse": {
    "functionCallId": "call_srv_8821",
    "value": {
      "isValid": true,
      "normalizedEmail": "user@example.com"
    }
  }
}

• functionCallId (string, required): Must match the invocation ID from callServerFunction.
• value (any): Present when execution succeeds; validated against the catalog's returnType schema.
• error (object): Present when execution fails; contains code (string), message (string), and optional structured details (any) matching the catalog's errors schema.
• Exactly one of value or error is required (oneOf).

---

4. Function Execution Semantics: Errors, Nesting, and Exception-Like Short-Circuiting

4.1 Error Returns vs. Value Returns

Both client-side and server-side functions can return structured error objects instead of values. Unlike draft v1.0's flat string errors, functions can return rich error payloads:

{
  "version": "v1.0",
  "serverFunctionResponse": {
    "functionCallId": "call_srv_8822",
    "error": {
      "code": "VALIDATION_ERROR",
      "message": "The provided email address is already registered.",
      "details": {
        "field": "email",
        "suggestion": "user+1@example.com"
      }
    }
  }
}

4.2 Function Nesting and Exception-Like Short-Circuiting

A2UI supports composing functions inside argument expressions. A component can pass the return value of a client-side function into a server-side function, or vice versa:

{
  "action": {
    "functionCall": {
      "call": "checkDeviceAuthorization",
      "args": {
        "deviceId": {
          "call": "getLocalDeviceId",
          "args": {}
        }
      }
    }
  }
}

Exception-Like Short-Circuit Evaluation

When evaluating a nested function chain:

1. The renderer evaluates innermost functions first.
2. If any function in the chain (whether client-side or server-side) returns an error, evaluation of the entire expression is immediately abandoned.
3. Downstream functions are never invoked. The error short-circuits the call stack and propagates directly to the calling component or SDK handler, behaving like a thrown exception in traditional programming languages.

sequenceDiagram
    participant C as Component
    participant R as Renderer (Client Engine)
    participant A as Agent (Server Engine)

    C->>R: Execute checkDeviceAuthorization(getLocalDeviceId())
    R->>R: Evaluate innermost: getLocalDeviceId()
    Note over R: getLocalDeviceId() fails with error: "PERMISSION_DENIED"
    Note over R,A: Short-circuit: checkDeviceAuthorization is NEVER called
    R-->>C: Reject with error: "PERMISSION_DENIED"

Loading

4.3 SDK Ergonomics (await action.execute(...))

Renderer SDKs present both client and server functions through an identical asynchronous Promise API. Whether a function executes locally or across the wire is determined by inspecting the catalog's executedAt property:

async function handleActionClick() {
  try {
    // SDK automatically inspects catalog's executedAt property:
    // If executedAt: "client" -> executes local handler
    // If executedAt: "server" -> sends callServerFunction & awaits serverFunctionResponse
    const result = await props.action.execute();
    console.log("Function succeeded with validated returnType:", result);
  } catch (error) {
    // Catches short-circuited errors from either client or server functions
    console.error("Function failed:", error.code, error.message, error.details);
  }
}

---

5. Modeling the Four Real-World Use Cases

Below is an analysis of how each use case from the original analysis document is modeled using Server-Side Functions, highlighting how this proposal resolves the limitations of draft v1.0 ActionResponses.

5.1 Button with an Asynchronous Loading Spinner

A "Submit Order" button shows a spinner and disables itself while the server processes the order.

{
  "component": "Button",
  "id": "submit_order_btn",
  "action": {
    "functionCall": {
      "call": "submitOrder",
      "args": {
        "cartId": "${/cart/id}"
      }
    }
  }
}

• How it works: When clicked, the button component's SDK wrapper sets isSubmitting = true and calls submitOrder. Because submitOrder is registered in the catalog with "executedAt": "server", the SDK transmits a callServerFunction message. When the agent returns serverFunctionResponse, the Promise resolves, and the button resets isSubmitting = false.
• Why this models it better:
  • No wire-level event pollution: action.event remains reserved for fire-and-forget notifications.
  • Formal return verification: If submitOrder is declared in the catalog to return { "orderId": "string" }, the SDK guarantees that the returned value matches this schema before resolving the Promise.
• Handling Side Effects: If submitting the order also clears the shopping cart, the agent transmits an authoritative updateDataModel message (path: "/cart", value: null) concurrently with or prior to serverFunctionResponse. State mutations remain imperative and decoupled from function return values.

---

5.2 Form Submission Returning Success Result or Validation Error

A registration form submits profile details. It can succeed or return field-level validation errors.

• How it works: The form's submit action invokes the server-side function registerAccount(formPayload).
  • Success: The server returns "value": { "accountId": "acc_109" }. The return value matches the catalog's returnType schema.
  • Validation Error: The server returns an error payload matching the catalog's errors schema:

    {
      "error": {
        "code": "VALIDATION_ERROR",
        "message": "Invalid registration fields.",
        "details": {
          "fieldErrors": {
            "email": "Email is already registered.",
            "password": "Must be at least 8 characters."
          }
        }
      }
    }

• Why this models it better:
  • Solves the Informal Schema Contract Problem: Both the success return value (value) and structured error payloads (error.details) are explicitly defined in the catalog's JSON Schemas (returnType and errors). The UI never relies on out-of-band assumptions about backend data shapes.
  • Rich Error Handling: Because functions support structured error objects, forms can map field-level errors directly to UI input controls without abusing message strings or treating validation failures as HTTP 200 successes.

---

5.3 Autocomplete and Typeahead Suggestions

An input field queries the server for autocomplete suggestions as the user types.

{
  "component": "TextField",
  "id": "search_input",
  "action": {
    "functionCall": {
      "call": "fetchSuggestions",
      "args": {
        "query": "${/search/query}"
      }
    }
  }
}

• How it works: As the user types "app", the component calls the server-side function fetchSuggestions({ query: "app" }). The server returns "value": ["apple", "application", "approved"]. The component SDK receives the validated array and updates the dropdown suggestions list.
• Why this models it better:
  • Eliminates responsePath redundancy: Rather than having the server automatically overwrite a path in the application's shared dataModel, the function returns a pure RPC result directly to the TextField component.
  • Schema Safety: If fetchSuggestions is declared in the catalog to return an array of strings, any accidental backend change that returns incompatible data is caught immediately by catalog validation.
  • Clean Concurrency Control: Because invocations are managed as Promises by the component SDK, the SDK can cancel or discard stale pending Promises when the user types a new character, preventing out-of-order race conditions without needing specification-level sequence tokens.

---

5.4 Synchronous Confirmation Gate (Modal or Dialog Completion)

A "Delete Project" modal requires server acknowledgment before closing or navigating away.

• How it works: Clicking "Confirm Delete" invokes the server-side function deleteProject({ projectId: "prj_55" }). The modal remains open while awaiting the Promise.
  • If the Promise resolves (value: true), the modal closes.
  • If the Promise rejects (error), an inline alert displays the error message inside the modal.
• Why this models it better:
  • Clean Separation of Control Flow and State Synchronization: The function's return value (true) serves purely as a control-flow gate to close the dialog. To remove the project card from the background UI, the server transmits a standard deleteSurface or updateDataModel message. There is no ambiguity between an event responsePath side effect and explicit surface teardown messages.
  • Exception Short-Circuiting: If deleteProject is nested within a validation chain (e.g., deleteProject(verifyAdminToken())), an error in token verification short-circuits the call before the deletion request ever leaves the client.

---

6. Comparison Table and Migration Guide

6.1 Architectural Comparison

Dimension	A2UI v0.9 (Stable)	A2UI v1.0 (Draft ActionResponses)	New Proposal: Server-Side Functions
Event Dispatch (action.event)	Asynchronous, fire-and-forget (name, context).	Adds wantResponse, actionId, and responsePath.	Preserves v0.9: Asynchronous, fire-and-forget. Removes all draft v1.0 response properties.
Execution vs. Call Boundary	Implies client execution; callFunction implies server caller.	Confuses execution and invocation in event flags.	Orthogonal: executedAt (client | server) vs. callableFrom (clientOnly | serverOnly | clientOrServer).
RPC Mechanism	None (client-initiated); callFunction (server-initiated).	actionResponse message keyed by actionId.	callServerFunction / serverFunctionResponse keyed by functionCallId.
Schema Contract on Returns	N/A	Informal: value is untyped any on the wire.	Formal: Explicit JSON Schema in catalog returnType and errors.
State Mutation Model	Explicit updateDataModel message.	Redundant: updateDataModel + automatic responsePath writes.	Single Responsibility: updateDataModel handles state; functions return pure RPC values.
Error Expression	Flat string code and message.	Flat string code and message.	Structured: Supports formal JSON Schema error details and short-circuit exception propagation.

6.2 Migration Guide

From A2UI v0.9 to this Proposal

1. Existing Actions Unchanged: No changes are required for existing action.event or local action.functionCall components.
2. Adding Server-Side Functions: To define a server-side query or check, add a FunctionDefinition to the catalog with "executedAt": "server", "callableFrom": "clientOnly" (or "clientOrServer"), an args schema, and a returnType schema.
3. Binding Components: Replace action.event with action.functionCall on buttons or inputs that require synchronous server returns or validation checks.

From Draft A2UI v1.0 (wantResponse / responsePath) to this Proposal

1. Remove wantResponse and responsePath: Delete "wantResponse": true and "responsePath" from all action.event blocks.
2. Convert to Catalog Functions: For each action that requested a response, declare a corresponding server-side function in the catalog:
   • Move the event's context schema to the function's args schema.
   • Define the expected return shape in the function's returnType schema.
   • Specify "executedAt": "server".
3. Update Agent Handlers: Replace agent-side actionResponse message generators with serverFunctionResponse handlers that respond to callServerFunction requests.
4. Decouple Data Model Updates: If an action previously relied on responsePath to mutate application state across multiple components, replace that side effect with an explicit updateDataModel message from the agent.

[jacobsimionato]

Architectural Refinement: Phased Model & Polymorphic @serverCall System Function

Based on further design discussion, we are refining the proposal into a two-phase evolutionary model that enables immediate, dynamic server-side function calling while preserving 100% polymorphism and function nesting from Day 1, without requiring immediate catalog schema declarations.

---

1. Motivation for the Phased Approach

In shared or multi-tenant ecosystems (such as the standard basic catalog used across many agents and renderers), requiring every backend check (e.g., checkUserId, validateOrder) to be statically declared in the catalog with rigid argument schemas creates friction.

• An agent knows how to handle its own server-side functions; the client renderer does not need to know or validate the argument types in advance.
• All the client renderer needs to do is recognize a server-side function call, transmit the callServerFunction RPC message with the evaluated arguments, await the serverFunctionResponse, and return the result to the caller (or raise a runtime type error if the returned shape is incompatible with where it is used).

---

2. Phase 1: Dynamic Server Calls via the @serverCall System Function (v1.0)

Instead of introducing a separate "serverFunctionCall" property on the Action schema (which would break uniform function nesting), we introduce a built-in system function using A2UI's reserved @ prefix: @serverCall (or @callServer).

2.1 The @serverCall Schema

@serverCall is a standard A2UI FunctionCall object whose arguments specify the remote function name and an untyped dictionary of arguments:

{
  "call": "@serverCall",
  "args": {
    "name": "checkDeviceAuthorization",
    "args": {
      "deviceId": "dev_123"
    }
  }
}

• name (string, required): The name of the server-side function registered in the agent's Inference SDK.
• args (object, optional): An untyped key-value map of arguments passed to the server function. Values can be literals, data-model bindings (${/path}), or nested FunctionCall objects.
• Return Value: Untyped (any in Phase 1).

2.2 Polymorphic Nesting

Because @serverCall is a standard FunctionCall, client and server functions can be composed inside argument expressions freely:

• Client inside Server: Passing the result of a local client function getLocalDeviceId() into a remote server function checkDeviceAuthorization:

  {
    "call": "@serverCall",
    "args": {
      "name": "checkDeviceAuthorization",
      "args": {
        "deviceId": {
          "call": "getLocalDeviceId",
          "args": {}
        }
      }
    }
  }

• Server inside Client: Passing the result of @serverCall into a local client utility formatBadgeLabel:

  {
    "call": "formatBadgeLabel",
    "args": {
      "tier": {
        "call": "@serverCall",
        "args": {
          "name": "getUserSubscriptionTier",
          "args": {
            "userId": "${/user/id}"
          }
        }
      }
    }
  }

2.3 Runtime Evaluation & Short-Circuit Semantics

1. Innermost Evaluation First: The client's expression evaluator recursively resolves innermost arguments first. Any client-side functions in the argument tree execute locally on the renderer.
2. Short-Circuit on Error: If any function in the chain (client or server) returns an error, evaluation is immediately abandoned. Downstream functions are never invoked, and the error propagates directly to the calling component or SDK handler.
3. Wire Dispatch: When the evaluator reaches @serverCall, it generates a unique functionCallId, suspends evaluation of the outer expression, and transmits the callServerFunction RPC message. Once serverFunctionResponse arrives, it injects the returned value into the outer expression and resumes evaluation.

2.4 Agent Inference SDK Integration (Source of Truth)

In Phase 1, server-side functions are registered directly in the agent's Inference SDK:

# Example: Python ADK / Inference SDK registration
@agent.server_function(
    description="Validates if a user ID exists and returns their account tier."
)
def check_user_id(user_id: str) -> dict:
    user = db.lookup(user_id)
    if not user:
        raise ServerFunctionError(
            code="USER_NOT_FOUND",
            message="User ID does not exist in the database."
        )
    return {"isValid": True, "tier": user.tier}

• LLM Tool Registry: During inference, the SDK formats check_user_id into the LLM's system prompt or tool context. The LLM can generate a UI payload using the generic basic catalog while attaching "call": "@serverCall", "args": { "name": "check_user_id", ... }.
• Clean Shared Catalogs: Shared catalogs remain 100% generic without needing to define backend-specific checks.

---

3. Phase 2: Formal Catalog Contracts (Future Spec Version)

In a subsequent specification release, catalogs can optionally declare server-side functions ("executedAt": "server") to formalize contracts between independent client and server teams:

{
  "functions": {
    "checkUserId": {
      "executedAt": "server",
      "callableFrom": "clientOnly",
      "args": {
        "type": "object",
        "description": "Optional in Phase 2: allows optional validation of outbound arguments.",
        "properties": {
          "userId": { "type": "string" }
        }
      },
      "returnType": {
        "type": "object",
        "description": "Required in Phase 2: formalizes what the client UI can expect from the server.",
        "properties": {
          "isValid": { "type": "boolean" },
          "tier": { "type": "string" }
        },
        "required": ["isValid"]
      }
    }
  }
}

• Backward Compatible: Existing Phase 1 usage (@serverCall) remains supported.
• Optional Runtime Validation: When a catalog declares "executedAt": "server", the client runtime can either validate @serverCall return values against returnType, or allow calling the function directly by its registered name ({ "call": "checkUserId", ... }) with automatic server routing.

---

4. Summary of Benefits

Dimension	Phase 1: @serverCall (v1.0)	Phase 2: Catalog Contracts (Future)
Polymorphism & Nesting	100%: @serverCall is a standard FunctionCall and nests uniformly with client functions.	100%: Retains full expression nesting and composition.
Shared Catalog Hygiene	Clean: Generic catalogs (basic) do not declare backend checks.	Structured: Catalogs can optionally define formal contracts for domain libraries.
Client Overhead	Zero Schema Parsing: Client acts as a lightweight RPC dispatcher (callServerFunction / serverFunctionResponse).	Verifiable: Client tooling can optionally lint or validate return shapes.
LLM Integration	Direct: Inference SDK registers functions and exposes tool definitions to the LLM at inference time.	Unified: Can auto-generate Inference SDK tool definitions directly from formal catalog schemas.

[gspencergoog]

So, what does it mean to have a function that is executedAt: server and callableFrom: serverOnly? (note: should be agent, and agentOnly with new terminology). Does this never reach the client at all?

What notices that it needs to be called, and how is it triggered? The ones that are rendererOnly and execute on the renderer make sense, because that's where the UI is, and the user can interact with it, but I just don't see how the server side equivalent gets called.

[gspencergoog]

I actually think that the executedAt and callableFrom fields should be combined into one field, with the following allowed values for an enum field called executionMode:

• rendererLocal (or just renderer?): Implemented on the renderer; called locally by UI components (e.g., local form formatting, client validation). Default value.
• agentRPC: Implemented on the agent; called by the renderer UI via callServerFunction (e.g., server validation, autocomplete, backend checks).
• rendererRPC: Implemented on the renderer; called remotely by the agent via callFunction (e.g., client environment queries, local UI triggers).

Then the confusing "agent executes agent only function" possibility is avoided altogether.

And even better, I'd like to consolidate callServerFunction (n.b. should be callAgentFunction) and callFunction into one mechanism and just call it callFunction on both sides, since they use the same payload and response and serve the same purpose.

[wrenj]

This might be easier to discuss on docs or VC, couple comments

1. server functions definitions can't go in the component catalog, since the client doesn't know what server functions are available (the agent could even make them up at runtime). You could put the server function schemas in the updateComponents I guess.
2. I understand the appeal of using the same RPC code for client and server, but in remote-ui-events people hated having the same terminology for each direction. Conceptually people wanted different terms (right now we have functions are on client and actions are on server)
3. We need responsePath to get away from having the agent write custom code to manipulate the updateDataModel. GetTypeAheadSuggestions -> MCP Tool for TypeAhead -> Response goes into responsePath. Without responsePath you have the agent write code to intercept the MCP Tool response and issue an updateDataModel (doesn't work with MCP), then we have out of order delivery, complexity when the getTypeAhead is in a templated list of components (now the agent has to track which index the component is at), etc.

[gspencergoog]

server functions definitions can't go in the component catalog, since the client doesn't know what server functions are available (the agent could even make them up at runtime). You could put the server function schemas in the updateComponents I guess.

The renderer does need to know which functions are agent-side functions somehow though, at least enough so it knows how to validate the A2UI (and where to try and execute the function when called).

[wrenj]

server functions definitions can't go in the component catalog, since the client doesn't know what server functions are available (the agent could even make them up at runtime). You could put the server function schemas in the updateComponents I guess.

The renderer does need to know which functions are agent-side functions somehow though, at least enough so it knows how to validate the A2UI (and where to try and execute the function when called).

right now the agent tells the client to execute the function on server, and the agent is responsible for validating everything. I could see letting the agent send its function schema to the client for more validation. That's how MCP Apps works (I think): the iframe can call tools on the MCP server