Eight agents, and the output still isn't good enough

TL;DR: Founders are building agent org charts that run their go-to-market overnight, and they're right to build them. The schedule works; the complaint we hear every week is that the output still isn't good enough. That's a judgment problem, not a model problem, and neither a wiki nor a downloaded methodology fixes it: the chart needs a record of what the company has decided, and it needs to read it every morning.

Founders are building their own teams, and they should

Every week now, someone posts their agent org chart on LinkedIn.

The shape is the same every time. Eight agents, each in its own chat with its own job. One runs the others. One scans the feed overnight so the posts that broke out are sitting in the founder's inbox at 08:00. On Mondays, one turns those into the week's plan. Then an outbound manager, a reply manager, a lead sourcer, and three writers. Behind it, dozens of skills written over the past year and reused. Nothing goes out without the founder saying yes.

The platforms to run this exist today. xAI's Grok Bot gives you always-on agents, schedules and connectors. OpenAI's Dots does the same from inside ChatGPT. Claude Code will run a skill at the hour you set. Lindy sells the whole org chart as a product.

The companies we talk to who build these are two to eight people. A founder doing go-to-market at night. No marketer yet. A product that needs outbound, content and replies every day whether or not anyone has time for them.

They're right to build it. For a company of eight with no marketer, this org chart is the best hire of the quarter. We'd tell you to do it.

What we keep hearing

In our conversations with founders running one of these, the schedule is never the complaint. The agents show up at 08:00. The plan gets made on Monday. The drafts arrive.

The complaint comes in nearly the same words every time: the output is still not good enough.

So they switch models. They rewrite the skill file. They add a reviewer agent that reads the writer's draft before it ships. It gets a little better, and it stays not good enough. And when you ask what good would look like, nobody can say.

The danger, and why motion feels like strategy

Look at what each agent actually does. It runs, it sources, it drafts, it scans, it writes. The top one manages the others. The week's plan comes from what performed for other people last week.

Those are all execution decisions, and the chart is very good at them.

Now look for the decision the chart exists to serve. Which customer is the outbound for, and why that one over the other two you considered? What price is this week's content quietly arguing for? If all of this works, what will be true by November? What number would make you shut it down?

A founder who builds this well also has a wiki, and that objection deserves its full weight. There's a Notion with a customer page, a positioning page, a pricing page, and the agents read it over MCP before they write. The agents aren't in the dark. They know what the company says about itself.

But a wiki holds a description. The pricing page says per seat, eighty dollars. It doesn't say this was decided in July on the strength of four calls. It doesn't say the decision rests on an assumption about team size nobody checked, or that fewer than three of five design partners paying by November would retire it, or that the positioning page it depends on changed two weeks ago and so it's stale now and nobody re-read it. A wiki page is true until someone remembers to edit it. The agent reads the sentence and inherits none of the reasoning, which for the purpose of being wrong is the same as never writing it down.

The second objection is better: the skills are better than procedures now. You can pull a positioning skill off skills.sh that carries a real methodology, the one a good consultant would walk you through.

Run it and you get a competent positioning document. Run it again in six weeks and you get another one, and neither knows the other exists. The methodology tells you how to make the decision. It doesn't keep the decision once made, with what it rested on and what would retire it, and it doesn't read the last decision before writing the next. A methodology is a way of deciding. A strategy is the decision you're currently living with, and it has to live somewhere that can say when it stopped being true.

Here's the trap. A founder with eight agents, a wiki and a Monday plan feels strategic, and the feeling is real. Motion at 08:00 every morning reads like direction.

The gap doesn't announce itself. It shows up two months later as a quarter of good execution against a position nobody tested. The quality complaint is the first symptom. Output quality isn't a model problem, or switching models would have fixed it. It's a judgment problem: the writer doesn't know what the company is betting on this quarter, so it writes for everyone.

The best model, briefed by an outlier post and a wiki page, produces an excellent version of somebody else's strategy.

What a strategy skill is

So we build the other half: a record of a company's strategic decisions, and forty skills that make those decisions the way a senior operator would.

"Skill" has come to mean a markdown file that tells an agent how to do a task. A founder can have a folder of them by Friday, and some of the methodologies on skills.sh are good. Ours are a different object.

Each skill is a written methodology for a single class of decision, and each one reads the record before it writes. The first read, where the company stands, is the clearest case. The server builds the frame from your evidence before the model writes a word, and the model elaborates that frame instead of replacing it. The rules it's held to, the ones a downloaded skill doesn't carry, are written up as a test you can run on your own system in Open your repo and try to find a decision.

Every output is a bet: a position, its assumptions tagged known, assumed or to verify, a threshold that confirms it, a kill criterion that retires it, a date to read the number.

The server owns the structure and the model fills prose. It can't invent a competitor that was never served, state a figure with no source, or quietly restate a committed number. Gates, not guidelines, on every run.

Quality, to us, is a decision that knows its own basis and its own exit.

The governed record

Nothing enters without the founder's commit. The system stages, the founder commits, for the first read and the fortieth and for anything an agent proposes.

A committed decision is never rewritten, only superseded with the cause recorded. When positioning changes, the reads that rested on it are marked stale with the reason.

Every bet carries a threshold in its own unit. When the number arrives, the record scores it and asks for a verdict. It never resolves a bet itself. What is waiting for a verdict sits on the board until the founder gives one.

Seats work the same way. The founding team controls the record. Everyone else, human or agent, reads it and builds from it and can't change it.

How the org chart plugs in

We're not asking anyone to tear the chart down or move the wiki. Every agent in it can start its morning by reading the record over the same MCP connection it already uses for Notion, and a decision that was superseded comes back as a refusal, not a page. What the connection serves is spelled out in Why not just ask Claude?

Agents write back one thing, which is evidence. A reading against a threshold, an outcome for a move they ran. They can't approve, resolve or change terms. The founder rules and the agents report.

So the chart stays. The content lead still plans on Monday, the reply manager still drafts at 08:30, the wiki still describes the company. What changes is what the agents are briefed with. The overnight outliers become inputs to a position instead of substitutes for one, and the writer stops guessing what the company believes.

Build your own team of agents. You should. Then give them something to be for, and something that can tell you when you were wrong.