GrowthHarness GitHub

The team

Agent TeamA multi-agent harness for work that takes weeks

A fixed skeleton, with judgment inside it.

GrowthHarness runs an unattended SEO team: a Leader, specialists for strategy, keywords, topics, writing and review, and a Learning Agent working off stage. The collaboration layer is general. Swap the agent definitions and the business tools for your own, and let a Leader take a piece of your attention off your plate, so all you do is judge yes or no.

1Leader
7specialists
20writers in parallel

The team

One Leader, seven specialists.

Each member has its own brief and its own continuous session. Work goes down as a written assignment and comes back up as a report. Nobody reads another member’s private notes, and specialists report to the Leader, never to each other.

The team and who reports to whomThe Growth Leader hands work to the Strategist, the Topic Editor and the Editor-in-Chief, and sometimes to the Deep Researcher. The Strategist hands work to the Keyword Researcher and the Deep Researcher. The Editor-in-Chief runs several Writers and a Reviewer. The Learning Agent works off stage.Growth Leaderthe only door in, decides and reportsStrategiststrategy per languageTopic Editorone topic group at a timeEditor-in-Chiefruns the content teamDeep Researcherone scoped question, with sourcesKeyword Researcherthe keyword libraryor straight to the LeaderWriters × none article eachReviewerreads one locked draftLearning Agentoff stage, no deskcontent groupone boundary for content outputThe Leader’s group makes the macro call for one SEO task. The Editor-in-Chief’s group produces content. Specialists report upward, never sideways.

Scroll sideways to see the whole diagram.

RoleWhat it doesWhat it hands back
Growth Leaderreports to youUnderstands the business and the goal, decides which specialist takes each piece of work, approves topics, decides what goes live and follows up on results. It does not write articles. It asks you only when a business fact is missing, and your answer is information, not approval.Decisions and follow-ups
Strategistreports to the LeaderStudies the search landscape of each language market and keeps a versioned strategy for it. It may conclude that no new version is needed.A strategy version, with sources
Deep Researcherto the Leader or StrategistInvestigates one scoped question across the web and ties every finding to its source.Findings, sources and what is still unknown
Keyword Researcherreports to the StrategistFinds what people really type inside the directions the Strategist chose. It is the only AI allowed to edit that language’s keyword library.Library changes and a conclusion per direction
Topic Editorreports to the LeaderPicks the next topics worth writing from the keyword library and what is already published. When the evidence is thin it asks for research instead of filling a quota.A topic group, or a research request with the reason
Editor-in-Chiefreports to the LeaderPlans what each page covers, assigns writers and reviewers, up to 20 at once, and sends revisions back to the same writer.Reviewed articles, ready for the Leader
Writerreports to the Editor-in-ChiefResearches and writes one article and saves the evidence for every factual claim. It may decline a review note, if it explains why.A locked draft with its evidence
Reviewerreports to the Editor-in-ChiefReads one locked draft on its own and never sees how it was written, so it reads it the way a customer will.Pass, revise with specific changes, or defer
Learning Agentoff stageHas no desk in the room. It records what each piece of work tried and scores it against real Search Console results.Experience the Leader can choose to apply

A group of delegation relations is a business boundary. The Leader’s group makes the macro judgment for one SEO task. The Editor-in-Chief’s group produces content. You can draw the boundaries of a multi-agent team in your own business the same way.

Skeleton and judgment

Neither a pipeline nor a free-for-all.

There are two common ways to make agents cooperate, and each has a real advantage. This team keeps both.

Between workflow and agenticA spectrum from fixed workflow on the left to agent-chosen delegation on the right. This system sits in the middle, a fixed skeleton with judgment inside it.WORKFLOWhard-coded cooperationstrong control, some steps must be rigidAGENTICeach child registered as a toolthe parent picks who does whatskeleton + judgmenta fixed frame, with the agent deciding inside it

Scroll sideways to see the whole diagram.

Workflow

Agents are chained by hard-coded cooperation rules. It gives strong control, and it suits the steps in an enterprise that really must be rigid.

Agentic

