Tiers and what each gives you

There are two ways to get an agent onto a Microsoft Teams call with StandIn. They differ in who owns the Microsoft Teams bot, and that one difference decides how much Azure work you do and how your agent appears in Microsoft Teams. Nothing on your side of the seam changes with the tier. Same package, same handler, same STANDIN_SECRET. Read this page once to pick a lane, then never think about it again while you are writing worker code.

​

Which one am I on?

One question settles it: who issued the Microsoft Teams bot? The tell that never lies is the App ID. If you hold an Azure Bot App ID and client secret, you are on your own bot; if StandIn handed you a secret and you never saw an App ID, you are on the StandIn AI Teammate app.

​

Side by side

Chat is the row people misread, so read it twice. The chat lane in this SDK is what the managed bot unlocks: it dials out, so it needs no port and no tunnel. A bring-your-own-bot identity gets chat from its own Azure Bot messaging URL instead, which is not this SDK. Endpoints is the only place that list lives. Meeting recap in the OpenClaw and Hermes plugins uses that same outbound chat socket. Turn the switch on on a bring-your-own-bot identity and hang-up writes the transcript, then has nowhere this SDK can post. Meeting recaps are best-effort. They may be lost if the worker exits during processing.

​

Plans and billing

Daily minutes and managed-bot capacity live on the identity in the StandIn portal. Choose a plan there, set how long the teammate can talk, and turn on extras such as a knowledge base. The SDK authenticates with the connection secret. The portal owns the plan. The daily budget runs on a clock that is not yours: the daily budget entry says when it flips and why a bot that “hung up out of nowhere” at around five minutes is the budget rather than a fault.

​

A Free identity

What it gives you. The whole bring-your-own-bot setup: your own bot, in your own tenant, carrying your own name, answering inbound calls that people dial directly. Nothing is fenced off. It is the paid setup with a daily budget attached, which makes it the honest way to evaluate StandIn against a real tenant. What it costs you. The Azure work is yours: a Microsoft Entra app, an Azure Bot resource, a Microsoft Teams app package, and the Graph permissions with the one-time admin consent that turns calling on. Then 5 minutes of call time a day, per identity. Pick the free budget when you deploy the identity in the dashboard. The setup itself is Microsoft Teams setup, and the permissions table that gates calling is on the Azure bot page.

​

The StandIn AI Teammate app

What it gives you. No Azure app registration at all, and no App ID or client secret to rotate. You add StandIn AI Teammate from the Microsoft Teams Store (also listed in Microsoft Marketplace), type signin so StandIn learns which Microsoft organization to connect, and deploy an identity in the portal that points at your agent. It is also what unlocks this SDK’s chat lane: ChatChannel dials out, so chat needs no URL registered, no open port and no tunnel rule, and your worker never holds a Bot Framework credential. What it costs you. The bot carries StandIn’s name in your organization, not yours, which is the whole of the trade and the reason the other lane exists. Calling waits on a Microsoft 365 administrator approving it once for the organization; chat works before that approval lands, which is why a new connection can look half-broken when it is merely half-approved. And one agent instance serves one connection: the secrets belong to a single Microsoft organization, so a second organization means a second instance, never a shared secret.

​

What the tier does not change

The tier decides who owns the bot and what you are allowed. It never reaches into your worker, so these hold everywhere:

• The package and the handler. One SDK in Python and TypeScript, the same callbacks, the same audio contract. Moving lane is a configuration change.
• One call path to publish, and one secret. STANDIN_SECRET must byte-match the secret registered for the identity you are on, and a mismatch is silent by design. The path and the probes are on Expose your agent, which is the only page that carries them.
• What you keep is yours to gate. recording_active / recordingActive says whether the call is being recorded right now. What the SDK itself gates on it is vision: AmbientVision, whose require_recording / requireRecording is on by default, and KeyframeStore, which keeps no history while the call is not recorded. The SDK does not gate audio on it. The caller’s speech reaches your handler whether or not the call is being recorded, so anything you store, transcribe to disk or send to a third party has to read the flag itself. Nothing in the SDK mirrors a call into an audit log and nothing redacts what your agent says or sends: if your organization needs either, it lives in your worker, on every tier.
• Outbound calling is off until you switch it on. An unset STANDIN_OUTBOUND_ALLOW refuses every outbound call, and STANDIN_OUTBOUND_MAX_PER_HOUR caps the rest at six an hour by default. When nobody answers, there is no voicemail: the SDK has none. The parked line is posted back into the conversation the request came from, once, marked so it reads as a missed call. A call with no such conversation, which is every one-to-one call, is parked with no fallback rather than posted somewhere it does not belong, because a message delivered to the wrong thread is worse than one that waited.

What the SDK gives you is the full boundary between your worker, this SDK and the hosted service.

​

Moving to another tier

Your handler comes with you. What does not come with you is the identity: each one has its own registered secret, so switching means taking the new secret from the portal, setting STANDIN_SECRET to it and restarting the worker. Never carry one secret across two identities or two organizations.