Give your GTM agents goals, not tasks

Most GTM agents today are handed a to-do list.

Build a list of 100 accounts. Enrich it. Draft the first emails. Ping the rep in Slack. Then the next request, and the one after that, each done perfectly.

Somebody wrote each request, on some day, based on what they believed at the time. The agent carries them out without once asking whether the last one worked. If the last list of 100 produced no pipeline, the agent builds the next one exactly the same way. Very efficiently.

That isn’t the agent failing. It’s the instruction.

Tasks tell agents what to do. Goals tell them what to improve.

A goal-driven GTM agent owns a measurable business outcome, with a number and a deadline, instead of a list of steps. It runs the current workflow, measures whether the outcome is moving, and proposes experiments, changes and new initiatives when the evidence says it should, within limits a person sets and approves.

An earlier piece in this series, stop rebuilding, start improving, showed how a versioned GTM system learns from what it runs. This one is about what drives that loop: what you give an agent so it pursues an outcome instead of repeating a procedure, what it needs before you can trust it with one, and where the goal has to live.

We’ve been giving agents the wrong instructions #

The industry already agrees on the direction. An Apollo piece on agentic GTM put it this way this summer: “The agent becomes the operator, in a way, and the human just sets the goals and guardrails for it.”

The direction is right. The word “just” is wrong.

Setting the goal isn’t the easy part left over for the human. It’s the hard part. And a goal typed into a prompt is still a task: nothing measures it, nothing remembers it, and nothing stops the agent from hitting it the wrong way. The question that framing never asks is where the goal lives, how anyone knows it’s being met, and what the agent is allowed to change in pursuit of it.

Here’s how a task-based GTM agent is usually specified:

TASK-BASED AGENT

Generate a list of 100 companies in B2B SaaS, post-Series B,
not already in the CRM.

It’s clear, and the agent will do it well. You can check that it ran: 100 companies, all B2B SaaS, all post-Series B, none in the CRM. You can’t check that it worked. Did any of them become pipeline? Were they the right 100, or just the first 100 that matched? Next month someone asks for another list, and nobody knows whether the last one produced anything. The instruction never says what it was for, so the agent can’t know either.

Now the same job, as a goal:

GOAL-DRIVEN AGENT

Generate 1.5x more qualified pipeline in the next six months
than in the last six, from any source: new logos, upsell or
cross-sell. Without increasing irrelevant outreach.

Four things changed. It names a number and a deadline, so anyone can tell whether it’s working. It names a guardrail the agent can’t trade away to hit the number. It leaves the how open, including where the pipeline comes from. And it doesn’t end when the list is delivered: it’s still true next week, so the agent has a reason to check what last week produced.

A goal without a number isn’t a goal. “Improve pipeline” is a mood, and any agent can claim progress against it.

The most advanced in-house teams already work this way. One GTM engineering lead we spoke to recently, at a large software company, gives every agent he runs a number to own: a share of pipeline it is responsible for. He also runs one agent whose only job is to check the other agents every day. He built it in-house, over four years.

What changes when an agent owns a goal? #

A task-based agent asks one question: did I do what I was asked? A goal-driven agent asks a different one: what would move the number?

That question changes what the agent does. Give an agent a goal, and it starts to experiment. It tests a new segment on a small batch. It tries a different signal or message against the current one. It notices that expansion is carrying more of the number than planned and suggests an initiative around it. It proposes stopping a play that books meetings nobody converts. A task invites none of that, because the task already decided what to do.

That’s the entire shift. The agent stops executing your plan and starts proposing the next one.

Experiments still need limits: a small batch, a budget, a stop condition, and a person who says yes before anything scales. That’s what the rest of this piece is about.

How do you write a goal an agent can pursue? #

Start with the danger. An agent with a goal will hit the number the cheapest way it can find.

Tell it to grow pipeline 1.5x, and it has easy options. Loosen the definition of qualified. Open an opportunity for every reply. Email everyone in the market three times. Push every customer onto an upsell call. Each one moves the number. Each one is wrong, and a task-based agent could never have done any of them, because it wasn’t allowed to change anything.

So the sentence from the first section isn’t enough, including its guardrail. “Without increasing irrelevant outreach” sounds like a limit. It isn’t one until it’s a number.

Here is the same goal, written so an agent can pursue it:

