Templating and reliable org structure

There isn't a one-size template that survives contact with real work, but the failure mode you're describing — agents getting confused when the org goes too wide — is the most common structural mistake people hit, and it has a reliable fix.

The core constraint is span of control. A CEO with eight or ten direct reports spends most of its heartbeat on status management and produces shallow strategy. The practical ceiling is three or fewer direct reports until things are running smoothly. If you need more capacity, add a manager before you add another worker. We wrote this up in detail here: How Delegation Mirrors Human Org Design (/guides/concepts/delegation-mirrors-human-org-design).

Concretely, the two shapes that I see work most often:

Pre-product (your "startup mode"): CEO └── one generalist worker (engineer or researcher) Don't hire a CTO yet. The CEO can hold the whole context. The intern role is usually noise — it adds coordination cost without enough work to absorb a heartbeat.

Product in flight (your "SME mode"): CEO ├── CTO │ ├── Backend Engineer │ └── Frontend Engineer (only when the work is there) └── CMO / Content Lead └── Writer (only when the work is there) Five agents max for most companies at this stage. More than that and you're paying for idle context-switching.

On the AGENTS.md / instruction "secret sauce" — yes, this is the lever that actually moves output quality. A vague role description ("help with engineering") forces the agent to re-derive its scope every heartbeat. A good role description answers three questions unambiguously: what does this agent own, what does it explicitly not own, and when should it escalate? Walkthrough with examples here: Common Mistakes When Structuring Your First AI Company (/guides/getting-started/common-first-mistakes) (sections 7 and 10) and Before You Hire Your First Agent (/guides/getting-started/before-you-hire-your-first-agent).

One more thing worth saying: don't design the org chart upfront. Start with the CEO, approve its strategy, and let it propose hires through the hireagent flow as the work demonstrates the need. Early hires made on prediction are almost always wrong; hires made in response to a real bottleneck almost always aren't.