Context at scale: governing knowledge, playbooks & skills

Cloud 102 taught members to create context: knowledge items, playbooks, skills. Your job as admin is different: stewardship. A team that's good at creating context and bad at curating it ends up with sprawl, and sprawl isn't neutral. Stale items, duplicates, and conflicting conventions actively degrade sessions, because Devin retrieves and trusts them.

Start with tiering. Context tiers the same way blueprints and secrets do, and the highest-tier rule makes its third appearance: put each item at the highest tier where it's universally true. Enterprise-wide conventions (commit-message format, security policy) belong at the enterprise level; a team's service conventions belong at org level; anything specific to one codebase belongs pinned to that repo. An org-level item that's only true for one repo will misfire everywhere else, which is worse than not existing.

Seeding a new org is part of onboarding it. Use knowledge onboarding to generate the initial items rather than starting from a blank library, migrate playbooks that have already proven themselves in other orgs, and encourage repos to carry their own skills and AGENTS.md files so context travels with the code instead of living only in Devin.

Then keep it healthy with an operating cadence:

• Review the library periodically. Folders group items by team or workflow, and bulk enable/disable is your triage tool: switch off a whole doubtful folder, watch what changes, then prune for real.
• Prune stale items. Conventions change; knowledge written for the old CI system misleads sessions on the new one.
• Watch Session Insights. When it flags a knowledge item as misleading, that's a direct signal to review, update, or prune that item. Repeated flags on the same item are never a coincidence.
• Nominate context owners. One person per team who owns their slice of the library beats an admin trying to curate everything alone.

At real scale, stop hand-editing. The knowledge and playbook APIs support full CRUD, so you can sync conventions from an internal source of truth (an engineering handbook, a style-guide repo) into Devin automatically. When the handbook changes, the knowledge changes with it, and the library stops depending on someone remembering to update it.