Managing AI Agents Like a Team: Job Descriptions, Ledgers, and Reviews

Most advice about AI agents is about prompts, models, and tools. After running a team of agents on Endertech's own marketing since September, I think the harder part is something older: management.

The thread that said it out loud

In early November, Marty Kausas posted a widely shared thread about working with AI agents. His fourth point stuck with me:

"ICs need to become great at management. Managing a fleet of agents is more similar to managing people than it is delegating tasks to Claude. Everyone needs manager training."

Screenshot from x.com/marty_kausas

I replied with what I had been seeing in our own system: "Funny but true about agents need management... takes time to refine their performance, trial and error, monitoring, KPIs... been working on self improvement system."

Screenshot from x.com/ThinkerGabe

So how do you manage agents? The same way you manage people. You give them written expectations, a record of decisions, goals with numbers and dates, and a regular review. A new hire who gets a vague task and no feedback will drift. An agent drifts faster, because it rarely stops to ask.

We use two documents for this. The Operating Manual is the job description. The Growth Decision Ledger is the decision record and the team's memory. The rest of this post covers what goes in each one, what went wrong once they were running, and a starter kit you can copy.

The job description: an Operating Manual

The Operating Manual was the first thing I created, before any agent did real work. It is a plain strategy document and rulebook. It says what the system is for, who owns what, and what each agent may and may not do. Its core rule is one line: "Strategy is centralized; execution is distributed."

Excerpt from the Endertech AI-CMO Operating Manual

That line does a lot of work. One coordinating agent owns objectives, priorities, and reviews. Specialist agents collect evidence and carry out approved work. Humans keep authority over anything consequential. Grok Bot runs the coordinator and the specialists, and I sit above all of them as the person who approves.

Standing authority

A good job description tells a new hire what they can handle on their own. Ours calls this standing authority. Routine, reversible work runs without asking and gets reported afterward. Examples include adding negative keywords, small bid tweaks, trimming SEO titles, and publishing blog posts that pass review.

Anything that changes budget, strategy, targeting, or positioning needs my recorded approval, and so does anything destructive. When an agent isn't sure whether a low-risk task is covered, it fails closed and asks. As I put it in a Reddit thread, "The important thing is gates / human approval where decisions need to be made, and keeping track of what agents are doing and why."

Complete but paused

Paid campaigns show how to split the work well. Agents build a campaign completely, with ads, keywords, and settings, and leave it paused. The only step that needs a human is turning it on. That way I review a finished campaign, and the decision in front of me is a simple yes or no.

One source of truth per fact

The manual also says where each fact lives. The CRM is the authority for leads. Git is the authority for code. Google Drive is the neutral place where agents leave evidence and pick up work. When two agents disagree, the manual tells them which record wins.

The decision record: a Ledger

A job description says what to do. It doesn't remember what happened. For that we use the Growth Decision Ledger, a Google Sheet that agents write into and read from before they act. Its tabs include Decisions, Experiments, Commercial Outcomes, Observations, a Task Registry, Evidence Processing, Learnings, and a weekly scorecard.

Excerpt from the Endertech Growth Decision Ledger

A few rules make it useful:

• Every decision gets an ID, the evidence behind it, a rationale, an owner, a review date, and acceptance criteria.

• Every recommendation ends in one of five words: Continue, Change, Test, Stop, or Escalate.

• Approval and execution are separate fields. A decision can be approved and still not done.

• "Verified" requires a read-back from a source other than the agent that did the work. A green status, a merged pull request, or a screenshot doesn't count.

• Failed attempts stay marked Failed. The fix becomes a child decision that points back to the original. It keeps the original approval only if the scope and risk stay the same.

• Every experiment has a hypothesis, one primary KPI, a baseline, and a stop rule written before it starts.

The point of all this is learning. On each review date, a decision is graded against what happened. The lesson goes into the record, and new experiments have to cite what earlier ones taught us. That is what turns a log into a memory.

Because the Ledger lives in Drive, it isn't locked inside one tool. Any model or agent with a Drive connector can read it. "Having the docs on Drive makes them operable by different agents, so they can audit each other," as I wrote in another thread. When I doubt one agent's reasoning, I can ask a different model to review the same record.

