Agent operating guide
Operate the governed GTM lifecycle through certified read tools and Fabric Platform actions, with HITL only where policy requires it.
GTM Brain is designed for agents to do routine GTM work without creating an ungoverned fast path. Built-in Harness agents and enrolled external runtimes use the same Fabric Platform actions as the UI. The difference is identity and scope, not business semantics.
The operating loop
An agent should follow the product journey in order:
sense → remember → judge → draft → evaluate → approve or escalate → act → learn- Discover the live, registration-filtered catalog. Never copy a tool list from another tenant.
- Read the campaign, account, evidence, and operational projections granted to the registration.
- Request the narrowest governed action using a stable caller-issued idempotency key.
- Treat a proposal or
waiting_for_approvalresult as inert. Do not call a provider directly. - Poll or resume the durable workflow. Retry only responses classified as transient.
- Escalate to a person when policy returns HITL, evidence is ambiguous, or a critical decision is intentionally reserved for a natural person.
- Read the resulting audit/projection state before choosing the next action.
Campaign content actions
The artifact lifecycle is expressed as separate Platform actions:
| Stage | Action | Expected agent behavior |
|---|---|---|
| Draft | gtm.save_artifact_working_copy | Save campaign-bound content with an exact version and hash |
| Propose | gtm.propose_artifact_revision | Freeze the reviewed working copy as an immutable revision |
| Evaluate | gtm.record_artifact_evaluation | Record bounded findings against the exact revision/hash |
| Decide | gtm.decide_artifact_revision | Request only when catalog and policy allow; otherwise HITL |
| Publish | gtm.publish_artifact | Request a governed receipt; publication is not email sending |
| Retire | gtm.archive_artifact | Preserve history while removing obsolete content from use |
An independent passing evaluation is required before approval. The revision author cannot silently review its own work. If tenant policy requires a person, the agent stops at the approval boundary and surfaces the exact artifact, evidence, consequence, and recommended decision.
Artifact titles are not unique identities. Agents must always present and act on the tuple
artifactId + campaignId + campaignVersion + revision + contentHash. When a safe-test artifact is copied
into a separately reviewed live candidate, the canonical title and body may be identical even though the
governed bindings are different. User-facing summaries should append Dry run vN, Live candidate
vN, or Live vN from the authoritative campaign definition; if the campaign definition is missing,
show the known version and do not infer a delivery mode from the title or artifact status.
Effective authority
Seeing an action in source code or documentation does not grant it. Effective authority is the intersection of:
certified action contract
∩ enabled registration and immutable agent version
∩ unexpired tenant grant
∩ explicit action and campaign scope
∩ current tenant autonomy policy
∩ execution-time proof and resource checksGTM Brain derives tenant and agent identity from the authenticated registration. It mints capability proofs at the trusted server boundary and binds them to the tenant, actor, action, command, campaign, revision, and hash where applicable. Agents must never supply a different actor, tenant, proof, or retry-time command identity.
HITL and autonomous work
HITL is a governed outcome, not a parallel workflow. Routine sensing, qualification, drafting, evaluation, task creation, notes, and other explicitly delegated work can continue autonomously within finite runtime and budget limits. Human review is reserved for the boundaries configured by tenant policy, including ambiguous evidence, policy exceptions, approval decisions, and live-delivery promotion.
The UI and an agent should present the same escalation packet:
- current lifecycle stage and blocked action;
- exact campaign, artifact revision/hash, recipient, or account in scope;
- observed evidence and policy outcome;
- consequence of approval or rejection;
- one recommended next action.
Do not interpret approval as permission to skip later checks. Recipient qualification, suppression, daily capacity, sender binding, live canary, and provider-boundary checks run again at delivery.
Live delivery boundary
General external-agent registrations do not receive the internal
gtm.send_approved_outreach_v2 workflow action or gtm.promote_campaign_live. An agent may prepare a
campaign, run its delegated review work, and request permitted actions, but controlled promotion and
approved delivery follow the separately configured live-launch policy. The system fails closed when the
live canary, sender mailbox, eligible recipient, manifest, or required approval is missing.
For the exact installation and MCP invocation contract, continue to the External agent gateway. For the operator-facing sequence, read Run your first campaign.