## O2. Qualified pipeline grows 1.5x

- **Why:** pipeline has to carry next year's plan. Expansion counts
  as much as new logos.
- **Owner:** CRO
- **Metric:** sum of amount on CRM opportunities created in the
  window, stage Discovery or later, renewals excluded
- **Baseline:** calculated by the agent, last six months
- **Target:** at least 1.5x the baseline over the next six months
- **Weekly signal:** opportunities created, by source, against the
  weekly pace the target needs
- **Guardrails:** negative replies and unsubscribes no higher than
  last month; new pipeline reaches stage 2 at least as often as in
  the baseline window
- **Experiment budget:** up to 10% of send volume, 200 accounts and
  2 weeks minimum per test, success bar written before launch
- **Agent may:** run tests inside the budget, reorder queues
- **Agent proposes:** new segments, changes to fit, routing or
  messages, new initiatives
- **Escalate when:** under 1.2x of the baseline pace at week 8

Every line is there because an agent misbehaves without it.

A number it can calculate. This is the most common way goals fail. If the agent can’t compute “qualified pipeline” from your CRM, it will chase something it can compute, like meetings booked, and report progress on that. Define the number by its source, its filters and its window, not by a word.

A baseline, calculated. “1.5x” means nothing without the starting point, and the agent should calculate it itself. If its baseline and yours differ, you’ve found the ambiguity before it cost anything.

A weekly signal. A six-month target gives clear feedback twice. The weekly signal, and the weekly pace the target needs, is what the agent steers on in between.

Guardrails as numbers. Including one against inflating the metric itself. Pipeline is the easiest number in GTM to fake, which is why the second guardrail checks that new pipeline still reaches stage 2 as often as it used to.

An experiment budget. This is what makes experimenting safe. You approve the budget once: how much volume, how many accounts, how long. Inside it, the agent tests on its own, and every test writes its success bar down before it starts, so a result can’t be reinterpreted afterwards. Outside it, the agent proposes.

Who decides what, and when to raise a hand. The agent may argue that the target is wrong, with evidence. It never changes the target, the metric or the guardrails.

Why. Armies call this commander’s intent. When the plan meets a situation nobody foresaw, people fall back on the purpose. An agent with only the rule follows it to the letter. An agent that knows the purpose can make sensible calls when the rule doesn’t cover the case.

Before you hand the goal over, test it. Ask the agent to calculate the baseline and restate the goal in its own words. If it can’t calculate the baseline, the metric isn’t defined yet. If its restatement differs from yours, the goal is ambiguous. It’s the cheapest check there is.

The goal also rests on context the agent has to read: the ICP, what a qualified opportunity is, which customers have room to grow. Aurélien covered what that means for an agent in building and contextualizing GTM agents. A goal raises the stakes. An agent with a task and bad context writes a bad email. An agent with a goal and bad context changes your system in the wrong direction.

What does goal-driven GTM look like in practice? #

Take the pipeline goal and follow it around the loop.

Goal. The file above. The agent starts by calculating the baseline and reading the context the goal depends on.

Execute. The agent runs the current plays as written: outbound to the target segments, signup routing, the expansion plays account managers already use. Nothing new yet. This is the baseline everything else is measured against.

Evaluate. Every week, the agent splits new pipeline by source and segment. Is the weekly signal on pace for 1.5x? Which sources carry it: new logos, upsell or cross-sell? Which segments, signals and messages produce opportunities, and which produce meetings that go nowhere? And are both guardrails holding?

Improve. Small tests inside the experiment budget, the agent runs and reports on its own. When a pattern holds across enough accounts to be more than noise, it writes a proposal: a change to a play, a bigger experiment, or a new initiative. It contains the evidence, the smallest step that would act on it, the outcome it expects to move, and a replay of the change on past accounts to show what would have happened.

Then it stops, and a person decides.

Notice what happened to the list of 100 companies. A goal-driven agent may still build lists. But now it decides which list, and it knows whether the last one produced pipeline.

Goal-driven doesn’t mean unrestricted

The agent can find opportunities, run small tests and propose changes. It shouldn’t redefine the company’s strategy, change major scoring policy on its own, or act outside its authority. The goal file already draws that line: what the agent may do alone, what it must propose, and the three things it never changes, which are its own target, metric and guardrails. In our own engine, the same split puts enrichment and stopping a sequence after a reply with the agent, changes to the ICP or scoring with the agent proposing and a person approving, and commercial commitments with people only.

