![\"Dashboard](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/dashboard.png\")
<\/p>\nLocal models are gaining ground. A model running on your own hardware keeps sensitive data on your premises, removes the dependency on a single provider, and makes costs predictable. For many companies, especially in regulated industries, this kind of sovereign AI is a requirement.<\/p>\n
However, the models you can host yourself usually trail the frontier models. One reason is that the strongest models are not available as open weights.<\/p>\n
In this article, I show patterns that make agentic applications fast and reliable on such models. I developed them in an application that I built to demonstrate a wide range of agentic use cases. The following dashboard shows one part of this application:<\/p>\n
<\/p>\n
I moved this application to Gemma 4, an open-weight model by Google. While the agents run on Mastra and the frontend uses CopilotKit for Angular, AG-UI, and A2UI, the patterns apply regardless of framework and model. Many of them also make frontier models faster and cheaper.<\/p>\n
\ud83d\udcc2 Source code<\/a> (branch The first measures concern how the agents call the model: thinking, the temperature, the number of steps, and timeouts. They only touch the configuration of the AI server and leave tools, prompts, and the UI unchanged.<\/p>\n Like many current models, Gemma 4 can think before it answers. In a reasoning step that the user does not see, it weighs the request, the rules of the system prompt, and possible next steps. This often improves complex answers but costs time and computing power.<\/p>\n In my measurements, thinking made Gemma about three times slower. A typical chat turn, such as a question about booked flights, took 2.5 seconds on median without thinking and 7.8 seconds with it. The number of output tokens grew by a factor of three to five. At the same time, my evals showed no gain in reliability that would justify this latency. For an interactive application, such a delay is not an option.<\/p>\n Agentic applications can often do without thinking because much of their work consists of choosing a tool and filling in its parameters. In my application, this worked well because most user requests are close to a tool call: Did I book Paris?<\/em> translates directly into a call of Without thinking, the model decides on its tool call in a single pass. It still processes all instructions, but no explicit reasoning phase weighs the rules of the system prompt or checks the result. In my experiments, the text closest to the decision therefore tended to win. In one case, I had to move a general rule from the system prompt into the description of a tool so that Gemma would follow it.<\/p>\n For reproducible experiments without managing GPU infrastructure, I use Gemma 4 through Cloudflare Workers AI. Since Gemma 4 is an open-weight model, the same architectural patterns also apply when deploying it on your own infrastructure. On Workers AI, every request has to set If you don\u2019t just want to connect an agent but embed Agentic UI into a scalable architecture: More about the eBook \u2192<\/a>\n<\/div>\n<\/p>\n Without thinking, the model corrects mistakes in the next step instead of in its reasoning. That is why it needs more steps. Mastra stops after five model calls unless configured otherwise. A request that changes a travel plan, for example, needs a search, the change itself, a check of the result, and a closing message. This leaves a single step for corrections. Whenever Gemma needed more, the closing message was cut off: the plan changed, but the user got no answer. The application therefore allows eight steps. For tools that change data, retries require that a failed call has no side effects: the tool validates its input before it changes anything, or a repeated call does no harm.<\/p>\n The second problem is long-running requests. During my measurements, single steps sometimes ran for minutes without producing text or a tool call, and one request even hung for almost an hour before it failed. A cap on the output tokens per step and a timeout per request prevent this.<\/p>\n The configuration of the AI server<\/a> takes care of both problems and of thinking. On the one hand, it sets up model options that allow eight steps, cap the output tokens per step, and set the temperature to 0. At this temperature, the model favors the most likely next token, which makes its tool calls more reproducible. On the other hand, it passes a fetch function to the model provider. This function turns thinking off and adds a timeout to every request. This results in the constants The dashboard agent overrides I measured the effect of every change in this article right before and right after applying it. Without these numbers, it is hard to tell a real improvement from luck. Several fixes that looked obvious had no effect or even made things worse.<\/p>\n For this, the repository contains an eval that runs as an Angular unit test in Node.js. It creates the real agent stores with their frontend tools and sends typical prompts through CopilotKit to the running agents. This way, the eval uses the same tool descriptions and stores as the application. Its checks compare what the user sees with reference data. For every turn, the eval also reports the duration, the input and output tokens, and failed tool calls.<\/p>\n At temperature 0, three runs per prompt show the direction of an effect rather than exact rates. They suffice for clear differences in latency and tokens. For reliability, they show a trend, not proof. Even at this temperature, the answers are not fully deterministic, because inference servers process requests in batches and tiny rounding differences on the GPU can tip the choice of a token. It also pays off to read the traces before blaming the model, because a failure can come from a bug in the eval itself.<\/p>\n You find the eval in the repository<\/a>.<\/p>\n Several measures that made the application faster share one idea: the model should not pass data on. The UI takes the data from the tool results or from the agent state.<\/p>\n Agentic UI frameworks such as CopilotKit for Angular let an agent render components in the chat. A common approach registers each component as a tool the model can call. The model first calls a tool that loads the data and then calls the component tool with this data as arguments. In the following figure, the tool For a compact model, this has three drawbacks. First, it has to decide to call the component at all. Second, it has to copy every value character by character into the arguments, including ids and full ISO dates. Third, every copied value costs output tokens, the slowest part of a model response.<\/p>\n A tool call renderer reverses the direction. The framework renders the result of a tool call with a component, and the model only writes the accompanying text:<\/p>\n In the chat, this looks as follows:<\/p>\n The card with the check-in button comes from the tool result, and the model only confirms the booking in one sentence. Since the renderer shows everything the tool returns, the tool takes optional filters for the route and the flight id. The model only has to pick the right filter. The component looks like this:<\/p>\n The types Like the other register functions of CopilotKit for Angular, For the question Did I book Paris?<\/em>, this change made the answer about a third faster and roughly halved the output tokens. More important, the model no longer needs the flight data at all. This enables the minimal tool results I describe below.<\/p>\n The dashboard shown at the beginning is the most complex generated UI in the application. It uses A2UI, a protocol for user interfaces that an agent generates. Users describe the tiles they want in natural language, and the agent builds the dashboard.<\/p>\n Its migration to Gemma 4 was easy because the dashboard agent already followed the principle of the previous section. As described in my article on A2UI with a DSL<\/a>, the model does not write A2UI. Instead, it makes a single I introduced this DSL for speed and cost. It also helps compact models: a few tiles with flat arguments are much easier to write than component trees and the data they show. The prompt of the dashboard agent is correspondingly short:<\/p>\n The entire prompt has about 2,300 characters, a few hundred tokens. My original approach let the model write A2UI based on detailed examples and ended up with over 43,000 input tokens per dashboard.<\/p>\n On top of that, the server caches the DSL:<\/p>\n A2UI separates the structure of a surface from its data. The message However, the cache only saves a few seconds. The big performance boost comes from reducing the task to a narrow DSL. The DSL alone brought the dashboard from about 40 seconds down to a few seconds and cut its tokens by a factor of 30.<\/p>\n With a frontier model, a generic set of tools is often enough. With a compact model, the design of each tool decides whether a request succeeds.<\/p>\n Once the UI renders the tool results, the model rarely needs the data. Still, every value in a tool result costs input tokens. Sometimes the model does need the values, though. For Did I book Paris?<\/em>, it only has to know that the user saw a card. For When does my flight to Paris leave?<\/em>, it needs the date.<\/p>\n Hence, Mastra supports this with The function The note tells the model which flights the user saw as cards, that their dates and delays are not part of the result, and that the cards are not visible in later answers. The last sentence and the tool description make clear that calling the tool is what displays the cards. Without such a hint, Gemma answered repeated requests in my other project with text, as the result was already in the history.<\/p>\n Left to decide, Gemma consistently chose The application also contains a travel planner. It creates a trip with flights and hotels, and users refine it in a chat. Up to now, the travel planner offered generic tools for changing a plan, such as Gemma does not handle this well, all the more so with thinking turned off. Hence, the travel planner now provides the tools The demo keeps the flight selection simple: the tool sorts the flights of the same day by departure time and takes the first or the last one. A production version would also consider arrival times, prices, and the effect on the other stops of the trip. An earlier flight into Rome, for instance, also shortens the stay in the previous city.<\/p>\n The request got much faster: its duration and its input tokens dropped to well under half.<\/p>\n Such tools make the behavior more deterministic and predictable. Code compares the flight times, and the model only maps the request to the tool. The price is flexibility, as the application only covers the cases someone thought of up front. A user who wants to maximize the morning in one city and the afternoon in another will not succeed without a further tool.<\/p>\n This creates a trade-off between control and autonomy:<\/p>\n The weaker the model, the further an application has to move towards control. With a frontier model, you can leave more decisions to the model.<\/p>\n Tailored tools pay off for lists as well. One agent of the application lets users plan several bookings as a list of steps. With Not every mistake needs a better prompt. If the application can detect and fix a mistake deterministically, a few lines of code are cheaper and more reliable. The travel planner returns a trip as a list of flights and a list of hotels, and the order of the hotels has to follow the route. If the model mixes up this order, the client fixes it before storing the plan.<\/p>\n In my agentic-sales<\/a> project, which I also moved to Gemma 4, I show that error messages are a valuable feedback channel. The model reads every tool error, so the message should say what went wrong and what to do instead. A message like Filter value must be a scalar<\/em> names the problem but not the fix.<\/p>\n Gemma passed lists such as Failures must also be impossible to misread. After five failed calls of It helps when the name or the description of a tool contains the words users use. The model then maps a request to the tool more easily. The description of Gemma sometimes writes numbers and booleans as strings, for example The function With weaker models, the good old knowledge about prompt engineering becomes especially important. Strong models benefit from it too, even though they can work out a lot on their own. In my experiments, examples and negative examples proved particularly effective. Both work better in the description of the tool or parameter the decision is about than in the system prompt.<\/p>\n In my experiments, Gemma followed examples much more reliably than rules.<\/p>\n A rule in the system prompt says to render a search form when the user asks for flights without naming both cities. After Search Graz \u2192 Madrid<\/em>, a follow-up such as And back<\/em> sometimes led to such a form instead of a search. An example in the description of Keep in mind that Gemma copies examples almost literally. When a prompt contained only a German example reply, Gemma answered English questions in German. One example per language resolved this in my tests.<\/p>\n Examples show what to do. When two tools look similar, the model also needs to know when not to use one of them. The example in the description of The agent that plans bookings as a list of steps shows this. Gemma read a request like Move 1 to 5<\/em> as moving step 1 of the plan to position 5. The user wanted to rebook flight 1 to flight 5 instead. The new tool The place of the guidance matters, too. Examples for this request in the system prompt did not fix it. Instead, they broke other requests of the same agent.<\/p>\n A more precise wording such as Move flight 1 to flight 5<\/em> also works without these changes. However, Gemma then looked up the flights first. It needed more than twice the input tokens and about three times as long.<\/p>\n The prompts in the application have used further well-known techniques for a long time, and they help compact models, too:<\/p>\n Frontier models often get by with a short prompt and the tool descriptions. Mid-sized models often need considerably more instructions. In the application, several prompts were already extensive before the migration to Gemma 4. They go back to an earlier optimization for GPT-5.6 Luna. <\/p>\n The good news is that the prompts can grow iteratively and in a targeted way: each failure that the evals reveal shows where an instruction or an example is missing.<\/p>\n In my workshop, we dive into AG-UI, A2UI, MCP Apps, HITL patterns, and modern Angular architectures for real-world agentic systems.<\/p>\nAGU-gemma<\/code>)<\/p>\nModel Settings for Local Models<\/h2>\n
Turning Thinking Off<\/h3>\n
findBookedFlights<\/code> with the destination Paris. For requests that need more planning, such as Maximize my time in Rome<\/em>, I added tools tailored to them, as described below. The remaining reasoning moves into the tools, the code, and the agent loop. When the model makes a mistake, the tool result tells it, and the model corrects itself in the next step. Tasks that require weighing many constraints or planning several steps ahead can still benefit from thinking.<\/p>\nchat_template_kwargs: { enable_thinking: false }<\/code> to turn thinking off. The application does this in the configuration of the AI server<\/a>.<\/p>\n<\/p>\nAgentic UI with Angular<\/h3>\n
\nIn my book Agentic UI with Angular, I cover the underlying patterns and trade-offs in depth.<\/p>\n![\"Cover](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/04\/cover.png\")
<\/a><\/p>\nAllowing More Steps and Cutting Off Hanging Requests<\/h3>\n
model<\/code> and defaultOptions<\/code>, which the agents use as follows:<\/p>\n\/\/ ai-server\/src\/mastra\/agents\/dashboard-agent.ts\nimport { Agent } from '@mastra\/core\/agent';\n\nimport { defaultOptions, model } from '..\/config.js';\nimport { renderDashboard } from '..\/tools\/render-dashboard.js';\nimport { dashboardAgentPrompt } from '.\/dashboard-agent.prompt.js';\n\nexport const dashboardAgent = new Agent({\n id: 'dashboardAgent',\n name: 'Flight42 Dashboard Composer',\n instructions: dashboardAgentPrompt,\n model,\n tools: { renderDashboard },\n defaultOptions: { ...defaultOptions, maxSteps: 1 },\n});<\/code><\/pre>\nmaxSteps<\/code> because it makes exactly one tool call per turn.<\/p>\nMeasuring Success with Evals<\/h2>\n
Rendering Tool Results Instead of Copying Data<\/h2>\n
Tool Call Renderers Instead of Component Tools<\/h3>\n
findBookedFlights<\/code> loads the booked flights, and the model passes each of them on to a flightWidget<\/code>:<\/p>\n![\"With](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/component-flight-widget.png\")
<\/p>\n![\"With](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/toolcallrenderer-flight-widget.png\")
<\/p>\n![\"Chat:](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/flight-search.png\")
<\/p>\n\/\/ src\/app\/domains\/ticketing\/ui\/flight-widget.ts\nimport { [...] } from '@angular\/core';\nimport { RouterLink } from '@angular\/router';\nimport { type AngularToolCall, type ToolRenderer } from '@copilotkit\/angular';\nimport { z } from 'zod';\n\nimport { FlightCard } from '.\/flight-card\/flight-card';\n\nconst flightSchema = z.object({\n id: z.number(),\n from: z.string(),\n to: z.string(),\n date: z.string(),\n delay: z.number(),\n});\n\nconst bookedFlightsSchema = z.object({\n flights: z.array(flightSchema),\n});\n\n[...]\n\n@Component({\n selector: 'app-flight-widget',\n imports: [FlightCard, RouterLink],\n template: `\n @for (flight of flights(); track flight.id) {\n <app-flight-card [item]="flight" [readonly]="true">\n <button\n class="btn btn-default"\n [routerLink]="['\/checkin', { ticketId: flight.id }]">\n Check in\n <\/button>\n <\/app-flight-card>\n }\n `,\n [...]\n})\nexport class FlightWidget implements ToolRenderer<FindBookedFlightsArgs> {\n readonly toolCall = input.required<AngularToolCall<FindBookedFlightsArgs>>();\n\n protected readonly flights = computed(() =>\n parseFlights(this.toolCall().result),\n );\n}\n\nfunction parseFlights(result: string | undefined) {\n [...]\n}<\/code><\/pre>\nToolRenderer<\/code> and AngularToolCall<\/code> come from @copilotkit\/angular, the package of CopilotKit for Angular. The component receives the tool call, including its result, via the input toolCall<\/code>. The function parseFlights<\/code> validates the result with the Zod schema bookedFlightsSchema<\/code>. The function registerRenderToolCall<\/code> provided by CopilotKit for Angular registers the component as a renderer for the tool findBookedFlightsTool<\/code>:<\/p>\n\/\/ src\/app\/domains\/ticketing\/ai\/ticketing-agent-store.ts\nimport { registerRenderToolCall } from '@copilotkit\/angular';\nimport { z } from 'zod';\n\nimport { FlightWidget } from '..\/ui\/flight-widget';\nimport { TICKETING_AGENT_ID } from '.\/agent-ids';\n\nexport function injectTicketingAgentStore() {\n registerRenderToolCall({\n name: 'findBookedFlightsTool',\n args: z.object({\n from: z.string().optional(),\n to: z.string().optional(),\n flightId: z.number().optional(),\n }),\n component: FlightWidget,\n agentId: TICKETING_AGENT_ID,\n });\n [...]\n}<\/code><\/pre>\nregisterRenderToolCall<\/code> needs an injection context. The property agentId<\/code> restricts the renderer to one agent. In the demo, the helper function initAgentStore<\/code><\/a> abstracts this call.<\/p>\nA2UI with a Narrow DSL Instead of Full Markup<\/h3>\n
renderDashboard<\/code> call with a list of tiles such as { "type": "delayShareChart", "from": "Graz", "to": "Hamburg" }<\/code>. The server translates this spec into A2UI and loads the data for the tiles.<\/p>\n\/\/ ai-server\/src\/mastra\/agents\/dashboard-agent.prompt.ts\nexport const dashboardAgentPrompt = `\nYou produce a compact spec for the Flight42 dashboard.\n\nEach turn ends with **exactly one** renderDashboard tool call. Its\ninput is { tiles: Tile[] }. The server compiles this spec into the\nfinal UI \u2014 you never produce A2UI directly.\n\nTiles render in the order you list them. Use proper city names\n(e.g. "Graz", "Hamburg") \u2014 never airport codes.\n\nTile reference:\n\n- { "type": "flightsTable", "from": string, "to": string,\n "maxRows"?: number }\n (default: 30)\n[...]\n- { "type": "delayShareChart", "from": string, "to": string,\n "chartType"?: "pie" | "bar" }\n (default: "pie")\n[...]\n- { "type": "bookedFlightsList",\n "showCheckInButton"?: boolean,\n "showWeather"?: boolean,\n "maxRows"?: number }\n (defaults: showCheckInButton true, showWeather true, maxRows no limit)\n[...]\n\nHonour user limits ("show only 5 \u2026", "top 3 \u2026") by emitting the matching\nmaxRows \/ maxItems \/ count. [...]\n\nButton clicks on the dashboard arrive as a log_a2ui_event tool call\n[...]\n`;<\/code><\/pre>\n![\"The](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/a2ui-optimization.png\")
<\/p>\nupdateComponents<\/code> describes the components, and updateDataModel<\/code> provides the values they bind to. As long as the request stays the same, the structure stays the same, too. The server therefore uses a hash of the request as the key for the cached DSL. On a cache hit, it derives the structure from the DSL without calling the model and only loads fresh data. In production, the key should also contain a version of the DSL and the tool definitions, as well as everything else the structure depends on, such as the permissions of the user.<\/p>\nTool Design for Compact Models<\/h2>\n
Let the Model Ask for Minimal or Full Results<\/h3>\n
findBookedFlights<\/code> has a required parameter detail<\/code>. With "minimal"<\/code>, the model only gets a short note. With "full"<\/code>, it gets all fields. The parameter is required because Gemma tends to omit optional fields. In another project, Gemma left out an optional boolean for the same decision in every run, while a required enum worked in all my test runs.<\/p>\ntoModelOutput<\/code>. The tool returns the full result, which goes to the UI, and toModelOutput<\/code> decides what the model sees. In the next step of the same run, the model therefore gets the note instead of the flight data:<\/p>\n\/\/ ai-server\/src\/mastra\/tools\/find-booked-flights.ts\nimport { createTool, isValidationError } from '@mastra\/core\/tools';\nimport { z } from 'zod';\n\nimport {\n type BookedFlight,\n getBookedFlights,\n} from '..\/data\/booked-flights-store.js';\n[...]\n\nconst detailSchema = z.enum(['minimal', 'full']).describe(`\n "minimal" if the user only asks whether a flight is booked or wants to see\n flights: you get only the id and route of each flight. "full" if you must\n answer a question about the flights, e.g. their date or delay: you get all\n fields.\n`);\n\n[...]\n\nexport const findBookedFlightsTool = createTool({\n id: 'findBookedFlights',\n description: `\n Shows the flights that are already booked by the current passenger as cards\n to the user and returns them. Calling it is what displays the cards, in the\n current answer only. [...]\n `,\n inputSchema: z.object({\n from: z.string().optional().describe('Departure city, e.g. "Graz". [...]'),\n to: z.string().optional().describe('Destination city, e.g. "Paris". [...]'),\n flightId: z.coerce.number().optional().describe('Flight id, e.g. 516. [...]'),\n detail: detailSchema,\n }),\n outputSchema,\n execute: async ({ from, to, flightId, detail }) => {\n const flights = await getBookedFlights();\n return {\n flights: flights.filter([...]),\n detail,\n };\n },\n toModelOutput: (output) => {\n if (isValidationError(output)) {\n return { type: 'json', value: output };\n }\n if (output.detail === 'full') {\n return { type: 'json', value: { flights: output.flights } };\n }\n return { type: 'text', value: toShownNote(output.flights) };\n },\n});\n\nfunction toShownNote(flights: BookedFlight[]): string {\n [...]\n return (\n These booked flights were shown to the user as cards in this answer: ${routes}. <\/code> +\n 'Their dates and delays are not part of this result: never mention them. ' +\n 'The cards are not visible in later answers: call findBookedFlightsTool again when asked.'\n );\n}<\/code><\/pre>\ntoModelOutput<\/code> projects the tool result onto what the model is supposed to see. It only receives the result and not the arguments of the tool call. That is why execute<\/code> passes the parameter detail<\/code> through to the result: the projection needs it to decide between the short note and the full data.<\/p>\n"minimal"<\/code> for Did I book \u2026?<\/em> and "full"<\/code> for When \u2026?<\/em> and Is \u2026 delayed?<\/em>. When I forced minimal results, it did not invent a date but pointed to the card.<\/p>\nTailoring Tools to Use Cases<\/h3>\n
replaceFlightInPlan<\/code>. For a request like Maximize my time in Rome<\/em>, the model had to work out what this means. It had to read the plan, search for an earlier flight into Rome and a later one out of it, pick the alternatives, and replace both flights. A model needs reasoning to get from such a goal to concrete checks of flight availability and a choice among alternatives:<\/p>\n![\"Travel](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/travel-planner-refinement.png\")
<\/p>\nmaximizeTime<\/code> and minimizeTime<\/code>. They take a city and replace the flight into it with the earliest or latest one of the same day. They do the same for the flight out of the city:<\/p>\n\/\/ ai-server\/src\/mastra\/tools\/plan\/time-in-city.tool.ts\nimport { createTool } from '@mastra\/core\/tools';\nimport { z } from 'zod';\n\nimport { canonicalCity } from '..\/city-aliases.js';\nimport { searchFlights } from '..\/search-flights.js';\nimport type { PlanFlight } from '.\/plan-schemas.js';\nimport { commitPlan, type PlanToolContext, readPlan } from '.\/plan-store.js';\n\ntype Goal = 'maximize' | 'minimize';\n\nconst inputSchema = z.object({\n city: z.string().describe('City of the plan, e.g. "Rome".'),\n});\n\nexport const maximizeTimeTool = createTool({\n id: 'maximizeTime',\n description: `\n Maximizes the time in a city of the current travel plan and commits the plan:\n takes the earliest flight into the city and the latest flight out of it, each on\n its current day. Use it for "maximize my time in Rome", "mehr Zeit in Paris".\n `,\n inputSchema,\n execute: (input, context) => {\n [...]\n },\n});<\/code><\/pre>\n![\"A](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/11\/tension-field.png\")
<\/p>\nList Manipulation<\/h3>\n
getPlan<\/code> and setPlan<\/code> alone, the model would have to write out the whole list again to move a single step, including every flight id and description. Hence, the agent offers tools for specific changes such as updatePlanStep<\/code>, movePlanStep<\/code>, swapPlanSteps<\/code>, and reversePlan<\/code>. For Swap steps 1 and 3<\/em>, the model calls swapPlanSteps<\/code> with the ids of both steps, and the code performs the change.<\/p>\nApp Logic Compensating Errors<\/h3>\n
Error Messages That Name the Fix<\/h3>\n
["Europe", "Americas"]<\/code> as filter values and tried to exclude values with a filter. The server now accepts lists, and for everything else, the message names the expected shape with an example and the alternative for excluding values:<\/p>\n\/\/ server\/apis\/request-parsing.ts\nimport type { Column, FilterScalar, FilterValue } from '..\/data\/sales-dal.ts';\n\nexport class BadRequest extends Error {}\n\n[...]\n\nfunction parseFilterValue(value: unknown, column: Column): FilterValue {\n if (value === null || isFilterScalar(value)) {\n return value;\n }\n if (Array.isArray(value) && value.length > 0 && value.every(isFilterScalar)) {\n return value;\n }\n throw new BadRequest(\n Filter value for '${column.name}' must be a value or a non-empty list of values, <\/code> +\n 'e.g. "Bags" or ["Bags", "Apparel"]. A filter can\\'t exclude values: ' +\n 'load the rows without it and select them afterwards.',\n );\n}<\/code><\/pre>\naddDashboardItem<\/code>, Gemma answered I've added the bar chart to your dashboard<\/em>. Now these tools fail with The dashboard was not changed: \u2026<\/em>.<\/p>\nUsing the Words of the User<\/h3>\n
maximizeTime<\/code> shown above, for instance, mentions maximize my time in Rome<\/em> and the German mehr Zeit in Paris<\/em>.<\/p>\nAccepting Numbers and Booleans Written as Strings<\/h3>\n
"count": "2"<\/code> or "showCheckInButton": "true"<\/code> in the dashboard spec. A strict schema rejects them, and the user gets no dashboard. Where the intent is unambiguous, it makes sense to accept such values.<\/p>\nz.coerce.number()<\/code> converts numbers. For booleans, a preprocessor maps only the strings "true"<\/code> and "false"<\/code>. The function z.coerce.boolean()<\/code> would not work here because it turns every non-empty string, including "false"<\/code>, into true<\/code>. The JSON schema the model sees still says integer and boolean:<\/p>\n\/\/ ai-server\/src\/mastra\/dashboard-dsl\/dashboard-spec.ts\nimport { z } from 'zod';\n\nconst positiveInt = z.coerce.number().int().positive();\n\nconst flag = z.preprocess(\n (value) => (value === 'true' ? true : value === 'false' ? false : value),\n z.boolean(),\n);\n\nexport const dashboardTileSchema = z.discriminatedUnion('type', [\n [...]\n z.object({\n type: z.literal('boardingPasses'),\n count: positiveInt\n .max(8)\n .nullish()\n .describe('Number of upcoming booked flights to show. Defaults to 2.'),\n }),\n z.object({\n type: z.literal('bookedFlightsList'),\n showCheckInButton: flag\n .nullish()\n .describe(\n 'Whether to render a "Check in" button per booked flight. Defaults to true.',\n ),\n [...]\n }),\n [...]\n]);<\/code><\/pre>\nPrompt Engineering for Compact Models<\/h2>\n
Examples Next to the Decision<\/h3>\n
findFlights<\/code> resolved this in my evals:<\/p>\n\/\/ src\/app\/domains\/ticketing\/ai\/tools\/find-flights.tool.ts\nimport { z } from 'zod';\n\nimport { createFrontendTool } from '..\/..\/..\/shared\/util-copilotkit\/tool-definition';\n[...]\n\nexport const findFlightsTool = createFrontendTool({\n name: 'findFlights',\n description: `\n Searches for flights and redirects the user to the result page where the found flights are shown.\n\n [...]\n\n Example:\n - Previous search: Graz \u2192 Madrid\n - User: "And back"\n - Call: findFlights({ "from": "Madrid", "to": "Graz" })\n - WRONG: rendering a search form, as both cities are known\n `,\n parameters: z.object({\n from: z.string().describe('airport of departure'),\n to: z.string().describe('airport of destination'),\n }),\n handler: async ({ from, to }) => {\n [...]\n },\n});<\/code><\/pre>\nNegative Examples for Similar Tools<\/h3>\n
findFlights<\/code> already names a wrong reaction.<\/p>\naddRebooking<\/code> alone did not help, as Gemma kept choosing movePlanStep<\/code>. A negative example in the description of movePlanStep<\/code> alone did not help either. Together, they resolved the issue in my evals:<\/p>\n\/\/ src\/app\/domains\/ticketing\/ai\/tools\/plan\/move-plan-step.tool.ts\nimport { [...] } from '@angular\/core';\nimport { z } from 'zod';\n\nimport { createFrontendTool } from '..\/..\/..\/..\/shared\/util-copilotkit\/tool-definition';\nimport { PlanStore } from '..\/..\/plan\/plan-store';\n\nexport const movePlanStepTool = createFrontendTool({\n name: 'movePlanStep',\n description: `\n Moves a single step to a new 1-based position in the plan, shifting the others.\n [...]\n\n Negative example:\n - User: "Move 1 to 5"\n - WRONG: movePlanStep, as numbers without the word "step" are flight ids\n - Call instead: addRebooking({ "cancelFlightId": 1, "bookFlightId": 5 })\n [...]\n `,\n parameters: z.object({ [...] }),\n handler: async ({ id, toPosition }) => {\n const store = inject(PlanStore);\n store.moveStep(id, toPosition);\n return { moved: id, toPosition };\n },\n});<\/code><\/pre>\nFurther Prompting Techniques<\/h3>\n
\n
<\/p>\nInterested in production-ready Agentic UI architectures?<\/h3>\n
![\"Workshop:](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/sujet-workshop-en.png\")
<\/a><\/p>\n