Your product.
New superpowers.
Give your application an agent experience that feels native. Start with React, connect through typed SDKs, and keep authentication on the backend you already trust.
What you build against
@flozentai/react
A provider and an assistant component. It takes a token callback rather than a token, so refresh stays on your backend.
Node.js SDK
Typed client for runs, approvals and management. The same surface the console uses.
.NET SDK
For services that already live in .NET, with the same run and approval model.
Management API
Create tenants, rotate connections and promote deployments from your own provisioning flow.
Embedding the assistant
The component takes a deployment id and a function that returns a token. It never holds a long-lived credential, and the identity it runs as is whatever your backend vouched for.
import {
FlozentAiProvider,
FlozentAiAssistant
} from '@flozentai/react';
// Your authenticated session and client options.
<FlozentAiProvider
identityKey={sessionKey}
options={{
gatewayUrl,
deploymentId,
getAccessToken: getHostToken
}}
>
<FlozentAiAssistant />
</FlozentAiProvider>Identity comes from your issuer
You do not provision users in FlozentAi. Your backend exchanges a token it already issued for an agent identity: the host tenant is the customer, and the end user is created automatically the first time they appear.
// On your backend, where you already know who the user is.
const response = await fetch(`${gatewayUrl}/v1/auth/token`, {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({
subjectToken: yourSessionToken, // your own issuer
tenant: customer.id, // becomes a host tenant
deploymentId,
}),
});
// The end user is created on first sign-in. You never
// provision them, and the browser never sees a long-lived secret.A trusted issuer tells FlozentAi which signing keys to accept. Until one is registered for the environment, token exchange refuses the request rather than guessing.
Environments behave like you expect
- Development, staging and production are separate environments with their own deployments, connections and knowledge.
- A deployment is an immutable, versioned bundle. Promoting is explicit; nothing moves between environments on its own.
- Production is marked as such in the console, so the environment you are pointed at is visible before you act rather than after.
Start with the preview, then wire it in.
The embedded preview runs the real component against sample responses — no account needed.