From a One-Sentence Request to an AI-Native Service Desk for a Healthcare Group

This was not a project that simply attached a large language model to a conventional ticketing system. What actually happened was that we gave the model the parts of hospital IT service that are hardest to express and easiest to distort, then returned permissions, workflow, data, and accountability to a deterministic system.

The core of AI-native enterprise software is not replacing traditional pages with a chat box. It is redrawing the responsibilities of people, models, and systems.

The project began with a plain question: can a user say just one sentence and have the system understand what happened, what information is missing, who should handle it, and how to preserve the complete handling history?

Seventeen days later, the system had moved from a proof of concept with three agents to a mobile-ready product with traceable attachments, ticket reassignment, multi-hospital isolation, configurable prompts, real-model testing, repeatable candidate-environment validation, and low-disruption production switching. We also took plenty of wrong turns: we built and later removed project management, created duplicate tickets, hit failures on 8.5 MB uploads, found buttons that could not be tapped on phones, saw model calls exceed twenty seconds, and encountered the most typical end-to-end failure of all—the model extracted a field correctly while the page still displayed it as missing.

Those wrong turns are more worth recording than the fact that the system launched.

The starting point was not a form, but three agents

The original concept had three clear capabilities:

1. Ticket triage and assignment agent: understand the problem and select a workgroup or assignee.
2. Problem analysis and solution agent: identify difficult and recurring issues, then provide reviewable recommendations.
3. Operations reporting agent: generate daily reports, weekly reports, and operational summaries from factual data.

A fourth agent—the “self-recording agent”—was added later. It handles another kind of input that is easy to confuse with a service request: the user is not asking someone else for help, but recording a problem they personally resolved that day. Both can be described in natural language, but their business meanings are entirely different.

That starting point still holds today: different tasks use different contexts, prompts, thresholds, and models instead of assigning every responsibility to one “universal agent.”

But it quickly became clear that three agents solved only the most distinctive part of the product; they did not automatically produce a usable system. A real service desk still needs accounts, permissions, attachments, notifications, search, statuses, SLAs, audit trails, mobile support, and administrative configuration. AI is the differentiator, not an exemption from product fundamentals.

The first product convergence: let users state what they intend to do

The earliest workbench offered three entrances: automatic judgment, create issue, and update task. There were too many concepts, and they duplicated the intent recognition already inherent in natural language. We eventually reduced them to two business purposes:

• Automatic assignment: this is an issue that requires collaborative handling, so the system creates a formal ticket and executes assignment.
• Issue record: this is a problem I resolved myself today, so it is recorded under my own name without disturbing anyone else.

This simplification did not remove capability. It asked the user one meaningful question first: am I asking others to collaborate, or am I preserving my own work? Queries, updates, reassignments, reminders, and help requests can still be expressed directly to AI.

One lesson matters here: an AI product cannot lose structure merely because “natural language can express anything.” Good structure does not force users to fill in more fields; it tells them what they are doing at the key decision points.

Required information does not require a long form

Hospital IT operations eventually established the minimum information for a valid ticket:

• department;
• on-site contact or requester name;
• at least one landline/extension or mobile number;
• a comprehensible description of the request.

Employee number, consulting room, detailed location, computer name, and IP address are optional. If an extension uniquely matches the directory, the system can infer the department, room, and address. If it cannot establish a unique match, it must keep asking rather than guess.

“Required” no longer means that the user must see a form first. It means that the model’s output must contain those facts. If something is missing, each turn asks for only the single most important missing field. Before the information is complete, the system creates no ticket, binds no attachment, and performs no assignment. Even after completion, the user must still confirm.

The process eventually stabilized as:

Natural-language input
  → model extracts strict JSON
  → server validates against the hospital's current configuration
  → ask for one missing field when incomplete
  → user confirms the structured preview
  → create the ticket idempotently
  → agent triages and assigns

The most important part is not JSON. It is that the model proposes candidate facts, while code decides whether the process may enter the next state.

Assignment is harder than asking a model to name a person

Real operations require two workgroup intake modes:

Mode	How it works	What the platform must guarantee
Round-robin assignment	Assign tickets to individuals in turn among currently eligible members	Staff on leave, paused, or disabled are excluded; the cursor remains consistent
Workgroup claiming	Assign first to a workgroup, notify everyone, and give ownership to the first person who claims it	Only one concurrent claim can succeed; unread alerts for everyone else are withdrawn automatically

