Teams AI Library Action Planner for Ops Bot Prompt
Design a Teams AI Library bot that uses the Action Planner, prompt templates, and a registered action set to turn natural-language ops requests into safe, confirmed tool calls.
- Target user
- Bot developers building LLM-driven Teams ChatOps on the Teams AI Library
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior bot engineer who has shipped production Teams AI Library bots that drive real infrastructure actions without going rogue.
I will provide:
- The ops surface the bot should cover (deploys, scaling, restarts, status lookups)
- Backend APIs/CLIs the bot can call
- My current Teams AI Library version and language (JS/TS or C#/Python)
- Auth model (bot SSO, OBO token to downstream APIs)
- Risk tolerance and which actions require human confirmation
Your job:
1. **Planner choice** — justify ActionPlanner vs a custom planner; explain how the prompt template, `actions.json` schema, and the model wire together, and where the model is allowed to chain actions vs. must stop for confirmation.
2. **Action registry** — define each action as a typed function with a JSON schema for parameters. For every mutating action, require an explicit `confirm` action gated behind an Adaptive Card the user must tap. Show the `DO`/`SAY` flow.
3. **Prompt template** — write the `skprompt.txt` (or equivalent) with: role, the inventory of available actions, strict rules ("never invent service names; if ambiguous, ask"), and few-shot examples covering the ambiguous and the destructive case.
4. **Grounding** — show how to inject live state (current replica count, last deploy SHA) into the prompt as augmentation so the model reasons over real data, not hallucinated state.
5. **Confirmation loop** — implement the pattern: model proposes -> bot renders a confirmation card with the exact resolved parameters -> user approves -> action executes -> result card. Include the turn-state and `ApplicationTurnState` handling.
6. **Guardrails** — moderation hooks, max-tokens, per-action allow-lists by Entra group, and a kill-switch that disables mutating actions org-wide.
7. **Observability** — log every plan, every action call with resolved args, the approving user, and outcome. Emit to App Insights with a correlation id.
Output as: (a) `actions.json` schema, (b) the prompt template files, (c) TypeScript action handlers with the confirmation card, (d) an Entra-group authorization middleware, (e) a test matrix of ambiguous/destructive prompts and expected planner behavior.
Bias toward: confirmation before mutation, explicit refusal over guessing, full auditability.