A marketing manager asks a simple question: what happens to our campaign plan if the available budget falls by twenty percent? A useful answer would let the manager change the assumption, inspect the arithmetic and compare the alternatives. Repeating the question in a chat window creates extra work if every adjustment produces another paragraph that someone must interpret manually.

OpenIntelligentUI makes that interaction worth examining. This October 14 review looks at the public developer project and proposes a bounded experiment for Gulf marketing teams. The calculator, participant plan and acceptance thresholds below are original recommendations. They are not announced product features, measured project results or a claim that the software is ready for sensitive production use.

What the official project establishes

CopilotKit's OpenIntelligentUI repository describes an open-source interface in which an agent can return text, native components or generated interactive tools. It builds on CopilotKit and AG-UI. Its license file identifies MIT licensing.

The architecture documentation describes a Next.js frontend and a Python agent using FastAPI and LangGraph. Custom interfaces render in an isolated iframe. Bundled sample data does not establish a live data connection.

The setup guide lists Node.js 22+, pnpm 9+, Python 3.12+ and uv. Answer generation and Jev visualization routing require provider access. This review does not independently test a deployed instance or establish a new release date.

Choose one decision that interaction can improve

Start with a recurring question that has explicit inputs and a checkable answer. A synthetic campaign-budget calculator is a useful candidate because a reviewer can verify every operation without connecting an advertising account. The proposed task is to compare three fictional channel allocations under a fixed spending envelope.

Keep the first version narrow. It should accept a total budget, channel shares and assumed inquiry costs, then show how the arithmetic changes when an input changes. It should not decide where a real organization must spend money. Any recommendation about a live campaign would require evidence about audience quality, capacity, creative and actual business performance that this exercise deliberately excludes.

Make the example auditable by hand

Use an invented monthly budget of SAR 30,000. Allocate SAR 15,000 to channel A, SAR 9,000 to channel B and SAR 6,000 to channel C. Give them illustrative inquiry costs of SAR 150, SAR 100 and SAR 200. The resulting arithmetic is 100, 90 and 30 inquiries, or 220 in total. Label every figure as fictional beside the result.

Now reduce the total to SAR 24,000 while preserving the shares. The outputs become 80, 72 and 24, totaling 176. This is a linear scenario under fixed assumptions, not a performance forecast. Real acquisition costs may change with spending. Ask participants to explain that distinction before accepting their task as complete.

Specify the calculation before designing the interface

Write a short calculation contract that a developer and marketer can both read. Define whether budgets include production, taxes or agency fees; for this exercise, specify media spending only. Establish one currency and one time period. State that zero assumed cost cannot produce an inquiry estimate, and that negative budgets are invalid.

Decide what happens when channel shares do not total one hundred percent. A clear validation message is preferable to silently adjusting the user's inputs. Preserve the original values so the user can correct them. Set rounding rules once, and show enough precision to reconcile the total. Test the formula independently of the generated layout, then check that every visible result uses it correctly.

Let the presentation serve the task

The routing documentation says Jev chooses a presentation for each new user message; basic tables use A2UI, while calculators and charts use Open Generative UI. The documentation explicitly treats routing as a model judgment.

For the proposed pilot, ask whether the selected display helps someone inspect the assumptions. A table may communicate the comparison more clearly than an animated chart. Require a visible input summary, units beside numbers and an explanation of the formula. Keep a plain-text result available for copying into a review note. Record unnecessary visual complexity as a usability cost rather than rewarding it for looking impressive.

Treat Arabic as a complete product requirement

An Arabic version needs its own acceptance review. Check right-to-left reading order, mixed Arabic and Latin labels, decimal separators, percentage placement and currency presentation. A slider must remain understandable when the interface direction changes. Long Arabic labels should not overlap values or hide the control that changes them.

Use the same underlying scenario in both languages, with terminology agreed by a native Arabic marketing reviewer. Ask users what they think an inquiry means. It should not quietly become a qualified lead, appointment or paying customer in translation. Test with the devices participants actually use, including narrow screens and enlarged text. Record language-specific failures separately so an acceptable English average cannot conceal an unusable Arabic journey.

Set a data boundary before inviting participants

Use fictional channel names, invented amounts and synthetic prompts throughout the exercise. Exclude patient records, symptoms, appointment details, contact lists, client reports and account credentials from the conversation. A healthcare marketing team can investigate the interface with the same fictional business scenario without asking it to make a clinical decision.