Staff can also reassign a ticket directly to themselves or another eligible employee. The business rule was later relaxed so that anyone who can see a ticket may reassign it—but this does not remove system boundaries. The target employee must belong to the same hospital, have an active account, and be eligible to receive tickets. Completed or cancelled tickets cannot be reassigned. The previous assignee, new assignee, reason, operator, and timestamp must all remain in the audit trail.

The easiest mistake is to put every assignment rule into the prompt and expect the model to “behave.” The correct division of labor is:

• the agent uses that hospital’s own prompt to understand its business systems and choose from a limited candidate set;
• the platform validates the hospital, workgroup, intake mode, employee status, and concurrency version;
• when the system cannot confirm the answer or the candidate is invalid, the ticket enters manual triage instead of accepting a guess.

Prompts express changeable business policy; code enforces system invariants that must never be violated.

Moving from one hospital to a healthcare group means redesigning data boundaries

The system later evolved into a healthcare-group edition. Ordinary hospital users still enter their own workbench immediately after login and can see only their hospital’s users, workgroups, tickets, attachments, agents, SLAs, extensions, and reports. A platform super administrator uses the same login entrance to reach the group overview and inspect cross-hospital operations. Before performing a write action, the administrator must enter an explicit hospital context.

Multi-tenancy is not a hospital filter added to the page. Database records, API queries, attachment objects, agent versions, imports and exports, test data, and logs all need a hospital boundary from the start. Even if an ordinary user forges a hospitalId, the server must ignore it.

This step changed how I understood ownership of AI configuration. A prompt is not one paragraph shared across the platform; it is part of each hospital’s operating policy. Hospitals differ in system names, responsibilities, workgroups, third-party operators, and service language. Their agents therefore need to be configured and published independently inside tenant boundaries.

AI-native enterprise software is a five-layer trusted system

By this point, I had developed a model more complete than an “agent architecture.”

1. Expression layer

Let clinicians, nurses, and engineers describe real situations through natural language, attachments, and mobile devices. The goal is to lower the entry barrier rather than make users understand database fields and workflow states.

2. Semantic layer

Agents recognize intent, extract JSON, classify problems, and generate analysis and reports, turning unstructured expression into candidate facts and recommendations that can be validated.

3. Governance layer

Required-field gates, hospital isolation, permissions, candidate eligibility, human fallback, and version policy convert “the model believes” into “the system permits.”

4. Transaction layer

Idempotency, database transactions, round-robin cursors, concurrent claiming, attachment authorization, and audit make every action executable, traceable, recoverable, and unable to cross its authority boundary.

5. Learning layer

Logs, evaluation sets, daily and weekly reports, recurring issues, prompt iteration, and operational review turn one resolved problem into better organizational capability the next time.

The middle two layers are the easiest to overlook. Without governance, the model can exceed authority, cross hospitals, or misassign work. Without transactions, even a correct recommendation can become incorrect data through repeated clicks, network retries, or concurrency. Chat is only the entrance; trustworthy execution is the product.

Why the model once needed more than twenty seconds

Early automatic assignment placed dozens of workgroups and third-party systems into the prompt and asked the model to choose from the complete list. The result was unsurprising: requests kept growing, average latency exceeded twenty seconds, and the model became more hesitant among similar names.

We later changed the approach to “retrieve first, reason second”:

• retrieve candidates using the ticket text, workgroup names and responsibilities, system aliases, and explicit routing statements from the prompt;
• keep at most fourteen workgroups and eight third-party systems;
• use candidates only to narrow the decision space, never to execute an assignment directly;
• let the model make the final semantic choice, then let the platform verify eligibility.

The request shrank from roughly 20.8 KB to approximately 5.4–7.8 KB, and average automatic-assignment latency returned to about four seconds. The lesson is direct: context engineering and candidate retrieval are often more effective than blindly switching to a larger model.

Not every task needs the most capable model. Field extraction, intent recognition, assignment, and issue recording have fixed outputs and shorter context, so they can use faster models. Difficult problem analysis and daily or weekly reporting require stronger synthesis and can use a more capable model. The real model name, prompt version, and elapsed time must be recorded accurately; the UI must not display a brand label that differs from production.

Concurrency did not overwhelm the server; tail latency came from the external model gateway

In an agent sandbox that does not write production tickets, I ran stepped concurrency at 1, 2, 4, 8, and 16. All 31 HTTP requests succeeded, with no 429 responses, timeouts, or first-call model failures. P50 remained roughly four to five seconds, while P95 and the maximum reached about 10.56 seconds.

