A newsletter is the easiest real business to hand to a team of employees, because the work is genuinely repeatable, the deadline is external, and the parts split cleanly along the line between judgment and mechanics.
It also punishes the two mistakes everyone makes: hiring six employees on day one, and letting the model do work that should be a script.
Steps
Hire one employee and have it audit the work
Start with a coordinator and nothing else. Connect it to wherever the business already lives, then ask it to look before it builds.
Read the answer critically. You are checking whether it understood the business, and the exercise is worth doing even if you ignore the recommendation.
Do the first issue through the coordinator by hand
Before creating a research employee, have the coordinator do that job once, with you correcting it. You are not being slow; you are working out what the role's instructions should say. Only once it produces an issue you would send do you split the job out.
Do the job once yourself through the coordinator, and only then create the employee that owns it. A role created before the work is understood is a role you will rewrite three times.
Split out research, and give it sources rather than a topic
researcher owns finding things. The difference between a useful research
employee and a useless one is entirely in the source list.
Ask for a numbered list. When you review, you reply "keep 2, 5 and 9" instead of describing each one again, and that difference decides whether you actually do the review each week.
Take the formatting off the model
Here is the step that separates a newsletter you can trust from one you have to proofread line by line. Writing each item into the house format is not judgment, it is transformation, and a model will do it slightly differently every week.
The model picks and writes, which needs taste. The script formats, which needs to be identical every time. You get an issue that looks the same each week without anyone checking that it does.
This is the step operators usually solve by pushing it out to a separate automation tool, because their agent cannot promise consistency. Here it is one node type, in the same workflow, with the model still doing the parts that need a person's judgment.
Add the sales employee, pointed at the inbox
Most sponsor money is lost to a reply that never happened. Put sdr on the
inbox with a watch trigger so nothing waits for you to notice it.
Keep the rate sheet somewhere it can read. A sales employee inventing a price is worse than one that stays quiet.
Ask for five lines, not a report
Once you have more than two employees, each one should file a short brief rather than a full account of its week. Put the shape in the persona so it holds.
The coordinator merges those into one digest. Five lines is not a stylistic preference — a long report from every employee is a report nobody reads.
Set the gate before the first send
Sending the issue, always. Any reply to a sponsor, until you have read a month of drafts. A newsletter sent twice, or sent with last week's items, is the kind of mistake subscribers remember, and the send is one click either way.
Verify
- Run the formatting script on last week's items and confirm it reproduces the issue exactly
- Confirm research skips items that ran in a previous issue
- Send a sponsor enquiry from another address and confirm it drafts rather than sends
- Confirm the daily briefs really are five lines
When it goes wrong
The issue looks slightly different each week
Formatting is still being done by the model. Move it into a command node; that is the whole point of step 4.
Research returns the same items repeatedly
It cannot see what already ran. Give it access to previous issues and make exclusion an explicit instruction.
The team grew to six employees and nothing is faster
Roles were created before the work was understood. Retire the ones with no clear owner and go back to doing the job through the coordinator first.