Every child is registered as a tool on the parent, and the parent picks which one takes a task. It suits fuzzy, dynamic work where the edges of the task are unclear.

Fixed in code

  • Who may hand work to whom, and who reports to whom.
  • The life of an article: queued, drafting, QA, awaiting review, publishing, published. It mirrors how a person writes one, and writing is the core of SEO.
  • Hard rules: workspace isolation, publication rules and quality checks.

Left to the agents

  • What to research and write, and whether the evidence is enough.
  • Who takes which piece of work, and how deep to go.
  • How to recover after a failed attempt, and when to defer instead of guess.

Delegation

Hand the work out. Take only the result back.

To the Leader, a sub-agent is a tool, disclosed step by step and mounted when needed. But a child is a full task: its own task, its own conversation, its own worker. The parent sees what it produced, never how it got there.

A child’s id comes from the parent’s decisionThe parent makes numbered decisions. The child started by decision 3 gets an id computed from the parent task and the decision number, works in its own conversation, and returns a short result. If the parent is replayed, decision 3 computes the same id, so no duplicate child is created.Parentdecides, delegates, waitsChildits own task, session, workerRerunthe parent host crashes and replaysdecision 1decision 2decision 3decision 4decision 5decision 6works in its own long conversationid = f(parent task, decision 3)result, evidence, limits or failurereplays decision 3: computes the same id, so no second child appears

Scroll sideways to see the whole diagram.

01Authority is split

A parent can create, dispatch and cancel a child, but cannot pretend to be it. When a parent is cancelled, every descendant’s business writes are blocked at once, so nothing is left running with nobody in charge.

02Ids are computed

A child’s id comes from “which parent task, which decision”. If the host dies mid-way and the work is replayed, the same id comes out again, so a second Editor-in-Chief is never dispatched.

03Results, not receipts

Delegating returns a dispatch receipt straight away, and accepting a job is never treated as delivering it. The parent receives results, evidence, limits or the reason for a failure, and only from its direct children.

One task across time

The same task, even after being cut into pieces.

In a short task, multi-agent is a problem of space: who does what and what to share. In a long task it becomes a problem of time. Even a single agent working for hours is sliced into a series of different selves, and the question becomes how a task stays the same task.

The context is compressed

What comes next sees only a summary, not the whole original process.

The worker is replaced

Another run takes over after an interruption or a platform limit.

A release lands mid-flight

New tasks get new prompts and tools while old ones are still running under the old rules. And while a task waits, the world moves: an article is edited, another agent decides something.

Common approachHow it carries onThe problems they admit
Long-running agent frameworkAnthropic, 2025-11Each session starts from a fresh context and reads a progress file and the git log.A later agent sees progress and declares the work done too early, or marks it done without end-to-end testing.
Multi-agent research systemAnthropic, 2025-06Near the context limit it summarises finished phases, stores them in external memory and sends a fresh sub-agent.The lead agent waits synchronously for its sub-agents, which becomes the bottleneck.
Context compressionCognition, 2025-06A dedicated model condenses the history.Hard to do well. It may need a specially fine-tuned model.

Our answer in one line: the system’s records count, and notes are only clues. A task is not carried forward by a notebook someone rereads. It is carried by facts the database captured when they happened.

Records, not notes

  • The original records are all kept. A summary only decides what the model reads this turn. Any original message can be read back by its number.
  • Some things never go through a summary. Which object was acted on, which version was seen, which action really succeeded and what it produced are recorded when the action happens, so a badly written summary cannot corrupt them.
  • Objects are chosen by id. The model picks one from the references the system gave it. Writing “go and do group two” in prose does not count.
What counts as factand what does not
Fact
The system’s records of objects, versions, actions and outputs.
Clue
The Leader’s work notes. The background written into a delegation. Kept as “its understanding at the time”, never read as fact.
Why
An unverified premise went into a work note, then into a delegation, then into a sub-agent’s report. It looked confirmed three times, and it had never been checked once.
Rules travel with the taskTasks A and B were created under version 1 and finish under it even after versions 2 and 3 ship. Tasks C and D run on version 2. Task E, created after version 3, runs on version 3.Rules in forcea task keeps the version it was created withv2 shipsv3 shipsTask A · runs on v1Task ATask B · runs on v1Task BTask C · runs on v2Task CTask D · runs on v2Task DTask E · runs on v3Task EOld tasks finish under old rules. New tasks get the new ones. Every version stays registered for as long as a task still needs it.

