Module 5: Team Adoption & Guardrails

Set up systems so juniors can execute without breaking your strategy

What This System Does

This module establishes the guardrails that allow teams to operate agents safely:

Define decision authority by role
Set override rules for junior team members
Create escalation paths for edge cases
Build onboarding SOPs for agent usage
Enforce guardrails without blocking progress

This scales your judgment without hiring senior people.

Prerequisites

Completed Modules 1-4
Team structure defined (who does what)
Clear on which decisions are reversible vs. irreversible

Step 1: Define Team Guardrails Standard

Create: `workflows/team_guardrails_standard.md`

Objective: Enable execution without breaking strategy.

Permission Levels

Junior: Can run agents, cannot approve budget changes
Mid: Can approve budget changes under $500/day
Senior: Full authority, sets standards

When Juniors Must Escalate

Budget changes over $200/day
New campaign launches
Creative outside brand guidelines
Risk score = high on pre-launch agent

Escalation Paths

Budget questions → Senior marketer
Creative questions → Creative lead
Technical issues → Ops/tools owner

Step 2: Create Role-Specific Templates

Build templates for each team level in `/workflows`:

bash

junior_workflow_template.md (step-by-step for common tasks)

bash

approval_checklist.md (what to verify before escalation)

bash

override_log.md (track when rules were bypassed)

Templates should be copy-paste ready with clear decision points.

Step 3: Build Onboarding SOP

Create: `workflows/team_onboarding_sop.md`

Onboarding Timeline

Week 1: Shadow senior running agents
Week 2: Run agents under supervision
Week 3: Run agents independently, report outputs
Week 4: Approved for solo execution

Junior must complete 3 supervised agent runs before solo approval.

Step 4: Implement Permission System

Use file-based permissions:

Create `/permissions` folder
Each team member has a `permissions_[name].md` file
Agents check permission file before executing sensitive actions

Example: IF budget_change > junior_limit THEN escalate

Step 5: Create Override Log

bash

outputs/override_log_YYYY_MM.md

Purpose: Track when and why guardrails were bypassed.

Step 6: Monitor & Adjust

Review override log monthly
Check if juniors are blocked unnecessarily
Refine permission thresholds
Update onboarding SOP based on common mistakes

Step 7: Iterate Quarterly

Survey team on friction points
Review escalation patterns
Adjust guardrails (looser or tighter)
Update role definitions as team grows

Common Failure Modes

Juniors blocked too often

Cause: Guardrails too strict

Fix: Raise permission thresholds for routine tasks

Guardrails ignored

Cause: No enforcement mechanism

Fix: Add approval requirement to workflows

Unclear authority

Cause: Edge cases not documented

Fix: Build decision tree for common scenarios

Why This Works

Execution scales without strategy breaking
Mistakes are prevented, not fixed
Authority is clear, not assumed
Onboarding is systematic, not ad-hoc

This is how teams grow without chaos.

← Previous: Module 4: Pre-Launch Risk Assessment Agent