TNTM Agentic Terraform Factory Playbook
Skills + Agents + MCP for module generation and intent-to-IaC composition
Build a TNTM-branded agentic factory that turns standards plus user intent into Terraform modules and composable IaC stacks. This playbook shows the operating model for Skills, agent orchestration, MCP integrations, validation gates, and governance controls.
Download the Playbook
Shareable versions for team onboarding, architecture reviews, and implementation sprints.
What You Are Building
A standards-aware module builder skill that generates complete Terraform module repos.
An IaC composer agent that turns user intent into dependency-aware infrastructure scaffolding.
An MCP tool layer for schema lookup, repo automation, and governed execution.
A validation and approval pipeline so speed does not break production guardrails.
Hard Rules
No module generation without explicit standards profile.
No infrastructure mutation from prompts without human approval.
No hardcoded environment values in generated examples.
No silent tool calls: all agent actions must be logged.
No direct production apply outside approved CI/control-plane executors.
Reference Architecture
# TNTM agentic Terraform factory (reference topology)
User intent ("2 web apps, 1 key vault, private endpoints")
-> Intent parser agent (normalizes quantities, env, policy constraints)
-> IaC composer skill (maps intent to module composition graph)
-> Module builder skill (generates/updates missing modules)
-> MCP tool layer
- Terraform docs/schema lookup tools
- GitHub/Azure DevOps repository tools
- Cloud policy lookup tools
-> Validation gates
- terraform fmt/validate
- static checks (tflint/tfsec/checkov)
- policy checks (OPA/Sentinel/custom)
-> Human approval for high-risk actions
-> PR with generated artifacts + rationale + run logsSkill and Contract Templates
Module Builder Skill Scaffold
---
name: azure-terraform-module-builder
description: TNTM skill that generates standards-compliant Azure Terraform modules from approved templates and schema lookups.
---
# Trigger
Use when a user requests a new module or asks to update an existing module schema.
# Required inputs
- Resource type (example: azurerm_linux_web_app)
- Resource abbreviation (example: app)
- Standards profile (naming, tags, providers, policy controls)
# Guardrails
- Ask for missing abbreviation before generation
- Do not continue if environment/policy profile is missing
- Use provider schema lookup before writing nested blocks
- Reject destructive changes unless explicitly approved
# Outputs
- Repo structure and module files
- Example folder with tfvars-driven usage
- Empty README.md (pipeline-owned docs generation)
- Validation report (fmt/validate/lint summary)Intent Contract (JSON)
{
"request_id": "REQ-2026-02-27-001",
"environment": ["dev", "staging", "prod"],
"region": "eastus",
"intent": {
"web_app": { "count": 2, "sku": "P1v3", "private_endpoint": true },
"key_vault": { "count": 1, "rbac_enabled": true },
"app_insights": { "count": 1 }
},
"constraints": {
"naming_standard": "TEN_v2",
"terraform_version": ">=1.5.0",
"provider_azurerm": ">=4.0.0",
"no_hardcoded_values": true
}
}Composition Pattern for "2 Web Apps + 1 Key Vault"
Dependency-Aware Terraform Composition
terraform {
required_version = ">= 1.5.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = ">= 4.0.0"
}
}
}
provider "azurerm" {
features {}
}
module "app_service_plan" {
source = "git::https://dev.azure.com/yourorg/_git/Azure.AppServicePlan.Terraform"
resource_group_name = var.resource_group_name
location = var.location
project = var.project
environment = var.environment
ten_regional_code = var.ten_regional_code
subscription_code = var.subscription_code
sku_name = var.app_service_plan_sku
}
module "web_app_01" {
source = "git::https://dev.azure.com/yourorg/_git/Azure.WebApp.Terraform"
resource_group_name = var.resource_group_name
location = var.location
project = var.project
environment = var.environment
ten_regional_code = var.ten_regional_code
subscription_code = var.subscription_code
service_plan_id = module.app_service_plan.id
key_vault_id = module.key_vault.id
}
module "web_app_02" {
source = "git::https://dev.azure.com/yourorg/_git/Azure.WebApp.Terraform"
resource_group_name = var.resource_group_name
location = var.location
project = var.project
environment = var.environment
ten_regional_code = var.ten_regional_code
subscription_code = var.subscription_code
service_plan_id = module.app_service_plan.id
key_vault_id = module.key_vault.id
}
module "key_vault" {
source = "git::https://dev.azure.com/yourorg/_git/Azure.KeyVault.Terraform"
resource_group_name = var.resource_group_name
location = var.location
project = var.project
environment = var.environment
ten_regional_code = var.ten_regional_code
subscription_code = var.subscription_code
enable_rbac_authorization = true
}MCP Policy Skeleton
Use explicit action tiers and policy requirements. Keep destructive actions denied by default.
policies:
- name: read-only-discovery
match:
actionTier: [1]
effect: allow
requirements:
- log_to_siem
- name: code-generation
match:
actionTier: [2]
tools: ["repo.write", "pr.create", "terraform.generate"]
effect: allow_with_conditions
requirements:
- standards_profile_present
- validation_passed
- log_to_siem
- name: infrastructure-mutation
match:
actionTier: [3,4]
tools: ["terraform.apply", "deployment.execute"]
effect: require_human_approval
requirements:
- approved_change_request
- ci_executor_only
- rollback_planAcceptance Checklist
# Release gate for generated IaC
- [ ] Module/resource names follow approved naming convention
- [ ] Required global variables are present
- [ ] No hardcoded environment values in example/main.tf
- [ ] terraform fmt and validate pass
- [ ] Lint/security checks pass (tflint/tfsec/checkov or equivalent)
- [ ] Generated PR includes dependency graph and assumptions
- [ ] High-risk actions routed to human approval
- [ ] All agent/tool actions logged for auditRollout Sequence
Phase 1: Skill Foundation
Create two skills: module builder and intent-to-IaC composer.
Keep templates deterministic (directory shape, required variables, pipeline files).
Define where agent freedom is allowed vs blocked.
Phase 2: Agent Orchestration
Wire parser -> composer -> module-builder as explicit handoffs.
Persist normalized intent as machine-readable contract JSON.
Require rationale output for every generated dependency decision.
Phase 3: MCP Integration
Add MCP tools for docs lookup, repo operations, and pipeline creation.
Classify each tool by risk tier and enforce least privilege scopes.
Start with read-only and code-generation actions before any deploy path.
Phase 4: Governance and Scale
Attach policy gates and CI validation to every generated change.
Track escaped defects, rollback frequency, and module adoption speed.
Promote only when quality metrics stay stable across at least two release cycles.
Sources
Companion Benchmark Article
Read the companion TNTM benchmark deep dive that explains why infra teams need their own evaluation harness and how architecture differences change outcomes.
Read the Benchmark Deep Dive