Scroll sideways to see the whole diagram.

Rules travel with the task

A task keeps the prompt and tool versions it was created with, to the end. In the code, the Leader’s delegation tool exists in seven versions at once. Old tasks finish under the old rules and only new tasks use the new ones.

Why accept the cost

A long task always meets a release. If the rules changed mid-flight, the same decision could come out differently under the new rules and the before and the after would no longer join. The price is real: old code has to stay for a long time, and old tasks do not get the new fixes.

Handoffs

Results find their own way up.

Most of a long task is spent waiting, and while it waits no agent is thinking about it. So who should receive which result has to be remembered by the system, not by anyone.

Results find their own way upA child task changing state causes a database trigger, in the same transaction, to write a report event. A subscription delivers it to the Leader’s inbox. The event moves from pending to delivered to processed, and only calling the process action counts. Delivered but unprocessed events are reminded the next day.Child taskstate changesDatabase triggersame transactionReport eventa fact, not a commandSubscriptionwho cares about whatLeader’s inboxin its original conversationpendingnot delivered yetdeliveredin the inbox, unread or unhandledprocessedonly when the agent calls the process actiondelivered but not processed: reminded again the next dayNobody has to remember to report,and nobody has to remember to look.A line of text saying “handled” does not count.

Scroll sideways to see the whole diagram.

Who gets what

A task’s result goes to its direct parent only. Writers and the Reviewer hand theirs to the Editor-in-Chief. The Strategist, the researchers, the Topic Editor and the Editor-in-Chief hand theirs to the Leader.

How it travels

When a child task changes state, a database trigger writes a report event in the same action and delivers it by subscription. Today only the Leader subscribes, while the Editor-in-Chief simply waits for its children and takes their results. If someone new starts to care about a result, adding a subscription is enough. The hand-off logic does not change.

Delivered is not handled

An event is pending, delivered or processed, and an agent saying “handled” changes nothing. Only the process action does. In production the Leader once wrote a handling note, the write failed, and it believed it was finished while the system still showed the event as open. It was reminded the next day.

Business state

When the world moves, the old decision dies.

An article can be edited, and other agents can decide things, in the hours a task spends waiting. So an agent coming back never acts on what it remembers. It looks at what state the business object is in now.

The article’s fixed life cycleAn article moves from queued to drafting to QA to awaiting review to publishing to published. Only a review pass enters awaiting review, only there may the Leader decide publication, and a published article cannot be edited. A notice bound to draft v3 is voided when draft v4 appears.queueddraftingQAawaiting reviewpublishingpublisheda pass from reviewis the only way inthe Leader may decidepublication only herepublished: no more editsNotice: “ready to publish”bound to draft v3Draft v4 appearsthe world moved onThe old notice is voideda decision on v3 is rejectedEvery decision carries the version it saw. If the article moved on while the agent waited, the old decision no longer applies.

Scroll sideways to see the whole diagram.

A fixed life

Writing an article is the core of SEO, and this cycle is a mirror of how a person writes one, so it is written in code. A review pass is the only way into awaiting review. The Leader may decide publication only on an article that is awaiting review. A published article cannot be changed.

Decisions carry a version

Every decision is bound to the version it saw. The “ready to publish” notice the Leader receives names the draft version. If the draft changes in between, the old notice is voided automatically and a publish decision made on the old version is rejected.

No orphans

When a parent task is closed, its children are wound up with it, so no child is left writing with nobody in charge of it.

The point is not that you watch the team. It is that you only judge yes or no.

Replace the agent definitions and the business tools with your own, and keep the layer that makes a team of agents behave like one team for weeks: delegation, handoffs and state.

How it keeps running How it learns Read the source