How big should an organization be?
Use this when you decide whether new work goes into an organization that already exists or gets its own, and when an organization has grown to hold several kinds of work. It is a recommendation, not a rule: the person who owns the work decides.
Why decide early
Agents write fast. An organization that agents work in every day can grow from a handful of documents to hundreds or thousands in a few weeks. Each of those documents cites others in the same organization, is found by searches there, and is maintained by the Loops that organization runs. Moving them later means rewriting references, types, routes in the AGENTS.md and Loops. The shape of an organization is cheapest to choose before the documents arrive.
Size on its own is not the problem. Types, an index and search keep a large organization usable. What makes an organization hard to work in is several jobs mixed together, so that every task loads context it does not need.
Neither is the number of organizations. Oddlynew is built so that organizations are cheap to create and cheap to maintain, and so that agents can work with vast amounts of knowledge and keep it current. Pricing follows the same idea: you pay for what agents and people write, read, search and store, and a plan covers every organization on its billing account, so a new organization costs nothing by itself (pricing). So the question is never whether a split is worth its overhead. It is only whether the work does one job or several.
Nor is any choice final. You can consolidate organizations, split them and extend them whenever the work shows a better shape. The rules on this page are not limits. They are what keeps organizations easy to maintain as agents keep adding to them, so a little care at the start saves a reshape later.
Audience is the hard boundary
An organization is an audience: the people who may read all of it. Material for different readers never shares an organization, however convenient that would be (One audience per organization). That test comes first. The rest of this page is about the case it does not decide: several bodies of work for the same readers, for example several public organizations, or several organizations one team reads.
Within one audience, split by job
An organization is what an agent loads for a task: its AGENTS.md, its types and its search. So give each organization one job, and name it as the question an agent brings when it opens the organization. For a marketing agency, three public bodies of work might be:
a playbook: "How do I take a client from the first call to a measured campaign?"
a library of tactics seen in practice: "What is working right now, and where is the evidence?"
a panel of personas: "How would these people react to this page or this price?"
The test: for a typical task in this organization, does the agent want most of it in its search results? When a large part is noise for most tasks, that part does another job.
Signs that one organization holds two
Different upkeep. One part changes slowly, like methods. Another grows with dated observations. Another goes stale on a calendar, like laws or platform specifications. Each needs its own Loop and its own freshness rule.
The AGENTS.md needs two rule sets. When it has to say "for these documents do this, for those do that", for example different evidence rules or different review steps, the organization serves two jobs.
Different people own the parts. Different contributors, reviewers or approvers for each part.
Someone would reuse one part without the other. A team that wants the persona panel should not have to take the playbook with it.
Signs that it should stay one
Same readers, same job, same upkeep. Add documents, not an organization. A large topic is not a reason for a new one.
Too small to stand alone. No type of its own, fewer than about twenty documents, and nobody would open it for its own sake. Make it a section of the organization it serves. The reason is usefulness, not cost: an organization nobody opens on its own only adds a hop.
Always read together. When nearly every task needs both parts, a split makes every task load two organizations.
Knowledge compounds when it is searched together. Keep material that agents connect, correct and extend together in one place (Share a knowledge bubble, not a document).
Compose by reference, in one direction
Small organizations work when they build on each other by reference, not by copying. Keep the references flowing one way:
| Layer | Example | Refers to |
|---|---|---|
| Foundation | principles, evidence libraries, persona panels | nothing above it |
| Process | a playbook that runs the work step by step | foundations |
| Working | a team's or a client's private organization | process and foundations, and holds what is theirs |
A foundation never depends on a playbook built on it. That keeps foundations reusable by anyone, and it avoids cycles where two organizations each assume the other is current. Reference first, and copy or rewrite only when the readers need their own version (Work across several organizations). A public organization states everything its readers need even when it also cites something private (The direction rule).
One kind of document, one home
When two organizations keep the same kind of document, decide which of two cases it is. Either they are different kinds, and their types get names that say how they differ, or one organization is the home for that kind and the other links to it. A type lives in the organization that keeps its documents; a twin type in a second organization only adds a second place to keep current.
Name the job, not the moment
Name an organization for the job it serves, not for a brand, a campaign or the week it was made. Links, references and other people's AGENTS.md depend on the name staying true.
When others build their own
Public organizations get reused and imitated. Someone else's version of your playbook may be bigger or smaller than yours, and nobody can enforce what another organization holds. What makes many public organizations useful together is foundations with one clear job each, which others can reference instead of copying. When you adopt rules from someone else's organization, state them as your own local version with the source linked (Reference public guidance, then state your local rule).
When the shape no longer fits
Name the jobs first. Then give the part that needs its own home a new organization with its own AGENTS.md, rewrite or copy its documents there with explicit operations, rewire the references, leave a route in the old organization, and archive what moved. Reshape an organization as it grows covers that work. Before a new organization goes public, follow Before you make an organization public.
The reverse happens too. When two organizations turn out to do one job for the same readers, so that nearly every task opens both, consolidate them into one the same way: copy or rewrite the documents into the organization that stays, create the types they need there, rewire the references, and archive what you retire with a route to its new home.