Services · AI & Machine Learning
LLM Application Development
LLM features built into the product you already run
What this is
What llm application development covers
LLM application development for product and platform teams adding drafting, classification, extraction, summarization, or multimodal features to an existing application. We design the prompt and model layer, the evaluation suite, and the fallback paths, then ship it behind your API with cost and latency budgets. Generative features for newsrooms, support desks, and document-heavy operations are built the same way: system of record first, model second.
Typical timeline: 6–16 weeks
Who hires us for this
- Product leaders adding an AI feature to a SaaS or internal tool with real users
- Newsroom and content operations that need multi-format drafts from one source
- Document-heavy teams (claims, underwriting, legal) extracting structured fields at volume
Problems we get hired for
What usually goes wrong before we are called
The demo prompt does not survive real inputs
We build an eval set from your own documents first, then iterate prompts and model choice against it. Ship criteria are numbers on that set, not a demo.
Cost per request is unknown until the invoice
Every feature ships with a token budget, caching policy, and a cheaper fallback model. Routing rules decide which model handles which input.
Output goes straight to the customer
For publish, send, or file actions we insert an editor or operator approval step. The Xenith Desk pattern keeps the desk system authoritative while drafts are generated.
How the engagement runs
Steps and the artifact each one produces
- 01
Eval set
Two to three hundred real inputs with expected outputs, labelled with your team.
Artifact: Eval dataset and scoring rubric
- 02
Model and prompt design
Candidate models scored on the eval set for quality, latency, and cost. Structured outputs enforced with schemas.
Artifact: Model selection memo with numbers
- 03
Integration
Feature shipped behind your API with caching, fallbacks, and observability. Approval step where output reaches users.
Artifact: Production endpoint, dashboards, runbook
- 04
Refresh loop
Monthly eval re-runs, drift alerts, and a documented process for swapping models.
Artifact: Refresh process and drift dashboard
Stack
Tools we reach for
Chosen per engagement against your existing platform. Nothing here is mandatory; everything here has shipped.
| Models | Claude · GPT-4 class · Gemini · Llama 3 and Mistral for private deployments |
|---|---|
| Serving | Vercel AI SDK · vLLM · LiteLLM routing · Redis semantic cache |
| Structure | JSON Schema outputs · Instructor-style validation · Zod |
| Evals and observability | Promptfoo · Langfuse · OpenTelemetry traces |
| Multimodal | Whisper · Vision-capable models · FFmpeg pipelines |
What you receive
Deliverables
- Eval dataset and scoring rubric from your data
- Model selection memo with quality, latency, and cost numbers
- Production LLM endpoint with caching and fallbacks
- Approval step for user-facing outputs
- Observability dashboards and refresh process
Proof
Where this has run
Broadcast / Media
Broadcast Group: One Long-Form to Multi-Format Packages PoC
Anonymized newsroom PoC: one VOD ingest → TV, YouTube, Shorts, Reels, and social drafts with desk approval, iNEWS-class SoR unchanged.
First-draft formats: Manual rebuild each → 11 surfaces in PoC scope
Insurance
Claims Intake Routing & Data Extraction
FNOL packs auto-classified and routed: adjusters cut intake from ~45 minutes to ~5–8 on standard claims.
Intake time (standard claims): ~45 minutes → ~5-8 minutes
Healthcare
Prior Authorization Packet Assembly
Guided prior-auth packet drafting in-VPC: ~35–45% less admin time on routine auths, humans on exceptions only.
Admin time on routine auths: Baseline → ~35-45% reduction
Products that ship inside this service
- Xenith Desk · Newsroom package factory: the desk system stays authoritative, output multiplies.
- Xenith LLM Platform · Model routing, caching, and cost controls between your apps and every LLM provider.
Engagement models
How we can be hired for this
| Model | Shape | Typical duration |
|---|---|---|
| Fixed-scope pilot | Defined workflow, defined integration points, defined exit metric. Priced as a project. | 4–12 weeks |
| Production retainer | Monthly capacity for evals, monitoring, model refreshes, and new workflows. Month-to-month. | 3+ months |
| Embedded pod | One architect plus two to four senior engineers working inside your repos and rituals. | 3–9 months |
Pricing and phase gates are described on How we work.
Questions buyers ask
Frequently asked questions
- Which model should we use?
- The one that scores best on your eval set at a cost you accept. We usually end with two: a frontier model for hard inputs and a smaller model for the bulk. The selection memo shows the numbers so procurement can defend the choice.
- Do you fine-tune?
- Only when prompting and retrieval fail on the eval set and there is enough labelled data. Fine-tuning small models for narrow classification or style tasks has paid off; fine-tuning for knowledge has not. Our SLM fine-tuning guide covers the decision.
- How do you keep generated content from publishing unreviewed?
- Outputs that reach customers, regulators, or the public pass through an approval step. In the broadcast repackaging PoC, editors approved every package; the desk CMS stayed the system of record.
- What about hallucinations in extracted fields?
- Structured outputs with schemas, source-span citations for each field, and confidence thresholds that route low-confidence items to a human. The claims intake deployment routes 400–600 items a day this way.
When this is the wrong fit
- Teams without access to real input data; we cannot build an eval set from a spec alone.
- Pure research or model training projects with no product to ship into.
Next step
Send the workflow. We reply with an architecture sketch.
Describe the queue, the system of record, and who signs off today. First brief is free; NDA first if you prefer.