In this guide10 sections
Lovable can add AI features to the application you are building, not just help you write the application. That distinction matters. The Lovable agent is the system that edits your project. Lovable AI is the built-in connector that can power features your users interact with, such as a support chatbot, document Q&A, summaries, translation, semantic search, image analysis, or workflow automation.
The fastest route to a useful result is not to ask for a general AI assistant. Start with one job, one source of truth, and one measurable outcome. A support app might answer questions from a controlled knowledge base. A sales tool might summarize a call and propose next steps. A document workflow might extract invoice fields for a human to approve. These are product workflows with an AI step, not a chatbot pasted onto every page.
This guide explains how to plan, prompt, secure, and test Lovable AI features. It also covers retrieval-augmented generation, model selection, rate limits, usage costs, and the point where a direct provider integration may be a better fit. If you are new to the platform, start with our first app walkthrough, then use this guide when the application has a clear reason to call a model.
What Lovable AI is, and what it is not
Lovable's built-in AI connector adds model-backed behavior to a deployed application. According to the current documentation, it can handle workflows including chat, summaries, document Q&A, translation, image and document analysis, semantic search, text-to-speech, speech-to-text, and multi-step automation. The connector is separate from the AI agent that creates and edits your project.
The connector is designed to remove some setup work. Lovable manages a project API key and routes calls through a backend edge function rather than asking you to put a provider secret in browser code. That reduces a common security mistake, but it does not make the whole feature safe automatically. You still need authentication, authorization, input limits, prompt design, abuse controls, logging decisions, and a clear policy for user content.
You also need to separate three kinds of behavior: deterministic application logic, retrieval from your own data, and generated output. The model should not decide whether a payment succeeded, whether a user owns a record, or whether an administrator action is allowed. Use normal code and database policies for those decisions. Use AI where interpretation, transformation, ranking, or language generation adds value.
| Workflow | Good first use | What must remain deterministic |
|---|---|---|
| Chat assistant | Answer product questions from a controlled knowledge base | User access, source filtering, escalation, and citations |
| Summarization | Turn a meeting note into a short brief and action list | Which records the user can read and where the summary is saved |
| Document extraction | Read an invoice or application and suggest structured fields | File access, validation, approval, and final data entry |
| Semantic search | Find relevant help articles when exact keywords differ | Tenant isolation, ranking boundaries, and link destinations |
| Workflow automation | Classify incoming messages or draft a reply | Trigger permissions, side effects, sending, and audit history |
| Voice feature | Transcribe a note or read an answer aloud | Consent, retention, upload limits, and sensitive data handling |
The AI can interpret or generate. Your application should still own permissions, state changes, and irreversible actions.
Note
A model response is an untrusted suggestion until your application validates it. Never use free-form AI text as proof that a payment, permission change, or database mutation is allowed.
Choose one AI job before you choose a model
Model choice is easier after the user job is precise. Ask what the user has, what they need, and what the application should do next. 'Add AI to my CRM' is not a buildable requirement. 'When a sales note is saved, create a five-bullet summary and three suggested follow-up questions, then let the owner edit it before saving' is a product behavior with a clear input, output, and review point.
Start with a workflow where quality can be evaluated by a person. A human review step is not a weakness. It lets you learn which inputs cause errors, which fields need validation, and whether the model is saving time. Once the workflow is reliable, you can automate a narrow part of it. Do not begin with an autonomous agent that can send email, alter records, or spend money without a well-tested boundary.
Use the simplest output format that supports the experience. A short answer with source links is easier to test than a large JSON object with twenty optional fields. If the application needs structured output, define required fields, allowed values, maximum lengths, and what should happen when the model cannot determine an answer.
- 1
Name the user and the moment
Write who invokes the feature, from which screen, and what information is already available. For example: 'A support agent opens a ticket and asks for a draft reply using the ticket history and approved help articles.'
- 2
Define the useful output
Specify the format, length, tone, required fields, and whether the user can edit it before it is stored or sent.
- 3
Define the failure path
Say what the interface should show when the model is unavailable, the source contains no answer, the request exceeds a limit, or the output fails validation.
- 4
Choose the success measure
Track a real outcome such as edit time saved, accepted suggestions, resolved tickets, extraction accuracy, or search clicks. Do not use response length as your quality metric.
Tip
If the output cannot be judged with a small set of real examples, the feature is still a concept. Build the evaluation examples before adding more screens.
A reliable first prompt for a Lovable AI feature
Give Lovable a product brief for the feature, not only a model name. Include the source data, the user role, the output contract, the UI states, and the security boundary. Tell it what the AI must not do. The prompt should also ask for sample data and a test screen so you can inspect the behavior without waiting for production traffic.
Build the interface around the uncertainty of the response. Show a clear loading state, allow cancellation where possible, explain an empty result, and provide a retry path. If the output is saved, make the saved status visible. If the user needs to approve it, do not style a draft as if it were a verified fact.
Add one AI-assisted support workflow to the existing app.\n\nUser: authenticated support agents can open a ticket and request a draft reply.\n\nInputs: ticket subject, ticket messages, the customer's plan, and only help articles marked published. The AI must not access another workspace's tickets or unpublished internal notes.\n\nOutput: return a concise draft reply with a short subject suggestion and three bullet points explaining which published help articles support the answer. If no article supports the answer, say that the evidence is insufficient and ask the agent to respond manually. Do not invent policy, pricing, refunds, or account changes.\n\nUI states: idle, loading, cancel, success, empty evidence, validation failure, rate limit, unavailable, and retry. Show the source articles used. Let the agent edit the draft before saving it.\n\nSecurity: keep model calls behind the server-side AI integration, enforce workspace ownership in database policies, validate input length, and never expose private keys in browser code. Start with sample tickets and add a small review screen so I can compare outputs against expected answers.Keep AI calls behind a trusted data boundary
A user-facing AI feature still needs ordinary application security. Confirm the signed-in user and their workspace before retrieving context. Apply database policies to the records used for retrieval. Filter private fields before they enter a prompt. Set limits on text length, file size, number of requests, and output size. Treat uploaded documents and user instructions as untrusted input that can contain prompt injection attempts.
The current Lovable AI connector routes model calls through a backend edge function and manages the project key for you. That protects the provider credential from direct browser exposure. It does not decide whether the current user is allowed to ask about a particular document. That authorization must happen in your application before the content is passed into the AI workflow.
Be specific about data retention. Decide whether prompts and responses should be stored, whether they may contain personal or confidential information, who can view them later, and how a user can delete them. If you enable detailed AI activity visibility for debugging, review who can access request content and for how long. Logging a full prompt may be convenient during development and inappropriate in production.
- Authenticate before loading private context, not only before rendering the AI button.
- Filter documents and records by tenant, role, and ownership before retrieval.
- Keep provider secrets and privileged service keys in server-side secrets.
- Limit prompt size, file type, upload size, request frequency, and output length.
- Validate structured output before saving it or using it in an automated action.
- Escape or isolate untrusted document instructions so they cannot override the application policy.
- Record enough metadata to debug failures without retaining sensitive content by default.
Watch out
Prompt injection is an application security problem. A document can contain instructions that try to change the assistant's behavior, reveal hidden context, or trigger an unsafe action. Retrieval must be permission-filtered and output must be constrained.
Document Q&A and RAG need a retrieval design
Document Q&A is often described as 'upload a PDF and chat with it.' In a useful product, there are several separate steps: accept the file, extract text, split it into retrievable chunks, create embeddings or another search index, retrieve relevant passages for a question, generate an answer, and show the evidence. Each step can fail independently, so the interface should not imply that a fluent answer proves the entire document was searched correctly.
Start with a small, controlled corpus. Store the document owner, workspace, title, version, processing status, and any access labels next to the extracted content. When a user asks a question, filter candidate chunks by their authorization before semantic ranking. A highly relevant chunk from another tenant is still a data leak.
Show citations or source passages when the feature is used for work. Source links let the user verify the answer and reveal when the retrieval system found nothing reliable. If the product cannot cite its source, use language that communicates uncertainty and provide a path to inspect the underlying material.
| Stage | What to implement | What to test |
|---|---|---|
| Upload | Validate type, size, ownership, and duplicate behavior | Large file, unsupported file, interrupted upload, unauthorized download |
| Extract | Store processing status and an error reason | Scanned PDF, missing text, broken encoding, partial extraction |
| Chunk | Keep headings, page numbers, document version, and access labels | A table split across pages and a section with repeated terms |
| Retrieve | Filter by authorization before ranking | Cross-tenant query and a question with no matching evidence |
| Generate | Constrain answer length and require evidence | Conflicting passages, ambiguous question, prompt injection |
| Present | Show sources, uncertainty, loading, and retry states | Slow response, model error, deleted document, expired session |
RAG quality depends on retrieval and permissions as much as on the language model.
Good AI UX makes uncertainty visible
A polished AI feature is not one that always sounds confident. It helps the user understand what the system is doing, what information it used, and what the user should do next. Use specific labels such as 'Draft generated from 4 published articles' or 'No matching source found' instead of a generic success message. Make it easy to edit, regenerate, compare, or discard a result.
Streaming can make chat and assistant features feel responsive because tokens appear as the response is generated. Streaming does not make the answer more accurate. Keep partial output visually separate from confirmed application state. Do not save a half-generated response as a completed record when the connection closes.
If the model returns structured data, validate it in code. Check required fields, enum values, maximum lengths, numeric ranges, and references to records the user actually owns. If validation fails, show a recoverable error and keep the original input available. A retry should not duplicate a payment, send an email twice, or create two records.
- Show where the answer came from when the feature uses private or indexed content.
- Let users correct or reject an output without losing their source input.
- Keep AI-generated drafts visibly distinct from approved or sent content.
- Explain rate limits, unavailable services, and insufficient evidence in plain language.
- Track accepted edits and failure categories, not only total request count.
- Provide an accessible keyboard path and a non-AI fallback for the core task.
Model choice, usage cost, and rate limits
Lovable's supported model list and defaults change as providers change. Choose by task characteristics rather than by brand name alone. A high-volume classification job may prioritize latency and cost. A document workflow may need better extraction accuracy. An image feature has different constraints from a chat feature. Start with the default or the model Lovable recommends, then test alternatives against the same evaluation set.
Built-in AI usage is separate from the messages you send while building the project. The deployed feature consumes usage credits based on the model and amount of work. Current documentation also describes workspace rate limits and distinct failure responses for too many requests and insufficient credits. A production feature needs a user-facing response for both conditions and a way for the owner to monitor spend and failure rates.
Estimate cost from real usage, not from a single demo. Track average input length, output length, request frequency, retries, file processing, and the percentage of requests that are cancelled or regenerated. Cache safe, repeated results such as a summary of an unchanged document. Keep expensive work asynchronous when the user does not need an immediate response.
| Cost lever | Practical control | Trade-off |
|---|---|---|
| Input size | Retrieve only relevant context and remove unused fields | Less context can reduce recall if retrieval is weak |
| Output size | Set a clear format and maximum length | Short outputs may omit nuance |
| Model | Test a faster or smaller model for simple tasks | Lower cost can reduce accuracy on harder cases |
| Retries | Retry transient failures with a cap and backoff | Aggressive retries can multiply spend |
| Regeneration | Ask what the user wants changed instead of rerunning blindly | More interaction design is required |
| Caching | Reuse results for unchanged, non-sensitive inputs | Invalidation and privacy rules must be correct |
Tip
Set a maximum number of retries and a budget alarm before launch. An AI feature that feels inexpensive in a test account can become costly when users regenerate long answers or upload large files.
Production checklist for a Lovable AI feature
Run the feature with real examples that have known answers, ambiguous inputs, missing evidence, malformed files, and adversarial instructions. Have someone who did not write the prompt use the feature. They will find unclear labels and false confidence faster than another round of styling.
Before connecting live data, use the application's security checklist and confirm that all private records are protected. If the AI feature changes a schema, touches authentication, or stores files, review the relevant Supabase integration guide. For a paid product, keep the AI workflow separate from Stripe billing state so a model response cannot mark an invoice paid.
- The feature has a one-sentence purpose and an owner responsible for its quality.
- Private context is filtered by authentication, tenant, and role before the model call.
- No secret key is exposed in browser code or committed to the repository.
- Inputs, files, outputs, retries, and request frequency have explicit limits.
- The interface handles loading, cancellation, empty evidence, validation failure, rate limits, and outages.
- Structured output is validated before it is stored or used to trigger side effects.
- The team has evaluation examples and a process for reviewing bad answers.
- Usage, latency, failures, and cost are visible to the owner.
- Users can complete the core job without an AI response when the service is unavailable.
Key takeaways
- Lovable AI adds AI behavior to your deployed app. It is separate from the Lovable agent that edits your code.
- Start with one narrow, reviewable workflow instead of a general-purpose chatbot or autonomous agent.
- The built-in connector keeps model calls behind a backend boundary, but your app still owns authorization, validation, limits, and data retention.
- Document Q&A needs permission-aware retrieval, source tracking, and explicit failure states.
- Model choice should follow the task and an evaluation set. Track real input size, output size, retries, and regeneration behavior to understand cost.
- AI output is a suggestion until your application validates it. Keep payment, permissions, and other irreversible state changes deterministic.
Frequently asked questions
The built-in AI connector can support features such as chat assistants, summaries, document Q&A, translation, image and document analysis, semantic search, text-to-speech, speech-to-text, and workflow automation. The available models and defaults can change, so check the current Lovable documentation for the supported list.
