One person on your marketing team built the agents, and every wrong output still finds its way back to them. The pipeline report that counted trials as revenue, the routing rule that sent a demo request to nurture, the account brief with last year’s pricing: each one ends as a message to the builder, because nobody else knows where it should go.
This page is about splitting that work so the builder stops being the inbox for every agent: who runs them, who changes them, and who may edit the material every agent reads before it starts. It is written for the marketing leader who has just been told the fix is to teach the rest of the team to build.
Empact Partners builds agents for the go-to-market teams of B2B software companies, a practice we call marketing engineering. We are a consultancy, and our consultants have sat inside partners’ own teams since 2020. An agent lasts only if its handover holds, and the ones a team argues about most route leads, report pipeline or send outbound: RevOps work.
Training And Access Do Not Say Where A Correction Goes
The answer most teams reach for first is training. Samsara’s CMO, Meagen Eisenberg, said on the GTMnow podcast in September that the company had trained more than half of its marketing organization to build agents. That is a serious investment, and it answers a real question: who can build.
Training does not answer the question sitting in your builder’s inbox. Follow one bad output. A teammate runs the weekly pipeline report and it counts trials as revenue. They have two moves, and a bootcamp graduate makes the same two, faster:
Access is the other cheap answer, and we paid for that lesson ourselves. We built the Empact Panel to measure our partners’ visibility in AI answers and gave their marketing leaders logins. On three partner calls in October, three of those leaders told us they had barely opened it. One said they read our consultant’s report instead.
That remark says what access buys. The people whose job it is keep running the work, and everyone else reads the output.
Train the people who run agents, by all means, and train them first to file a correction, because that is the skill the builder’s inbox is missing. What gets handed over is neither a login nor a course. It is a set of permissions.
Run, Change, And Edit Context Are Three Permissions With Three Owners
Running an agent means giving it a job and judging what comes back. Changing it means editing its instructions, tools or steps, so every later run behaves differently. Editing the context means changing what every agent reads first: what counts as a qualified lead, which system holds true revenue, the voice rules, the accounts nobody emails.
Most teams hand all three to whoever built the first agent, by default, and the first two to anyone who asks. Split them on purpose:
| Permission | Who holds it | What it lets them do | Where a problem goes |
|---|---|---|---|
| Run | Everyone whose work the agent does | Start the job, judge the output, file a correction | The ledger |
| Change the agent | One or two builders | Edit instructions, tools and steps, test before release | The builder’s backlog, fed from the ledger |
| Edit the context | One writer, on rulings from whoever owns each definition | Change the definitions, rules and lists every agent reads | A ruling session the writer starts |
We run our own publication this way. The content system behind the Empact Zone went live on 17 September, and since then 61 articles have shipped through it, 43 of them under the bylines of eight consultants who did not build it. Every one of the 57 changes to its rules went through one person, the one whose name is on this page.
The other consultants did not stay quiet. Nine of them filed 55 of the system’s 92 correction notes in six weeks, and not one of those notes changed a rule on its own. Each waited in the ledger until it was ruled on, which is the reason ten people can write through a system without ten versions of its rules.
A team of six can give two of these permissions to one person. Write that down as a decision, because the default is that all three land on whoever built the first agent, and nobody notices until that person takes a vacation.
.png)
The third permission is the one nobody assigns, and it decides whether a correction ever reaches the next run.
Shared Context Gets One Writer And A Ledger Everyone Can Write To
What every agent reads before it starts is not one thing, and its parts go stale at different speeds:
Give that material one writer. Two people making sensible edits a month apart will contradict each other, and every agent obeys whichever edit it read last.
The writer applies rulings, and the rulings come from whoever already owns each definition: the head of RevOps for a qualified lead, finance for revenue, the content lead for the voice. The builder is often none of them.
Then give everyone else one place to write. A ledger is a shared list anyone can add to and nobody edits in place, with three fields: the run, what was wrong, what the person expected. The writer opens it on a fixed day and sorts each note before ruling, because the same wrong output can come from different places, and each has its own owner:
Until a ruling lands, runs carry on against the old context. Waiting for a ruling is slower than a message to the builder, once. It is the only version that still works when nine people are filing, and the writer’s ruling is what turns a correction made twice into a rule the next run already knows.
We run a partner’s content program the same way, with the roles turned around. The partner, a B2B software company, handed us its own content pack and its own review checklist, and we review every draft against that checklist word for word. Our consultants run the writing and review agents, and everything wrong goes into one ledger.
That ledger holds thousands of findings from our review runs and a few dozen of the partner’s own rulings, and the notes are ranked before anyone acts on them:
One person, the account lead on that partnership, applies every change, in calibration sessions started by hand, nine of them in October. The context owner in that program sits on the partner’s side, and the builder never decides what the partner’s voice is.
What practitioners on Reddit say about who writes to the context
“Agent can draft changes, but only a human or a narrower approval agent can promote them into the trusted folder.” — r/AI_Agents, Jul 2026
“i liked the concept but they never did more interviews so it felt like it got out of date -- and to your earlier comment, the process/tactics got out of date way faster than the constitution layer” — r/revops, Mar 2026
The second line is the one to plan around. The operating instructions go stale first, so the ruling sessions spend most of their time there, and the definitions get a look when the business changes.
A ledger tells you what the team corrected. It cannot tell you whether the team would run the job if the builder left.
A Handover Is Done When The Team Runs It Again Without You
We hold a handover to one test. The team runs the job a second time without the builder touching it, and the definitions it runs on are owned on their side. A first run proves the demo worked. The second proves somebody other than the builder owns the job.
The cleanest handover on our record is a measurement job. In June we wrote a data-request spec for a B2B software partner: the questions our content work needed from their own data, each with the reason we wanted it, and one ground rule at the top, that anything their data could not answer comes back marked unavailable, never estimated.
The first version had 363 questions. Their content lead ran it past the agent their data team already uses, told us which questions the data could not answer, and we cut it to about 140. In the middle of June their team gave the spec to that agent, which ran it against a read-only copy of their database. Nobody from our side touched their systems.
.png)
Eight weeks later a new source of data landed on their side, and their team reran the whole set themselves. The run answered seven of the ten follow-ups we had sent at the end of July, and every other question came back answered except one, marked unavailable.
Their content lead left seventeen rulings on the results, and those rulings now bind every request we send. They ran it, we changed it, and they owned the definitions.
What stayed with us is the builder’s real job after a handover: cutting 363 questions to the ones the data could answer, correcting one definition we had wrong, and refusing a split the data could not support. Scope, definitions and refusals. None of it was running the job.
Our records do not show hours, because nobody timed the builder’s week before and after. To get that number, count the messages to your builder for a month before the split and a month after, the measure we would agree with a partner before building. The rest of the test fits in five checks:
| Check | A handover that held | A handover that did not |
|---|---|---|
| The second run | The team ran it again without the builder | The builder ran it, or nobody did |
| Where corrections come from | Notes from the team, in the ledger | Messages to the builder, or silence |
| Who owns the definitions | A named person on the team’s side whose rulings bind | The builder, by default |
| What still reaches the builder | Scope, new definitions, refusals | Fixes to individual outputs |
| How success is checked | The result where it lands: the deal routed, the report matching finance | The agent’s own success message |
The last row is the easiest one to fool yourself on. An agent that finished without an error has told you it finished, and the only proof the job was done is the deal sitting with the right rep or the report matching what finance closed.
Most handovers never reach a second run, and the reason is usually which agent went first.
Start With The Agent Your Builder Fields The Most Questions About
The instinct is to hand over the agent the team uses most. Hand over the one that sends the most questions to the builder instead, because that is where the ledger fills first and where the builder gets the most of their week back. This week, in this order:
- Pull a month of messages to the builder and tag each one by agent.
- Take the agent with the most. Write down who runs it, who may change it, and who owns each definition it reads.
- Open the ledger: one shared list, add-only, with the run, what was wrong and what was expected.
- Tell everyone who runs it that a correction goes in the ledger and nowhere else, the builder’s messages included.
- Put a weekly ruling session in the writer’s calendar, on a fixed day.
Everything on that list fits in a week. What does not fit is the part that keeps it true: a ruling session every week, definitions that drift as the business changes, and the discipline of not handing over a second agent until the first one passes its second run. That takes a quarter and somebody whose job it is.
That longer part is the work we run. A RevOps engagement with Empact Partners opens with an audit of what your team repeats, then one agent for one job, a named consultant who answers for it, and the number it should move agreed before the build. Routing, reporting and outbound follow once that first agent passes its second run.
If every agent on your team still sends its mistakes to one person, book a time with me, and we will find out together whether this is work for Empact.