One goal, ten days

Here’s that loop on one goal. Watch the clock.

Say you split off one slice of the pipeline goal as its own outcome, and hand it to a second agent:

GOAL

20% of new qualified pipeline from expansion within six months,
up from 8% today. Stop replies and unsubscribes
from customers stay under 1% of customers contacted.

Day 1: replay the past. Before it touches a single customer, the agent replays the last year. Every customer whose usage jumped, at 20% and at 40%, and which of them turned into expansion pipeline. The 20% trigger fires constantly and almost never converts. The 40% trigger converts better. Add a third-party signal, the customer hiring in the team that uses the product, and the combination beats either signal alone. That’s a month of spreadsheets for a person. The agent has it the same day.

Days 2 to 9: three versions at once. The agent tests the winning trigger three ways in parallel, inside its experiment budget, with the bar for each written down first: an automated email, an email sent in the account owner’s name, and a Slack message to the account owner with what changed, who the customer is hiring, and a suggested first line, so the owner writes it themselves. On day 4 the automated email crosses the 1% stop-reply line, and the agent pauses it, as its goal allows, and says why. By day 9, only the Slack version clears its bar.

Day 10: the proposal. Usage up 40% in 30 days, plus hiring in the team that uses the product, sent to the account owner in Slack instead of a sequence. The replay and the three live results are attached. The agent proposes making it a permanent play, and you approve it.

Ten days. A team running the same tests by hand would spend the quarter on it: one test at a time, a meeting to read each result, the next idea waiting for the next planning cycle. That gap is what I call System Improvement Velocity, and it’s where agents leave any team working by hand behind.

Nobody asked for that play. The goal found it. A task would have produced the first email and sent it forever. The goal produced a combination nobody had written down: first-party usage data, a third-party hiring signal, and a person instead of a sequence.

Plain runs the same loop on its scoring model: a weekly job asks whether the scoring model is missing high-value accounts, and when it is, proposes the rule change as a pull request, priced in accounts moved. How it works is in let an agent propose changes to your scoring model.

Manifest: give your agents a system to operate #

A goal in a prompt disappears when the session ends. A goal in a repository is something an agent can be held to: it has an owner, a number, a history, and a place where the evidence piles up.

Manifest is our free, open-source template for that repository, extracted from the one our own GTM team works in. Six folders matter for goals:

plan/          the objective, and the outcomes that must become true
context/       ICP, personas, market knowledge, business policy
initiatives/   bounded work, each one tied to an outcome
infra/         what agents execute through Cargo, as code
evals/         tests that a change is safe and better
outputs/       dated evidence of what ran and what it produced

Here is where the pipeline goal lives in it. The structure and field names are the template’s. The numbers and names are an example.

plan/ holds the goal. The file in the section above is an entry in plan/outcomes.md, field for field. Every outcome there carries a why, an owner, a metric, a baseline and a target. An outcome an agent owns adds the weekly signal, the guardrails, the experiment budget, what the agent may do, what it proposes, and when it escalates. Three more lines finish it:

- **Verify:** the weekly pipeline entry in outputs/, read from the CRM
- **Becomes:** the pipeline agent, starting with
  infra/plays/new-logo-outbound.ts and infra/plays/expansion-signals.ts
- **Serves:** move 1 in plan/company-plan.md

Becomes is the line that connects a goal to something that runs. The template’s own rule: an outcome with no Becomes: is a wish. For a goal an agent owns, it names the agent and the plays it starts with, not every play it will ever run. The next ones come from the agent.

context/ holds what the agent must know. The ICP, the personas, what a qualified opportunity is, which customers have room to grow, the outreach rules. One claim per file, in plain text. The template sets the bar for adding one: a claim enters context after it shows up twice in the real world. Once is an anecdote. The same bar keeps an agent from rewriting your ICP off one strange account.

initiatives/ is where the agent’s ideas land. One file per bounded effort, tied to the outcome it serves, with success criteria that are true or false. When the expansion agent from that quarter wants its winning combination to become a permanent play, it doesn’t ship it. It writes this:

