🤖 Build LLM-Powered Teams Bots With the Teams AI Library

A traditional ChatOps bot makes you speak its language: /deploy payments staging v2.1.0, exact syntax, exact order. An LLM-powered bot lets the engineer say “ship payments 2.1 to staging” and figures out the rest. The hard part has always been the plumbing between the language model and your actual operations — turning loose natural language into a specific, safe, confirmable action without letting the model freelance against production.

The Teams AI Library is Microsoft’s framework for exactly that plumbing. It sits on top of the Bot Framework and gives you prompt management, a planner that maps user intent to named actions you define, and conversation state — so you write the actions and the safety checks, and it handles the LLM orchestration. Crucially, the model never calls your systems directly; it selects from a menu of actions you control.

The mental model: actions, not freeform

The key design idea is that the LLM doesn’t run commands. It produces a plan — a sequence of named actions from a registry you defined — and your code executes those actions with whatever guardrails you put in them. The model’s job is intent-to-action mapping; your job is making each action safe. That separation is what makes an LLM bot trustworthy enough to touch infrastructure.

Setting it up

The library is @microsoft/teams-ai. You configure a planner pointed at your model and register actions:

import { Application, ActionPlanner, OpenAIModel, PromptManager } from "@microsoft/teams-ai";

const model = new OpenAIModel({
  // works with Azure OpenAI or other configured backends
  azureApiKey: process.env.AZURE_OPENAI_KEY,
  azureEndpoint: process.env.AZURE_OPENAI_ENDPOINT,
  azureDefaultDeployment: "gpt-deployment"
});

const planner = new ActionPlanner({
  model,
  prompts: new PromptManager({ promptsFolder: "./prompts" }),
  defaultPrompt: "ops"
});

const app = new Application({
  storage,
  ai: { planner }
});

The promptsFolder holds your system prompt and the action schema — a folder of skprompt.txt and config.json per prompt. The system prompt is where you set the bot’s personality and, more importantly, its constraints.

Registering guarded actions

Each action the model can select is a function you write. This is where deploy logic, authorization, and confirmation live:

app.ai.action("deployService", async (context, state, params) => {
  const { service, environment, version } = params;

  if (environment === "production") {
    // never auto-execute prod from the model's plan
    await context.sendActivity(confirmCard(service, environment, version));
    return "Awaiting human confirmation for production deploy.";
  }
  await kickOffDeploy(service, environment, version);
  return `Deploying ${service} ${version} to ${environment}.`;
});

app.ai.action("getStatus", async (context, state, params) => {
  const status = await fetchStatus(params.service);
  await context.sendActivity(statusCard(status));
  return `Reported status for ${params.service}.`;
});

The string each action returns goes back into the planner’s loop so it knows the result and can decide what to do next. Notice the production branch: the model can propose a prod deploy, but the action refuses to execute it without a human clicking a confirmation card. That’s the read-and-reason / human-executes line, ported into an AI bot.

The system prompt sets the rules

The model’s behavior is shaped by the prompt. Mine, paraphrased:

You are an operations assistant in Microsoft Teams. You may only act through the registered actions. Never invent service names, versions, or environments — if any are missing or ambiguous, ask the user. Read-only actions (getStatus, listDeploys) may run freely. Any state-changing action targeting production must be confirmed by a human; describe what will happen and stop. Never claim an action succeeded unless an action result says so.

That last sentence matters because LLMs will happily narrate a success that didn’t happen. By routing all truth through action return values and forbidding the model from asserting outcomes itself, you keep its confident prose from becoming a lie about your infrastructure.

Why the action registry is the safety boundary

The thing I’d underline for any DevOps engineer evaluating this: the registry of actions is your security boundary. The model cannot do anything you didn’t register. It can’t shell out, can’t call arbitrary APIs, can’t construct a kubectl command — it can only pick from deployService, getStatus, rollback, and whatever else you defined, with parameters you validate inside each handler. So you get the natural-language ergonomics on top of a fixed, auditable set of operations. The blast radius is exactly the set of actions you wrote, no more.

Practical guardrails

• Validate every parameter inside the action, not in the prompt. The model can be talked into passing odd values; the handler is where you reject them.
• Authorize on the action, keyed to the Teams user. Map context.activity.from.aadObjectId to your RBAC and check it before executing anything that writes.
• Confirm destructive actions with a card, never inline. A button-click confirmation gives you a deliberate human step and a visible audit record.
• Log the plan and the outcome. Store what the model proposed and what actually ran. When someone asks “why did the bot do that,” you want the trace.
• Keep the action set small and sharp. Five well-guarded actions beat twenty fuzzy ones. Every action is attack surface and prompt-confusion surface.

The Teams AI Library turns “remember the exact syntax” into “say what you want,” while keeping you firmly in control of what can actually happen. The model plans; your guarded actions execute; production changes still wait for a human. That’s an LLM bot you can put in front of real infrastructure.

For more on LLM-driven ChatOps in Teams, see the Microsoft Teams guides, and the prompt library has system prompts and action-schema templates to start from.

The Teams AI Library API, model configuration, and supported backends change across versions. Always keep state-changing actions behind server-side validation and human confirmation.