Organization structure
The structure you choose is not cosmetic. In Skynet it decides what gets remembered, what stays separate, and how precisely you can scope permissions later. Model the organization before you invite anyone.
Three layers of memory
Collective memory is built in three layers, and your structure decides where each piece of knowledge lands.
Individual
What one person has taught the workspace through their own work. Private to them, and the layer everything else builds on.
Team
Shared context for a group working the same problem. Individual knowledge rolls up here, so the second person to ask a question does not re-explain the project.
Company brain
Organization-wide knowledge. What the business is, how it operates, and the standards that apply everywhere regardless of department.
Knowledge rolls upward. Individual work informs team memory, and team memory informs the company brain. It does not roll sideways by default: one team’s context does not leak into another’s.
Departments, teams, and projects
The three structural units serve different purposes, and implementers routinely collapse them into one.
Departments are the coarse division: Finance, Design, Sales, Engineering. Enterprise supports department-level admin roles and department-level cost allocation, so this layer is where you delegate administration and account for spend.
Teams are the working groups inside a department. Every team shares collective memory, connectors, and context, so nothing has to be explained twice. Create teams by project or department depending on how the client actually works. See invite your team.
Projects are the finest unit, and the one that does the most work. A project groups memory, skills, and agents around a specific workstream. Every project is its own scope, which is what keeps a Finance project from bleeding into a Design project unless someone explicitly shares it.
Mapping a client org
Work from the client’s real org chart rather than an idealized one. Three patterns cover most engagements.
Mirror the org chart. Departments become departments, reporting lines become teams. Best for organizations with stable structure and clear cost centres, and the easiest to explain to a compliance reviewer.
Mirror the work. Teams follow workstreams rather than reporting lines. Best for organizations that run cross-functional squads, where a strict org-chart mirror would split people who share context daily.
Start narrow and grow. One department, fully modelled, before anything else exists. Best when the client is unsure of the shape, or when you need a reference deployment before wider rollout.
Where implementations go wrong
Everything in one project. The fastest way to start, and the hardest to unpick. Memory that should have been scoped is now shared, and permissions cannot be tightened without taking context away from people who already rely on it.
A project per person. Isolation without any of the compounding benefit. Collective memory only pays off when people working the same problem share a scope.
Structure invented by the implementer. If the model does not match how the client describes their own business, adoption suffers and administration falls back to you rather than to the client.
Next: roles and permissions.