Guides / Prompting and shipping

How to Add AI Features to Your App

Add summaries, chat, data extraction and classification to your app with an LLM API — keeping keys safe, costs under control and output trustworthy.

Mythex Team · 2026-09-29 · 7 min read

To add AI features to your app, call a large language model (LLM) API from your server: send it clear instructions plus the relevant data, and use what comes back. Most useful features are one of four patterns — summarising, chatting, extracting structured data, and classifying — and each is a few dozen lines of code that an AI builder can write for you. The work that decides whether the feature is any good is around the call: keeping the API key on the server, controlling cost per user, and checking the output before you trust it.

The four patterns behind most AI features

Extraction and classification are often the most valuable and the least visible. They quietly save someone a few minutes on every record, and because the output is a fixed shape you can check it automatically. Chat is the most visible but the hardest to get right, and has its own guide: how to build an AI chatbot app.

How it fits into your app

Every pattern has the same shape:

1. The user acts — clicks "Summarise", uploads a file, sends a message.
2. Your front end calls your own server, not the AI provider.
3. Your server builds the request: system instructions, the user's input, and any data the model needs from your database — only data this user is allowed to see.
4. Your server calls the LLM API with a key stored in an environment variable.
5. Your server checks the response — valid JSON, a known label, a sensible length — and saves or returns it.
6. The front end shows it, streaming text as it arrives for longer answers.

The key sits on the server in step 4 and never reaches the browser. If the idea of an API is new, what an API is is a short primer, and how to use LLM APIs covers tokens, models and keys in more depth.

Choosing a provider and model

The major providers — OpenAI, Anthropic, Google and others — all offer text APIs with broadly similar shapes. Useful questions when choosing:

• Quality on your task. Try a few real examples from your app on two or three models. Differences are often clearer on your data than on general benchmarks.
• Size vs cost. Providers offer larger, more capable models and smaller, cheaper, faster ones. Classification and simple extraction frequently work well on a small model; long reasoning or nuanced writing may need a larger one.
• Structured output. For extraction and classification, prefer an API feature that makes the model return JSON matching a schema you supply, rather than parsing free text.
• Data handling. Read the provider's terms on whether API inputs are stored or used for training, and whether that suits the data your users give you.
• Limits. New accounts often have lower rate limits; check them before a launch.

Model names and prices change often, so the code should read the model name from configuration rather than hard-coding it in many places.

Adding a feature, step by step

Take a concrete example: a small CRM where each contact has a long history of notes.

1. Store the key. Create a key in your provider's dashboard and save it as a server-side secret, for example OPENAI_API_KEY or ANTHROPIC_API_KEY.

2. Ask for one narrow feature:

Add a "Summarise" button to the contact page. On the server, send the contact's last 20 notes to [PROVIDER] using the secret [ENV_NAME], with instructions to write three bullet points: current status, open questions, next step. Only include notes the logged-in user can see. Show a loading state, save the summary with a timestamp, and show "Couldn't summarise right now" if the call fails. Never send the key to the browser.

3. Add extraction where it saves typing:

When a user pastes an email signature into the "Quick add" box, call [PROVIDER] on the server and return JSON with name, company, job title, email and phone, using the provider's structured output feature. Validate the JSON on the server, pre-fill the new contact form with it, and let the user edit before saving. Leave fields blank rather than guessing.

"Let the user edit before saving" is the important part: the model proposes, the person decides.

4. Classify in the background:

When a new support ticket arrives, classify it into exactly one of: billing, bug, feature request, account access, other. Use a small, low-cost model. If the response is not one of those labels, store "other". Show the label as an editable tag.

5. Test with messy real data — long notes, empty notes, other languages, a signature with no phone number — and look at twenty outputs side by side before shipping.

Writing instructions that work

The instructions you send with every request (often called the system prompt) are where quality comes from.

• Say who it is for and what good looks like. "Summaries are read by a salesperson in 10 seconds before a call" gives the model a target.
• Fix the format. Exact number of bullets, length limit, fields, labels.
• Say what to do when unsure. "If the notes do not mention a next step, write 'No next step recorded'." This reduces invented answers.
• Give two or three examples of good input and output for extraction and classification.
• Keep instructions separate from user content, and label the user content clearly, so the model can tell them apart.

Keep the prompts in files in your codebase so they are versioned and reviewable like any other code.

Keeping costs under control

LLM APIs charge by tokens — small chunks of text — for both what you send and what comes back. Cost grows with the amount of context per request multiplied by how often it runs. Practical controls:

• Send only what is needed. The last 20 notes, not the whole history. Trim long documents or split them.
• Use the smallest model that does the job. Test before defaulting to the largest.
• Cap output length with the API's maximum-tokens setting.
• Cache results. Store a summary and only regenerate it when the source changes, instead of on every page view.
• Limit per user. A daily cap per account or per plan stops one heavy user, or one script, from running up the bill.
• Rate-limit the endpoint like any other expensive route.
• Set a budget or alert in the provider's dashboard, and check usage weekly after launch.
• Log token usage per feature so you know which one costs what.

If AI features are central to your product, factor their running cost into your pricing rather than absorbing it.

Safety and trust

AI output is probabilistic. It can be wrong while sounding confident, and it can be steered by the text it reads. Build for that:

• Treat output as untrusted input. Validate structure, escape it before rendering as HTML, and never run it as code or database queries.
• Keep a human in the loop for anything with consequences — sending an email, changing a record, refunding a payment. The model drafts; a person confirms.
• Guard against prompt injection. A document or message may contain text like "ignore your instructions". Limit what the model can see to what the current user may see, and do not give it tools that can take sensitive actions without your code checking permissions first.
• Label AI content so users know a summary or suggestion was generated and can check it.
• Handle failures gracefully. Providers have outages and rate limits. Time out, show a clear message, and let the rest of the app keep working.
• Watch what users send. For open text inputs, consider a moderation step and be clear in your privacy policy that content is processed by a third-party AI provider.

The broader list of checks is in the security checklist for AI-built apps.

Common mistakes

• Starting with a general chatbot when a single "Summarise" or "Categorise" button would help more people.
• Putting the key in front-end code or in a public repository.
• Sending the whole database as context, which is slow, expensive and risks exposing other users' data.
• Trusting free-text output where a schema or fixed label set would make it checkable.
• No per-user limits, discovered when the first invoice arrives.

Adding AI features with Mythex

In Mythex you add AI inside your own app by asking for it in chat, using your own provider key. Store the key as a project secret — when the agent needs one, Mythex shows a secrets card in chat so you don't paste the key into the conversation — and the agent writes the server route, the prompts and the interface. Your app's AI usage is billed by your provider, separate from the Mythex credits you spend building. The docs have a starter prompt in add AI features with your own API keys.