Every AI action has a trigger, an outcome, and a logged reason.

One loop that gets sharper every cycle

Most "AI automation" is a one-way street: a rule fires, something changes, and nobody records whether it worked. TAI is a closed loop. Every cycle leaves a record, and that record makes the next cycle smarter.

The first four stages give you accountability. The fifth, the feedback step, is what makes the system compound. Here is each stage in detail.

What is a trigger?

A trigger is a defined condition that initiates an automated action. It is a specific, observable data event, not a blind timer or a guess. The system checks for it on a schedule, but it only moves to the next stage when the condition is actually met.

Triggers are written in plain language and translated into machine-readable rules during sprint configuration. Examples include:

• CPA exceeds target threshold by more than 20% over a 3-day rolling window
• An inbound lead has not received a follow-up within 4 hours of form submission
• A keyword's quality score drops below 5 for two consecutive weeks
• Monthly ad spend reaches 80% of budget before the 20th of the month

Each trigger is documented in your AGENTS.md file and is reviewable, editable, and version-controlled. Triggers do not fire actions directly. They initiate a guardrail check first.

How a trigger actually runs

The watching is done by a scheduled agent. Claude, Cursor, and Codex all support scheduled "wakeup" tasks: an agent that wakes on a cron-style schedule, pulls the latest data (a Google Ads export, a GA4 report, a Search Console pull), and evaluates the condition. If nothing is met, it stands down and writes a "no action" line to the log. If the condition is met, it moves to the guardrail check. The schedule decides how often the system looks; the condition decides whether anything happens.

trigger:
  condition: CPA > target_CPA * 1.38
  window:    3-day rolling average
  source:    Google Ads API export (CSV)
  engine:    scheduled agent wakeup (Claude / Cursor / Codex)
  check:     daily at 06:00 EST

How guardrails interact with TAI

Guardrails are the conditions that must be satisfied before a trigger can fire its action. They sit between the trigger and the action, and they run on every cycle — not just the first time.

There are four standard guardrail types in our framework:

• Spend guardrails — daily, weekly, and monthly caps. No action can exceed these. Period.
• Brand guardrails — brand exclusion lists, approved messaging matrices, tone constraints for automated copy.
• Approval guardrails — actions above a defined threshold (e.g. budget changes above $5,000) require explicit human sign-off before execution.
• Conflict guardrails — if two triggers fire simultaneously and their actions conflict, a conflict resolution protocol determines priority and the lower-priority action is queued.

Guardrails are configured in your AGENTS.md file. They are plain language by design — a non-technical team member can read, understand, and update them without engineering support.

guardrails:
  spend_cap_daily:   $3,000
  spend_cap_monthly: $68,000
  brand_exclusions:  [competitor_names.txt]
  approval_threshold: budget_change > $5,000
  conflict_protocol: highest_impact_first

What is an action?

An action is the specific change the system makes in response to a confirmed trigger, after all guardrails have been evaluated and passed.

Actions are scoped, bounded, and reversible by design. We do not build actions that make irreversible changes without a human approval gate. Every action has:

• A defined scope (which campaigns, ad groups, contacts, or records it touches)
• A maximum change magnitude (e.g. bid adjustments capped at ±30%)
• A rollback mechanism (logged before-state enables reversal)
• An approval gate option (some actions can be set to "notify and wait" rather than "execute immediately")

Actions are the deliverable of a sprint. When we hand over a sprint, we hand over the full action library: what each action does, when it fires, and how to modify or disable it.

How an action executes

When a trigger clears its guardrails, the agent makes the change through a real connection to your account, not a screenshot or a suggestion you have to action yourself. We connect through MCP, the Model Context Protocol, or a platform API to Google Ads, Meta, GA4, or your CRM, and the agent performs the change directly: pause a campaign, add negative keywords, shift budget, adjust a bid. Because it runs through your own connection with scoped, revocable credentials, the action is real, logged with a before-state, and reversible.

action:
  type:      pause_ad_groups
  targets:   [AG-004, AG-007, AG-011, AG-019]
  via:       MCP -> Google Ads (scoped credentials)
  secondary: reallocate_budget -> top_performing_ad_groups ($1,200)
  approval:  auto (guardrails passed)
  logged:    before_state captured for rollback

What is an impact?

Impact is the measured outcome of an executed action, logged at the time of execution and tracked over the following observation window.

Impact is not a projection or an estimate. It is a before/after comparison logged automatically when the action runs. The impact record includes:

• The metric that changed (CPA, lead volume, conversion rate, time-to-action)
• The before value and the after value at the observation window close
• The number of human approvals required (target: zero for routine automations)
• A timestamp and action ID for cross-referencing with the activity log

Impact is tracked across whatever the action touched: PPC metrics like CPA, ROAS, and Quality Score, and SEO metrics like rankings, impressions, and clicks. Over time the impact log becomes a performance record, and that record is what powers the feedback loop below.

impact:
  metric:          CPA
  before:          $94.20
  after:           $61.23
  change:          -35%
  observation:     90 days
  approvals_req:   0
  action_id:       ACT-2024-1114-003
  logged:          2024-11-14T06:04:22Z

The part that compounds

An automation that pauses a campaign is useful once. A system that records every action, measures what it changed, and feeds that back into the next decision gets better every cycle. This is the difference between an automation and an intelligence layer, and it is the part most "AI automation" leaves out.

Every action writes a record: the trigger that fired it, the guardrails it passed, the change it made, and the impact over the observation window. That record is not just an audit trail. It is training data for the system's own thresholds. The loop reads it and proposes refinements:

• Triggers get sharper. A trigger that fires often but moves nothing gets its threshold tightened. One that fires too late gets loosened. If pausing at CPA +38% keeps recovering spend, the system can recommend acting earlier, at +30%.
• Actions get better scoped. Actions that consistently stay well under their guardrail caps have room to scale. Actions that overshoot get pulled back.
• Guardrails get calibrated to how your accounts actually behave, not a generic default.

Refinements are proposed, not silently applied. Each one lands in the log as a recommendation with the evidence behind it, and waits for a human yes. You keep the wheel; the system keeps getting smarter about where to point it.

# Feedback ledger -- trigger refinement
ACT-003 | pause @ CPA>+38% | impact: -35% CPA | verdict: effective
ACT-009 | pause @ CPA>+38% | impact: -31% CPA | verdict: effective
ACT-014 | pause @ CPA>+22% | impact:  -6% CPA | verdict: marginal
-> recommendation: tighten trigger to CPA>+30% (acts earlier, recovers more)
-> status: awaiting human approval

Over enough cycles, the loop turns a static rule set into a system that reflects your accounts. Running it continuously, month over month, is exactly what the Campaign Strategy Portal is for.

The activity log

Every trigger evaluation, guardrail check, action execution, and impact measurement is written to a structured activity log. The log is delivered as part of every sprint handoff and is updated continuously as the automation runs.

The log serves three purposes:

• Accountability — you can see exactly what the AI did, when, and why. No black boxes.
• Optimization — the log surfaces patterns. Triggers that fire frequently but produce small impact may need threshold adjustment. Actions that consistently stay under guardrail limits may have room to scale.
• Compliance — for teams subject to internal audit, marketing governance, or client reporting requirements, the TAI log is a structured audit trail in a format designed for review.

The log is exportable as CSV or JSON and can be piped into any reporting tool your team already uses — Google Sheets, Looker Studio, HubSpot, or a custom dashboard.