Keep the pilot away from live publishing, media buying and customer messaging systems. The experiment needs enough capability to calculate and display a comparison; additional permissions add review work without helping answer that question. Write a short participant notice explaining the permitted inputs and how to report accidental disclosure. If someone enters real information, pause that session and follow the organization's established incident process.

Inspect the whole processing path

An isolated frame answers only part of the security question. Have the technical owner map the application server, answer provider, visualization provider, hosting logs and optional monitoring services. For each destination, record what could leave the browser, who operates the service and the configuration actually tested. Keep secrets out of prompts, screenshots and generated examples.

The project's telemetry guide documents opt-out settings and distinguishes runtime telemetry from hosted-demo analytics. Review the relevant settings rather than assuming that self-hosting prevents external processing. For this pilot, use the minimum diagnostic information needed to identify failures, with a defined deletion date and a named person responsible for checking it.

Compare against an honest baseline

Prepare a conventional spreadsheet or fixed web form containing the same synthetic formula. Give it clear labels and a usable layout. Comparing an attractive generated interface with a deliberately poor baseline would answer the wrong question. The practical decision is whether generation adds enough value to justify its extra complexity.

Measure the complete journey from receiving the scenario to giving a correct explanation. Include waiting, retries, corrections and assistance. If someone finishes rapidly but misreads the result as guaranteed demand, the task has failed. A short comprehension check is therefore more useful than asking only whether the experience felt modern or enjoyable. Preserve the baseline's results so later changes can be judged consistently.

Run a small observed usability study

Invite twenty consenting adult colleagues or other appropriate test participants, with Arabic and English sessions represented. This is a proposed usability sample, not a statistically powered conversion experiment. Give everyone two equivalent scenarios and alternate which interface they use first. Different fictional amounts can reduce simple recall while retaining comparable arithmetic.

Ask participants to complete three actions: calculate a scenario, change one assumption and explain the limit of the result. Observe where they hesitate without coaching them immediately. Log assistance when it becomes necessary. Follow with a brief question about which information was missing. A researcher should distinguish a discovered defect from a personal design preference, while retaining both as useful feedback.

Count correct completion and hidden effort

Define successful completion before testing. The participant must produce the right numbers, identify the currency and period, and explain that the inputs are assumptions. Record completion without assistance, elapsed time, incorrect interpretations, retries and abandonment. Break out results by language and device rather than relying on one combined average.

Track development and review effort alongside user time. A calculator that saves each participant thirty seconds but requires frequent repairs may still be a poor investment. Include every attempt, including provider failures and broken outputs. Report medians and ranges with the small sample, and describe notable individual failures. Avoid translating a promising usability result into an unsupported claim about revenue or campaign conversion.

Test failure deliberately before widening access

Create a short set of adversarial but harmless test cases: missing currency, zero assumed inquiry cost, negative values, a total allocation above the budget and an unusually long Arabic label. Check whether the interface keeps the last valid result clearly separate from the invalid request. A polished number should never hide an unresolved input error.

Also interrupt a request and simulate a provider outage in the controlled test environment. The deployment guide notes process-memory checkpoints and process-local rate limits, which create restart and scaling considerations. Have the engineer demonstrate the actual recovery behavior of the tested configuration. Do not infer continuity from a successful first request or a healthy server status.

Calculate the cost of an accepted answer

Create a simple pilot ledger covering engineering, review, hosting and provider usage. Divide the total operating cost by successfully completed tasks, while reporting initial build effort separately. Count repeat generation caused by confusing outputs as part of cost. A low price per model request can coexist with an expensive user journey.

Estimate future demand with a range rather than a single optimistic volume. Consider whether ordinary input changes really need another model call or could use a reviewed deterministic control in the proposed implementation. Keep the choice open: the experiment may show that a conventional calculator is the better permanent solution, with conversation reserved for explaining assumptions or helping users find the appropriate tool.

Agree on the next decision before seeing results

An illustrative acceptance gate is sixteen of twenty participants completing all actions correctly without help, no unresolved calculation or disclosure failures, and a twenty percent improvement in median completion time against the baseline. These are proposed targets to discuss before the trial, not external benchmarks or reported OpenIntelligentUI performance. Require a separate Arabic review even if the combined gate is met.

If the pilot passes, authorize another bounded stage with a documented owner and review date. If it fails, identify whether the problem is arithmetic, language, interaction, reliability or cost before deciding what to change. The useful outcome is a defensible product decision. An interface earns its place when people can inspect its assumptions, recover from mistakes and finish the intended task with less effort.