# How to Add AI Agent to SaaS Product | FlyMy.AI

> Embed a tested agent behind your SaaS backend, with customer-specific service connections and explicit builder billing.

Page: https://flymy.ai/use-cases/ai-agents-for-saas/

One product workflow, separate customer connections

# AI agents for SaaS products

Add an agent to your SaaS through a deployment called by your authenticated backend. Identify each product user separately and let them connect their own supported services. Keep the builder key on the server and reconcile every ambiguous run. FlyMyAI charges you, and you bill your customers. Customer connections never imply customer billing.

[Build this agent](https://app.flymy.ai/signup) [Read the recipe](https://flymy.ai/use-cases/ai-agents-for-saas/#recipe)

## How to add AI agent to SaaS product

1. ### Build and test the shared workflow Create one agent, freeze a successful execution and create a stable deployment pointing to the reviewed version. Expose only the inputs your product needs.
2. ### Bind the authenticated customer Derive external_user_id from your authenticated product session on the backend. Do not let a model or an untrusted browser choose another customer identity, deployment or credential mapping.
3. ### Connect each customer account Use a deployment connect-session for a required slot and present its hosted connection flow. Your customer connects their own supported account, such as a Google integration where available. Read access state afterward; never fall back to the authoring owner connection.
4. ### Run, reconcile and bill in your product Dispatch through your backend with a persisted idempotency key and the exact customer mapping. Store the execution ID and read its status. Handle quotas, customer billing and your markup in your own product. An unknown dispatch needs reconciliation before another write.

## Billing belongs in your product

FlyMyAI charges you, and you bill your customers. The deployment owner pays FlyMyAI usage. Automatic onward charging, billing passthrough and per-user cost rollups are not provided by this workflow. It makes no white-label claim.

Documented customer connection mapping body - [source documentation](https://docs.flymy.ai/agents/guides/embedded-resale)

```
{
  "external_user_id":"customer_42",
  "variables":{},
  "connections":{
    "support_mailbox":"11111111-1111-4111-8111-111111111111",
    "compliance_mailbox":["22222222-2222-4222-8222-222222222222"]
  }
}
```

Example IDs and slot names only. Use slots required by your frozen deployment and public IDs returned by the authenticated customer connection flow. The complete deployment/run recipe is linked in the source; this body alone is not a runnable request.

## What you get

Illustrative output - example data

```
product_user: customer_42
deployment: your reviewed deployment
execution: returned execution ID
status: completed
result: customer-specific support summary
payer: deployment owner
```

### Where the result goes

Return the execution result through your authenticated application backend. Keep the builder key, customer identity and connection mapping on that backend. External delivery uses the customer-authorized service connection selected for the run.

## Cost and operating limits

FlyMyAI bills the deployment owner for execution. Your application must enforce its own customer quotas and billing. Start with a small customer cohort and bounded polling; do not automatically retry writes after a timeout or lose the persisted idempotency identity.

[Check current pricing](https://flymy.ai/pricing/)

## Choose the right approach

**Implementation choices for this job**

| Approach | What to evaluate |
|---|---|
| FlyMy.AI deployment | Use one builder integration with explicit customer identities and supported customer connections. |
| A backend workflow you operate | You own the runtime, credential mapping, isolation, execution tracking and customer billing. |
| Giving every customer your API key | Not an acceptable integration pattern. Keep the builder key server-side and authenticate each product user in your own application. |

## Frequently asked questions

**Does each customer need my FlyMyAI key?**

No. The builder key stays on your backend. Customer service connections and product identities are distinct from that key.

**Can customers connect their own Google account?**

Use the supported connector and deployment connect-session flow for the required slot. Verify current connector availability and access state before promising a specific Google action.

**Is this automatic resale billing or white labeling?**

No. FlyMyAI charges the deployment owner; your product handles customer charging. This guide does not promise automatic cost attribution or a white-label interface.

## Related jobs

Use case

### [Create AI agent by describing it](https://flymy.ai/use-cases/create-ai-agent-by-describing-it/)

Turn a plain-English job into a cloud agent, review a real run, and freeze the accepted workflow for reuse.

[Read the guide →](https://flymy.ai/use-cases/create-ai-agent-by-describing-it/)

Use case

### [Scheduled AI agents](https://flymy.ai/use-cases/scheduled-agents/)

Schedule a tested agent for a morning report, recurring research or structured output using cron and an explicit timezone.

[Read the guide →](https://flymy.ai/use-cases/scheduled-agents/)

## Sources

[Embedded and resale guide](https://docs.flymy.ai/agents/guides/embedded-resale), [Operating guide](https://flymy.ai/skill.md), [Pricing](https://flymy.ai/pricing.md)

Sources checked 2026-10-23. Examples are documentation excerpts, not a claim that a paid run has been performed.

---

For agents: the FlyMyAI operating guide (sign up, connect, run models, tools and agents) is https://flymy.ai/skill.md, and https://flymy.ai/llms.txt lists the other pages and the documentation.