The test exposed another fact: the same somewhat ambiguous description of an “AI assistant” occasionally entered manual triage instead of consistently reaching the intended group. HTTP success is not business correctness. Model tests must evaluate structured output, explicit routing, ambiguity fallback, manual-triage rate, P50, P95, maximum latency, and concurrency error rate together.

Mobile is not a smaller desktop

Many of the most valuable bugs in this system came from phones:

• hidden file inputs could not be tapped in some WeChat and hospital WebViews;
• an 8.5 MB attachment failed even though the page said uploads up to 10 MB were supported;
• dialogs were too tall, leaving the save button out of view;
• type was too small, while filters and fixed bottom bars crowded one another;
• multi-column checkbox groups pushed the entire page into horizontal scrolling.

The final principles were plain: key touch targets should be about 40–48 px; file selection should be triggered explicitly by a real button; mobile should use cards and segmented information rather than squeezing desktop tables; dialog content should scroll independently while the action area remains fixed; validation must include at least 390 × 844 plus Android WebView behavior.

There is one broader experience principle: users must be able to see what the system is doing.

Attachments need local preview, uploading, success, failure, retry, and removal states. AI needs to show that it is parsing, what is missing, what it recognized, whether it is waiting for confirmation, whether assignment is in progress, and which safe state follows a failure. Without feedback, users click again, and duplicate submission and concurrency failures follow.

Natural-language workflows require idempotency as infrastructure

The system once experienced a typical incident: the user’s follow-up had already been saved, but final confirmation created the ticket again, leaving several nearly identical tickets in the list.

The root cause was not one button. Front-end conversation state, model state, and database writes had not been separated clearly. The resulting rules were:

• the questioning stage computes only and never writes a formal ticket;
• final creation uses a stable client request ID;
• the server protects against duplicate request IDs and near-identical content within a short time window;
• network retries return the same result instead of executing again;
• write buttons enter a busy state to prevent repeated clicks.

Natural language makes workflows more flexible, but it also creates more retries, supplements, and state recovery. Idempotency is not a “back-end optimization”; it is infrastructure for agent products.

Another issue is even more instructive: “premium obstetrics clinic” appeared in the user’s original text and may already have been extracted correctly by the model, yet the detail page still showed the service location as missing. The break could occur in the model, field merging, persistence, querying, or UI. Correct model output does not guarantee a correct product result. End-to-end tests must assert from the input all the way to the final mobile display.

A test center is not there to display a passing number

The test system gradually grew into eight layers: domain unit tests, API smoke tests, focused business tests, role-based UAT, real-model evaluation, responsive validation, candidate-release verification, and non-destructive production smoke tests.

At one stage, code tests reached 336/336 and isolated candidate-environment UAT reached 87/87. The numbers themselves were not the achievement. What mattered was that every failure could answer a diagnostic question: did the model fail, was the candidate invalid, was configuration insufficient, did permissions reject the action, did a data precondition change, or did the page fail to display the result correctly?

Full regression cannot be allowed to contaminate production directories. Early tests created large numbers of UAT workgroups and test users that later required physical cleanup. The mature approach is to copy production state into an isolated candidate directory, run the complete test suite on a separate port, and destroy the copy afterward. Production receives only non-destructive checks for health, login, static assets, hospital isolation, and a read-only model sandbox.

The most valuable test samples are not ideal inputs, but what people actually do: a 10 MB boundary attachment, three rapid clicks, two people claiming the same ticket, data changing while a user remains on the page, a staff member on leave appearing as a candidate, deleting an employee still referenced by tickets, an ordinary user forging a hospital parameter, the model returning Markdown or invalid JSON, and the model gateway returning 429, 502, or a dropped connection.

The other half of a production system is deployment and observability

The earliest version depended on a personal computer and a changing network environment. Once the system truly moved to the cloud, I set several release minimums: it could not depend on a developer’s computer being powered on; it could not affect other services on the same server; full tests could not write production state; the production switch had to be as short as possible; and we needed evidence of exactly which version was running.

At the current single-server stage, releases use “candidate container + copied state + short switch.” Source and runtime configuration are first built into a versioned candidate image. The candidate mounts a copy of production state for regression. After validation, only the target application service is replaced. The health endpoint returns the release version, database, and actual model information, while front-end assets carry version fingerprints.

Simply seeing that the website loads does not prove that it is running the latest code. A complete evidence chain should be:

