Implementing Skynet in an organization
This section is for the people who install Skynet rather than the people who use it: implementation partners standing up a workspace for a client, and internal IT or operations leads running an organization-wide rollout.
The end-user documentation explains what each feature does. This section explains the decisions you have to make before a single employee logs in, and the order to make them in.
The five decisions
Almost every rollout problem traces back to one of five choices being made late, or made by default. Settle them during scoping, not during onboarding.
-
Organization structure
Map departments, teams, and projects onto the workspace before anyone logs in. This decision drives what memory is shared, and with whom.
-
Roles and permissions
Who can administer, author, and read. Permissions scope down to individual projects, skills, connectors, and memory layers.
-
Model policy
Decide which models employees can reach, which are pinned by department, and where frontier spend is capped.
-
Data posture
Residency, retention, encryption, and the compliance evidence procurement will ask for before signing.
-
Skills program
How custom automations get authored, reviewed, published to the workspace, and maintained once the engagement ends.
A rollout in five phases
Scope the deployment
Confirm the plan and the deployment target first, because they constrain everything downstream. Only Enterprise can run on the client’s own cloud or data centre, and only Enterprise gets department-level admin roles and custom routing policies. See choosing a plan and Enterprise: on your infrastructure.
Get the compliance requirements on paper at this stage. If the client needs data to stay in a specific jurisdiction, that is a deployment decision, not a setting you can toggle later.
Model the organization
Translate the client’s real structure into departments, teams, and projects. This is the highest-leverage hour of the whole engagement: it determines which context is shared, which stays separate, and how cleanly you can scope permissions afterwards.
Full guidance in organization structure.
Set access and model policy
With the structure in place, assign roles, connect identity, and decide the model policy. Both are far easier to define against a structure that already exists than to retrofit onto a flat workspace.
See roles and permissions and model policy.
Seed the workspace
An empty workspace demonstrates nothing. Before wider onboarding, load the connectors the client actually uses, import history where it exists, and publish a first set of skills against real workflows.
See connectors and integrations, import from another agent, and authoring and publishing skills.
Onboard in waves
Roll out one department at a time rather than organization-wide on day one. A first department gives you a reference deployment, a set of proven skills, and internal advocates before the rollout is load-bearing.