The admin mental model

In Fundamentals you learned to think of Devin as a teammate: give it a scoped task, review its PR. As an admin, shift the frame. You're not managing a teammate; you're running a fleet. Your job is to provision it, secure it, and meter it so every member of your team gets a working, governed Devin from day one.

The unit you manage is the Organization. An org draws four boundaries at once:

• Shared environment. All members of an org share the same Devin machine setup. One good environment benefits everyone; one broken one taxes everyone.
• Repository isolation. Repos are granted to orgs, not to individuals. Every member of the org can use the repos it holds, and nobody outside it can.
• Member boundaries. A user can belong to multiple orgs, and their permissions are scoped per org. Admin in one org means nothing in another.
• Billing separation. Each org has its own ACU limits and usage tracking, so cost rolls up along the same lines as access.

Above orgs sits the Enterprise, and the access-control flow runs top down: enterprise admins create orgs and grant repository permissions to them, org admins invite members, and members run sessions inside their org's scope. Each layer only hands down what the layer below needs.

So how many orgs, and where do you draw the lines? The mapping that works in practice: one Devin org ≈ one GitHub or GitLab team ≈ one IdP group ≈ one business function. A company might run ecommerce-platform, analytics-platform, payments, and infra as four orgs, each aligned with the matching source-control team and identity group. When those four things line up, provisioning, repo grants, and cost reporting all fall out of the same structure.

When the mapping isn't obvious, decide along four axes: team boundaries (who works together), repo collaboration patterns (which repos are worked on by the same people), cost-allocation needs (which budgets need separate tracking), and security isolation needs (which code must stay compartmentalized). The anti-pattern to avoid is one giant org for the whole company: it erases repository isolation, makes cost attribution impossible, and turns every environment change into an all-hands risk.

Keep this hierarchy in your head; the rest of the course walks through each layer of it. By the end, you'll onboard a brand-new team end to end in the sandbox: create the org, wire up identity, grant repos, configure the environment, add secrets, set governance, and verify it all with a real session.