local Git HEAD
  = GitHub main
  = image build commit
  = health-endpoint release
  = front-end asset version
  = container and image digest in the deployment record

Observability is not something to add after an incident. Critical paths need a unified request ID and records of the stage, model, prompt version, candidate count, request bytes, duration, retry, result, and business audit event. Logs must not contain passwords, tokens, API keys, attachment bodies, or complete ticket text. Detailed logging and leaking sensitive data are not the same thing.

Small-looking failures that reveal deep system problems

Surface symptom	What it actually exposed
The page says 10 MB is supported, but an 8.5 MB file fails	Limits are distributed across the browser, multipart parser, proxy, and storage; changing front-end copy is not enough
The attachment button does nothing on a phone	Passing in a standard desktop browser does not prove WebView interaction works
One follow-up creates three identical tickets	Multi-turn flow failed to separate computation from formal writes and lacked idempotency
Department is recognized, but service location remains empty	There is no full-chain assertion across model, merge, persistence, query, and UI
Delete remains disabled indefinitely	Protective design does not explain why or give administrators a controlled cleanup path
A huge blue box appears on the password page	A generic CSS selector contaminated compact controls because component dimensions were not fixed
The same ambiguous issue occasionally enters manual triage	Model non-determinism requires candidate constraints, aliases, platform validation, and human fallback
Automatic assignment takes more than twenty seconds	Prompts and candidate lists grew without bounds; retrieve first, then reason
It is hard to tell whether local, GitHub, or production is newest	Versions cannot be inferred from release notes or file timestamps; they need runtime fingerprints

These failures share one characteristic: a screenshot usually shows only the last layer, while the root cause is hidden somewhere along the complete chain. An effective fix cannot modify only the component visible in the screenshot.

From closing one ticket to helping the organization avoid starting from zero next time

A traditional ticketing system optimizes flow efficiency: who receives the ticket, when they respond, and when it closes. An AI-native service desk should go one step further and turn every resolution into a reusable organizational asset.

When a ticket closes, it can preserve at least four kinds of content:

1. Factual data: what happened, who was affected, and in which system and location.
2. Resolution process: what was attempted, what worked, and what did not.
3. Accountability boundary: who made the judgment, who executed the action, and when reassignment and confirmation occurred.
4. Reusable knowledge: whether this is a recurring issue and whether it should become a standard solution, dictionary entry, prompt rule, or preventive measure.

Daily and weekly reports therefore cannot merely ask the model to rearrange ticket titles. They should answer more important questions: which systems fail repeatedly, which departments wait too long, which workgroups remain overloaded, which problems deserve standard solutions, and which directories or prompts need revision?

Seen this way:

• an agent prompt gradually becomes an executable operating policy;
• the test set becomes the organization’s machine-readable definition of correctness;
• the audit trail becomes the factual basis for accountability and continuous improvement;
• a ticket is no longer just a to-do item, but a digital trace of organizational operations.

The system still cannot replace accountability. Models can recommend, summarize, and rank. Platforms can execute authorized actions. Final responsibility remains with the people who confirm facts, configure policy, and resolve issues. In healthcare, this division of accountability matters more than making the model “smarter.”

Ten conclusions I would keep

1. The value of AI-native software is letting users complete work in natural language, not letting a model bypass business rules.
2. Models handle semantics; code handles permissions, consistency, and auditable execution.
3. Structure first, validate second, execute third is the most reliable backbone for multi-turn agents.
4. Candidate retrieval and context compression are often more effective than blindly switching to a larger model.
5. Mobile must be validated on real touchscreens and WebViews; passing on desktop does not prove it works on a phone.
6. User feedback reveals end-to-end failures; do not fix only the component shown in the screenshot.
7. Full regression belongs in an isolated candidate copy; production should receive only non-destructive verification.
8. Low-disruption releases, version fingerprints, and traceable logs are basic production-system capabilities.
9. A product must allow subtraction; modules built on the wrong boundary should be removed instead of patched forever.
10. Documentation is not an archive. It lets the next computer, the next AI tool, and the next maintainer take over safely.

What is most worth preserving from this build is not any one page, model, or prompt. It is a maturing method: start from real operations, use models to lower the cost of expression, use code to protect system boundaries, use tests to prove end-to-end behavior, use candidate environments to protect production, and use documentation and runtime evidence to keep the system maintainable.

AI never amplifies efficiency alone. The clearer the responsibilities, the more accurate the data, and the more complete the feedback, the smarter the system can become.