GOGrowth Operator
Library

Pillar 02 / Agent systems

Build growth Agents around decisions, not personalities.

A growth Agent should own a bounded decision domain and produce reviewable work. It is not a mascot, a chat prompt or a list of installed Skills. The system becomes useful when context, tools, permissions, handoffs and outcome checks are explicit enough for a team to trust and correct.

01

Separate the building blocks

A Skill is a reusable method for one task. A tool reads or changes an external system. A specialist Agent applies domain judgment across several Skills and tools. A workflow connects multiple actors and checkpoints. An Orchestrator interprets the business goal, selects the minimum relevant specialists and resolves dependencies before work enters one action queue.

Keeping these roles separate prevents every capability from becoming a new Agent and stops internal architecture from overwhelming the user.

  • Skill: reusable task method
  • Tool: typed external capability
  • Agent: bounded domain judgment
  • Orchestrator: routing, dependency and priority control
02

Give every Agent a contract

The Agent contract should define its goal, inputs, evidence requirements, output schema, allowed tools, autonomy level, budget, fallback and evaluation. A free-form role description is not enough when the work can influence budgets, publication or customer communication.

The contract also states what the Agent must refuse or defer. Missing data, unavailable connectors and unresolved permissions should produce a visible gap or human task, not a simulated completion.

  • Required and optional context
  • Output artifact and acceptance criteria
  • Tool scopes and permission boundary
  • Time, token and money budget
  • Failure and recovery behavior
03

Let the Orchestrator select the minimum team

One business goal should not wake every Agent. The Orchestrator uses channel fit, evidence coverage, dependencies, risk and available capacity to select only the specialists that can change the current decision. Other work is deferred with a reason.

The user should see why a specialist was selected, what it needs and where its output goes. They do not need to configure a topology or compare a collection of Agent personas.

  • Read the goal and shared context
  • Apply mandatory stage gates
  • Select relevant specialists
  • Resolve conflicts and rank actions
  • Carry approved results into scoped memory
04

Keep handoffs structured

Cross-Agent handoffs need a shared Goal, Run and Trace reference. They should include evidence references, the requested decision, the output contract, permissions and unresolved questions. Free text can add nuance but cannot replace these fields.

Collision checks matter when several specialists may edit the same page, campaign, metric definition or audience. The system should lock the entity, sequence work or request a human decision rather than allowing contradictory changes.

  • Evidence and source references
  • Requested decision and owner
  • Entity affected by the work
  • Approval and rollback requirement
05

Evaluate the real workflow

Offline answer quality is only one signal. A useful evaluation also checks multi-part completeness, tool recovery, user correction, policy compliance, cost and whether the external result was actually verified. Version updates should run both deterministic regression cases and held-out tasks.

Learning enters durable memory only after review. Agents cannot grant themselves more permissions, rewrite their own evaluation rules or convert a tentative finding into permanent policy.