Citra Self-Improving Decision Apps — UI, Agent, and Dashboard, Authored by Your BA

Every line-of-business team — claims, underwriting, vendor ops, KYC, support — needs the same three things to do their job: a real UI to handle work in front of them, an automated agent that takes the routine cases off their plate, and a live KPI dashboard that tells leadership how the queue is moving.

Today they get none of it without a developer. The BA writes a Word doc, files a ticket, waits a quarter for IT, and ends up with a portal that looks like 2014 — without the agent, without the dashboard, and obsolete the moment the policy changes.

A Citra Decision App is what closes that gap — and it's Citra's flagship product. Your business analyst describes the business outcome in plain English. A sandboxed builder agent ships a published app at apps.citra.ai/{slug} that bundles all three pieces — UI, agent, dashboard — wired to your enterprise data, governed by your tenant, deployed inside your perimeter. It recommends each decision, acts within your policy gate (auto-committing the routine calls and escalating the high-stakes ones), and learns from every outcome so next week's recommendations are sharper. No developer required.

When the consumer of a decision is another system rather than a person working a queue, the same self-improving logic ships headless as a Decision Service — the flagship's API form. Your existing systems call it to request a governed, auditable decision in-line, and it feeds the same owned operational memory as the apps. Use a Decision App when people work the queue; use a Decision Service when a system needs the call.

The three things every Decision App bundles

Worked example: motor claims auto-triage

Take the most common pain in any motor insurer's operations team: a backlog of claims, all queued for a human reviewer regardless of size. A junior reviewer spends three hours every morning approving fifty $200 windshield replacements before they get to the $15,000 collision claim that actually needed their attention.

The BA describes the business outcome they want:

"Build me an app that auto-approves motor claims under $500. Anything above that, route to my queue with a recommended decision and the policy clause it depends on. Show me a dashboard of SLA risk, monthly payout, and fraud-flag rate."

The Decision App ships. Inside an hour the BA has:

• An intake form for new claims (and a connector pulling from the existing claims system through MCP).
• An agent that classifies claim type, runs the under-$500 check, fires the policy-RAG lookup for high-value claims, and writes a recommended decision into the queue record.
• A queue UI showing only the high-value items — each with the recommended decision and the cited policy clause.
• A detail panel with embedded agent chat so the BA can ask "why this recommendation?" and get a grounded answer.
• A dashboard tracking SLA breach risk, monthly payout, fraud-flag rate, and approval throughput.
• Audit logging on every step, every recommendation, every approval — per tenant.

Three months later that team is no longer running daily three-hour triage. The morning review takes thirty minutes. The dashboard goes to the COO. The BA owns the whole thing — they tweaked the threshold from $500 to $750 last week without filing a single IT ticket.

Three more apps that look exactly the same shape

Why this isn't another no-code platform

Low-code and no-code platforms have existed for ten years. Why hasn't every BA built a claims app already? Because those platforms still require somebody to:

• Lay out screens.
• Model the data.
• Wire up actions and conditions.
• Stitch in integrations.
• Build dashboards in a separate BI tool.

That somebody is, in practice, a developer or a heavily trained power user. The BA still files the ticket.

A Decision App is different because the BA describes the business outcome — not the screens. The builder agent generates the UI, the agent, and the KPI dashboard together, coherent with each other, wired to your enterprise data. It's not a screen builder; it's an outcome builder.

What you actually get in every Decision App

Why the sovereignty story matters here too

A motor-claims app is touching policy data, customer records, and payout decisions. A vendor-KYC app is touching identity documents and financial information. These are the workloads where SaaS AI is a non-starter — and where most low-code platforms also fall down because they ship as multi-tenant SaaS hosted somewhere your security team has never heard of.

Citra Decision Apps run inside your perimeter — in your private cloud — on the same sovereign stack as the rest of Citra. The published apps.citra.ai/{slug} URL is served by your own deployment. Data doesn't egress. Models don't train on your IP. Audit log is yours.

That's why a Decision App is something a regulated business actually deploys, instead of yet another "AI app builder" that gets blocked at the security review.

Where Decision Apps fit in the Citra stack

The Agentic Layer of Citra is two-tier on purpose:

• Decision Apps — what this post is about. The BA tier. Authored in natural language, ships UI + agent + dashboard together, runs on the sovereign stack.
• Agentic Workflow Engine — the IT tier. A developer-grade canvas with AI-agentic decision nodes for complex, cross-vertical processes that need explicit composition — application screening with multi-rule scoring, multi-step decisioning, long-running flows.

Most line-of-business apps land in the Decision App tier and never need to touch the Workflow Engine canvas. When they do, the same governed data, the same tenant audit, and the same model layer underpin both — so handing off from a BA-built app to an IT-built workflow doesn't mean rebuilding on a different stack.

The honest summary

For ten years the answer to "let's give the BA a real app" was "file a ticket and wait." That was fine when shipping a portal meant a lengthy developer project and the policy didn't change for two years. Neither of those is true anymore.

Citra Decision Apps move the work where it actually belongs: the BA, who knows the business process, describes the outcome they want; the platform ships the UI, the agent, and the dashboard, all wired to enterprise data, all governed, all on your infrastructure. Weeks of manual triage become a daily review. The KPIs that used to live in a stale slide deck now live in a dashboard the BA owns.

That's the gap a Decision App closes — and it's the gap that decides whether a regulated team actually deploys an AI app, or just keeps reading slide decks about one.

Frequently Asked Questions