Management lessons from running it

Once the Manual and Ledger were in place, the problems changed. Fewer of them were "the model got it wrong." More of them looked like problems I have seen with human teams. Here are six.

1. Agents follow the process you write, including its blind spots

Our routines were very specific about process: what to execute, how to format IDs, which approvals to ask for. They said little about what success looked like. Without a numeric goal, an agent can't tell you whether it's on track or off track. So it reports everything and leaves the sorting to you. A new hire with no targets does the same thing.

2. Every correction became a new required section

Each time I said "always show me this," the request was added to the report as a required section. Nothing was ever removed. The instruction to lead with results and keep it short was still there, but the list of required sections always won. The fix is simple to say: when you add a rule, decide what it replaces, and move detail into a drill-down the reader can open if they want it.

3. Status chatter isn't management information

Early-morning messages like "this page is live" or "closing this decision" were reaching me directly. Each one was accurate, and none of them needed me. Confirmations like that belong in the Ledger. What should reach the owner is conclusions and decisions.

4. The best conclusion can get lost between agents

In one handoff, a specialist's notes included a strong strategic recommendation. The coordinating agent kept the data but dropped the recommendation from the report I read. The facts were fine. The "so what" fell through the gap between two agents. A handoff needs a "so what / do this" field that the next agent has to carry forward.

5. Preserving failure is how it learns

Keeping failed attempts visible felt awkward at first. It is also the only way the system can avoid repeating them. We covered examples in Building a Marketing System That Improves Itself, so I won't repeat them here. The management point is that a team that hides its failures can't learn from them, and agents are no exception.

6. Specialize when the job is too broad, but fix goals first

Our coordinating agent has taken on a lot of work over time, and we're asking whether to split it across more specialists. Our own analysis pointed to something less exciting first. Splitting an agent that has no goals would likely give me two long reports instead of one. So the question we're working through is goals and report format first, then structure.

Practical application: a starter kit for managing your first agents

If you're setting up your first agents, here is the checklist I'd use today. It follows the same order I'd use to onboard a new hire.

1. Write the Operating Manual before the agent does real work. Cover the purpose, the owners, what the agent may do alone, what needs approval, and what it must never do.

2. Create the Ledger. At minimum, track Decision ID, date, decision, evidence, rationale, owner, review date, approval status, approved by and when, acceptance criteria, execution status, verification evidence, and a parent ID with an attempt number.

3. Set two or three numeric goals with dates before the first report. Give each one a baseline, a target, a by-date, and a current status.

4. Write a report contract. Each report opens with a verdict, then goals against target, one conclusion, no more than three actions tied to goals, a one-line hygiene summary, and a link to the detail. Set a hard length limit.

5. Keep approval, execution, and verification separate. Verify with a read-back from a source the executor doesn't control.

6. Review on the calendar. Daily for fast channels, weekly for decisions, and monthly for where effort and budget go. Grade past decisions on their review dates.

7. Treat feedback as policy edits. Every new rule names what it replaces, or where it goes in the drill-down.

8. Keep everything in a shared place with good connectors, like Google Drive, so a second model can audit the first.

9. Start small. One coordinator, one specialist, and one scheduled report. Read it every day and steer from there.

Steps 3 and 4 are the ones we came to late. They're also the easiest to do on day one, before any report exists to grow.

Inputs matter

One more line from my reply to that thread: "And as always, the quality of the creative going in influences the quality of the creative coming out." Agents amplify the brief they're given. A clear manual, clean evidence, and a specific goal will do more for the output than a clever prompt on top of a vague request. The same is true of people.

We're still early

We're still early, and still learning. The model has mattered less than I expected, and the management layer has mattered more. Writing a job description, keeping a decision record, setting goals, and reviewing on a schedule aren't new ideas. Good managers already do them. Agents just make the cost of skipping them show up faster.

If you're building something similar, or you have agents running and the reports keep getting longer, we'd be glad to compare notes. Discuss Your AI Use Case with us, or ask us to Review Your Current Marketing System.