---
title: Ping account owners on usage growth plus hiring
status: proposed
owner: CRO
serves: O3 in plan/outcomes.md
---

## Why now

A replay of the last year and three live versions over ten days,
each in outputs/. Usage growth plus hiring in the team that uses the
product, sent to the account owner in Slack, cleared its bar. Both
email versions did not.

## Success criteria

- [ ] At least one expansion opportunity per 10 customers flagged,
      over the next eight weeks
- [ ] Customer stop replies and unsubscribes under 1%

## Approach

1. Flag customers whose usage grew 40% or more in 30 days and who
   are hiring in the team that uses the product.
2. Send the account owner a Slack message with both facts and a
   suggested first line.
3. Report opportunities created every week in outputs/.

## Log

- Proposed by the expansion agent after the replay and three live tests.

It’s marked proposed. A person moves it to active, or doesn’t. That one field is the line between an agent that suggests work and an agent that assigns itself work. The log is append-only, so the next session starts from what was tried, and why it was accepted or turned down.

infra/ holds what runs. The plays and the pipeline agent, declared as code. When the initiative goes active, the new play lands here as a pull request. Cargo plans every pull request against the live workspace, so the reviewer sees exactly what will change, and deploys on merge.

evals/ holds the tests a change has to pass. Cases the agent’s judgment must get right: the clear fit, the clear miss, the account that’s too big, the account with no data. One rule in the template does a lot of work here: when an agent’s prompt changes, its test suite changes in the same pull request. How to build the suite is in evaluate a GTM agent before it reaches production.

outputs/ holds the evidence. One dated entry per run or review, each with an outcome: field, what it actually produced in numbers, and the outcome it serves. Agents read recent entries before starting related work. This is where the weekly pipeline-by-source report lands, and where the next proposal gets its evidence.

Put together, a proposal from the pipeline agent is a pull request that touches infra/, updates evals/ if a prompt changed, and cites the entries in outputs/ it relies on. The template’s pull request form asks for one more thing that matters here: what was observed, and what is being concluded from it. That’s the difference between “pipeline is behind” and a change a sales leader can approve.

Manifest gives agents a durable operating framework. Cargo gives them the production infrastructure to execute it. The repository says what the goal is, what the agent knows and what it may change. Cargo runs the plays and agents with your company’s credentials, traces every run and every step, and turns each reviewed merge into a production change. The traces are what the evidence is made of. What it takes to run that layer is in AI agents in production.

None of this makes the loop autonomous. It makes it possible to hold an agent to a goal, and makes every change it proposes something a person can read, test and undo.

Humans stop operating tasks. They start governing systems. #

When agents run the tasks, a person’s most valuable work is commercial judgment: choosing the goal, setting the guardrail, weighing trade-offs, and approving the changes that matter.

An agent can’t decide those trade-offs for you. More pipeline against your reps’ capacity. Expansion that’s easy to open and hard to close. A segment that converts fast and churns fast. A message that books meetings and costs you brand. Those are business decisions, and they belong to whoever owns the number.

In the expansion example, the most important decision wasn’t the agent’s. It was one line in the goal: customer stop replies stay under 1%. That guardrail is what pushed the agent away from more email and toward the account owner. Leave it out, and the agent optimizes, with great discipline, toward annoyed customers.

Approval doesn’t have to stay on everything forever. Autonomy is earned one workflow at a time: the agent proposes and a person approves until a workflow has a clean track record, then approval moves to exceptions only. Our own workflows run at both levels today. Nobody’s whole GTM moves to autonomous at once, and a change to who you sell to should always reach a person.

The morning question changes too. It used to be “did everything run?” It becomes: what did the agents do, what did they learn, and what should I approve?

Where to start #

Pick one workflow you already run as a task. Write down the goal it serves: the number and how to calculate it, the target and the date, and one guardrail against inflating it. Give it one owner. Ask the agent to calculate the baseline and restate the goal. Then ask it one question every week: is this working, and what would you try next?

The answer will tell you more about your GTM than the workflow ever did.

The best GTM agents won’t be the ones executing the most tasks. They’ll be the ones making the most progress toward the right goals.

See how Cargo can run your GTM infrastructure.

Prefer to build it yourself? Clone Manifest, write your first outcome in plan/outcomes.md, and point your coding agent at it.

FAQ #