> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/ai-powered-app.md).

# AI-Powered App Features

This example is about adding AI behavior inside a Buzzy app.

It is different from using AI to build the app. Builder MCP and Buzzy AI help create and edit the app definition. AI-powered app features are runtime capabilities that users interact with, such as summarising a record, drafting a response, classifying a submission, extracting fields from text, or chatting with domain-specific context.

## Pattern Overview

Use Buzzy Functions for AI service calls. Keep API keys in Constants. Use standard Buzzy screens and actions for simple workflows. Add code widgets only when the interaction needs a richer UI than standard Buzzy components provide.

| Need                                                                 | Buzzy capability                           |
| -------------------------------------------------------------------- | ------------------------------------------ |
| Store API keys and model config                                      | Constants                                  |
| Call OpenAI, Anthropic, Gemini, or another provider                  | Buzzy Function                             |
| Capture user input and selected row context                          | Buzzy screen action                        |
| Display simple output                                                | Standard fields, modals, or result records |
| Display streaming, chat, advanced review, or side-by-side comparison | Code widget                                |
| Change the app definition safely                                     | Builder MCP                                |
| Verify the workflow                                                  | Release Tests                              |
| Review sensitive data and access                                     | Security Review                            |

## Example Use Cases

* Summarise a support ticket or case record.
* Draft a reply for a reviewer to approve.
* Classify an inbound request by type, urgency, or risk.
* Extract structured fields from pasted text.
* Generate a first-pass checklist or action plan.
* Compare two records and highlight differences.
* Provide a domain-specific assistant over approved app data.

## Recommended Build Flow

1. Update the brief to describe the AI feature, who uses it, and what the output is allowed to do.
2. Confirm the data model has fields for input, output, status, review, and audit notes where needed.
3. Create Constants for provider keys, model names, base URLs, and safe configuration.
4. Create a Buzzy Function with a clear input and output contract.
5. Wire the function to a screen action.
6. Add a code widget only if the UI needs chat, streaming, rich comparison, or custom controls.
7. Add Release Tests for happy path, error path, and permission-sensitive path.
8. Run Security Review if the feature can access personal, operational, financial, health, education, customer, or internal data.

## Function Contract

Keep the function contract explicit. A good AI function declares:

* required inputs from the screen or row
* constants it depends on
* the model/provider it calls
* maximum input and output size
* what data must never be sent to the provider
* structured JSON output
* user-facing error messages
* sample payloads for tests

Example output shape:

```json
{
  "status": "ok",
  "summary": "Short generated summary for review.",
  "confidence": "medium",
  "needsHumanReview": true,
  "warnings": ["Contains sensitive data; review before sharing."]
}
```

## Prompt and Data Safety

Do not send more data to an AI provider than the feature needs.

For sensitive apps:

* filter row data before calling the function
* exclude Private Data unless there is a clear approved reason
* keep prompts server-side
* avoid placing secrets or private policy text in code widgets
* store generated output where the same field-level access rules apply
* require human approval for actions that affect users, money, compliance, or records of authority

## Builder MCP Instructions

Builder MCP can help generate the function, constants, widget, and screen wiring.

Example instruction:

```
Add an AI-assisted case summary feature to the Case Detail screen.

Use a Buzzy Function for the model call and Constants for provider configuration.
The function should accept case ID, safe case metadata, and non-private review notes only.
It should return structured JSON with summary, riskLevel, missingInformation, and suggestedNextSteps.
Add a reviewer-only action on Case Detail that calls the function and stores the output in reviewer-visible fields.
Add release tests for reviewer success, unauthorized user denial, and provider error handling.
Run Security Review after wiring the feature.
```

## When to Use a Code Widget

Use a code widget when standard Buzzy UI is not enough:

* conversational chat
* streaming response display
* side-by-side diff or compare UI
* token/cost meters
* rich prompt controls
* interactive review workflows

Do not use a code widget just to call the AI provider directly from the browser. The provider call should stay in a Buzzy Function so keys and sensitive logic stay server-side.

## Testing Checklist

* Function succeeds with realistic input.
* Function fails safely when the provider is unavailable.
* Function rejects missing or malformed input.
* Unauthorized users cannot trigger the action.
* Sensitive fields are not sent unexpectedly.
* Generated output is stored in fields with correct access rules.
* Release Tests cover the main workflow.
* Security Review findings are addressed before release.

## Related Pages

* [Builder MCP Change and Extension Workflow](/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/builder-mcp-change-workflows.md)
* [Buzzy Functions & Constants](/the-building-blocks/buzzy-functions-and-constants.md)
* [Code Widget Examples](/the-building-blocks/code-widget-custom-code/examples.md)
* [Security Review](/the-building-blocks/security-review.md)
* [Release Tests](/the-building-blocks/release-tests.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/ai-powered-app.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.