How to Use Devin Knowledge to Onboard the Agent

Cognition's official Knowledge guide defines three repo-pinning modes for every note: no repo, a specific repo, or all repos. That single control decides whether a tip fires only when Devin judges the context relevant, always when the agent works in one repository, or on every repo the agent touches. DataForSEO's US keyword data for "devin knowledge" is only about 20 monthly searches, which is a reminder that most teams still treat Knowledge as a buried settings tab instead of the primary onboarding system for Devin AI.

Devin Knowledge is a shared library of tips, procedures, and constraints that Devin automatically retrieves during sessions when trigger conditions match. Official docs compare it to onboarding a new engineer: you invest in knowledge transfer once, then the agent recalls the right notes as work unfolds. You do not paste the same deployment checklist into every prompt. You store it once with a clear trigger, enable it, and let retrieval do the rest.

Use Knowledge for materials Devin would otherwise miss in the git tree: custom internal libraries, non-obvious conformance rules, "never do this" constraints, and operational steps that live in people's heads. Cognition's product language is plain: share documentation, tips, and other materials the agent may need, and keep adding to the bank over time.

Knowledge vs DeepWiki (do not mix these up)

Many write-ups collapse Knowledge and DeepWiki into one "Devin docs" blob. They are different products with different authorship models. Cognition documents both separately: Knowledge for curated notes, and DeepWiki for generated repo wikis.

• Knowledge is user-authored (or user-approved from suggestions). You write the trigger and content. You pin repos. You enable or disable items. You can promote organization items to enterprise scope when that permission exists.
• DeepWiki is generated repository documentation. After indexing, Devin produces architecture diagrams, source-linked summaries, and wiki pages. Ask Devin uses that map for grounded answers. Public repos also appear on deepwiki.com for basic docs and Q&A.

DeepWiki answers "how is this codebase structured?" Knowledge answers "how does our team expect you to behave in this codebase?" A well-indexed wiki will not tell Devin that staging deploys require a freeze window, or that the payments service must never import from legacy/billing. Those rules belong in Knowledge.

How retrieval actually behaves

Devin does not dump every knowledge item into the session at the start. Official guidance is explicit: the agent retrieves Knowledge when it is relevant to current work, not all at once. That is why trigger quality matters more than word count. A vague trigger like "coding" competes with everything. A tight trigger like "when writing database migrations that touch foreign keys" fires when it should.

Devin can also pull multiple Knowledge items in one session. Split topics into focused notes instead of one giant "everything about backend" page. The docs recommend specific Knowledge targeted at one workflow or action, kept short enough that every sentence stays relevant when the full item is read.

Featured snippet path for creating Devin Knowledge (from the official Knowledge product guide):

1. Open Settings & Library, then the Knowledge tab.
2. Click Create knowledge.
3. Write a Trigger Description (required). Use a phrase or sentence that matches when Devin should recall this note.
4. Write Content: a handful of sentences with the procedure, constraint, or tip.
5. Optionally assign a macro (!identifier) so humans can force-include the note in a prompt.
6. Choose repo pinning: no repo, one repo, or all repos.
7. Leave the item enabled (or disable it later per user without deleting it).

That sequence is the whole create flow from Cognition's Knowledge guide. Everything else is craft: better triggers, tighter content, cleaner macros, and sensible scope.

Write triggers that match real work, not marketing slogans

The trigger is a retrieval key, not a title for humans. Devin matches current work to the trigger text. Good triggers name the action and the surface area:

• "When scaffolding a new NestJS module under apps/api"
• "When fixing flaky Playwright tests that touch auth cookies"
• "When deploying the payments service to staging"
• "When adding GraphQL resolvers that return monetary amounts"

Weak triggers sound like wiki categories:

• "Backend"
• "Best practices"
• "Important"

If you find yourself repeating the same paragraph in prompts and playbooks, that paragraph is a Knowledge candidate. Official examples of what belongs include common bugs and fixes, code conformance practices, deployment workflows, testing workflows, and how to use proprietary tools.

Content shape that survives full-item reads

Because Devin reads the entire Knowledge item when it retrieves it, long essays backfire. Prefer a short procedure:

Trigger: When opening a PR that touches packages/billing

Content:
- Run pnpm --filter @acme/billing test before requesting review.
- Never import from packages/legacy-billing; use packages/billing-client.
- Amounts are integer cents. Do not introduce floating-point money fields.
- Tag the PR with billing-risk if migrations are included.

Keep constraints concrete. Name packages, commands, and failure modes. Update the note when the rule changes. Stale Knowledge is worse than missing Knowledge because the agent will treat it as current policy.

Enable, disable, and stop deleting as a workflow

Each item can be enabled or disabled per user. Disabling blocks retrieval in your sessions without removing the note from the organization. That matters when a knowledge item is temporarily wrong for your branch of work but still useful to teammates, or when you are debugging whether a bad note is polluting session behavior.

Folders help at scale. Cognition documents nested folders, bulk enable/disable for a whole folder, drag-or-move reorganizations, and auto-organize for sorting selected items into logical groups. When your org accumulates notes across teams, folders stop Knowledge from becoming an unsearchable wall of text.

Keep Devin onboarding notes where the team can find them

Store approved runbooks, Knowledge exports, and session handoffs in a shared Fast.io workspace with Intelligence Mode search, per-file version history, and MCP access for agents. Every org starts with a 14-day free trial.

Start 14-Day Trial

Automatic retrieval is the default path.

Devin knowledge macros are the override path when you want a specific note in the prompt without hoping the trigger fires.

How Devin knowledge macros work

You can assign a macro to any knowledge item: a short identifier that starts with !, such as !deploy-checklist. Official rules:

• Macros start with !
• Allowed characters are letters, numbers, and hyphens
• Macros must be unique within the organization

In a session prompt, type the macro name to reference that knowledge quickly. Macros are ideal for checklists and high-risk procedures you do not want left to fuzzy retrieval: deploy freezes, incident hotfixes, data migrations, security review gates.

Example prompt fragment:

!db-migration
Migrate invoices.amount from decimal to integer cents on the payments service.
Open a PR with migration + dual-read notes. Do not deploy.

Pair macros with playbooks when the procedure is long. Advanced Capabilities docs show teams improving playbooks (for example !db-migration) from session outcomes, then keeping the short Knowledge note as the always-on guardrail while the playbook holds the full procedure.

Knowledge suggestions from real sessions

Devin can suggest Knowledge from feedback in chat. You can edit the suggestion before saving, dismiss it, or ask Devin to regenerate the suggestion from your notes. Suggestions are not limited to brand-new items; Devin can also propose updates to existing knowledge.

Treat suggestions as draft PRs against your institutional memory:

1. Read the proposed content for accuracy and scope.
2. Tighten the trigger so it will not fire on unrelated work.
3. Decide pin mode (no / one / all repos).
4. Add a macro only if humans will type it often.
5. Save, then run a small real task to confirm retrieval behavior.

Advanced Capabilities also describe managing knowledge in bulk from a session: find and merge duplicates, resolve conflicting guidance, and create new knowledge from codebase patterns. A practical maintenance prompt looks like:

Review all knowledge entries and identify duplicates or highly
similar entries. For each set of duplicates, propose a
consolidated version with a single trigger and clear pin scope.

For large bases, Cognition's order of operations is: deduplicate first, resolve conflicts second, fill gaps third. Noise reduction before expansion keeps retrieval quality from collapsing as the library grows.

Scheduled sessions can keep that maintenance regular (for example a weekly pass over pending suggestions). That is optional automation around Knowledge, not a substitute for human approval of company rules.

Scope is where Devin Knowledge stops being a personal notepad and becomes org infrastructure.

Pinning knowledge to repos

Official pinning options:

• No repo: Retrieved only when Devin decides the note is relevant to the current context. Best for cross-cutting tips that should not force themselves into every session.
• A specific repo: Always used when Devin works in that repository. Best for service-local rules (test commands, package boundaries, deploy targets).
• All repos: Applies to every repository Devin works on in any session. Best for company-wide constraints that must not be optional.

A useful default policy:

• Pin all repos for security and compliance-style rules that are short and non-negotiable.
• Pin one repo for local tooling and service conventions.
• Pin no repo for situational advice that should appear only when the work clearly matches the trigger.

Overusing "all repos" creates constant noise. Underusing specific-repo pins means Devin rediscovers the same conventions by trial and error.

Organization knowledge vs enterprise knowledge

For enterprise customers, the Knowledge page splits into scopes:

• Organization Knowledge: Default scope. Visible to members of the current organization.
• Suggestions: AI-generated suggestions from session interactions (shown for non-primary organizations).
• Enterprise Knowledge: Applies across all organizations in the enterprise. Enterprise admins manage items that should be uniform company-wide.

Primary organization users may see a single Enterprise Knowledge tab. Non-primary organization users with an enterprise account can see Organization Knowledge, Suggestions, and Enterprise Knowledge. Without an enterprise account, the surface is Organization Knowledge plus Suggestions.

Enterprise notes are the right home for coding standards, architectural guidelines, and deployment procedures that should not drift between business units.

Promote organization knowledge to enterprise

When an organization-level item proves valuable beyond one team, open it and use Promote to Enterprise in the Details tab. The item moves from organization scope to enterprise scope and becomes available to all organizations in the enterprise. Promotion needs enterprise knowledge management permissions and applies to user-created knowledge items in organizations that belong to an enterprise.

Promotion is a governance move. Review triggers and pin modes before you promote. A note that was "always on" for one monorepo may need retuning before it becomes company-wide.

If you are starting from zero, do not invent fifty notes on day one. Ship a small pack that covers the first week of agent work on your primary repositories.

Starter set (create these first)

1. Repo map and "do not touch" zones
   Trigger: when starting work in the main application monorepo.
   Content: which packages own auth, billing, and admin UI; which folders are generated; which services are freeze-locked this quarter.

2. Local verification commands
   Trigger: before opening a pull request.
   Content: exact test and lint commands per package, not "run the tests."

3. PR conventions
   Trigger: when drafting PR titles or descriptions.
   Content: required labels, size expectations, and where risk notes go.

4. Environment and secrets boundaries
   Trigger: when configuring env vars or local sandboxes.
   Content: which secrets never belong in the repo, which fixtures are safe, which staging endpoints are allowed.

5. Incident hotfix path
   Macro: !hotfix.
   Content: branch naming, required reviewers, rollback owner, and "no drive-by refactors" rule.

Pin the repo map, verification commands, PR conventions, and environment notes to the primary repo. Consider all-repos only for the secrets boundary note if that rule is company-wide. Keep the incident hotfix path as a macro-first note so humans invoke it deliberately during incidents.

What should not go in Knowledge

• Full architecture encyclopedias (that is DeepWiki plus human ADRs)
• Long narrative postmortems with no actionable steps
• Temporary ticket context that will be wrong next week
• Secrets, tokens, or production credentials of any kind

If a fact is already true from reading the repo and DeepWiki indexes it well, prefer DeepWiki. If a fact is a preference or constraint humans enforce in review, put it in Knowledge.

Where durable artifacts should live outside Devin AI

Devin Knowledge lives inside Cognition's product. Session logs, playbooks, exported checklists, PR drafts, screenshots, and handoff notes often need a home the whole team can open without being in a Devin session.

Teams commonly park that material in git (good for code-adjacent docs), object storage such as S3 (good for bulk artifacts), or Google Drive / Dropbox / Box (good for mixed human documents). Those work. They also fragment agent and human access: the agent wrote the file in a session, the human needs version history, search, and a clean handoff path.

Fast.io fits as the shared workspace layer around Devin AI, not as a built-in Devin feature. Put runbooks, approved Knowledge exports, PR bundles, and review packs in an org-owned workspace. Enable Intelligence Mode when you want semantic search over those files. Agents can use Fast.io's consolidated MCP tools over Streamable HTTP at /mcp (and legacy SSE at /sse) while humans use the UI. Per-file version history keeps concurrent edits auditable. When an agent stages the workspace, ownership transfer hands the org to a human without orphaning the work. Plans start with a 14-day free trial (credit card required): Starter $29/mo, Business $99/mo, Growth $299/mo. For agent MCP setup, start at the storage for agents guide; for plan details, see pricing.

Use DeepWiki for generated structure, Devin Knowledge for team rules, and a durable workspace for the files you still need after the session tab closes. For team-facing AI workspace patterns more broadly, see the AI product overview.

When Devin ignores a rule you "already wrote down," the failure is usually retrieval design, not model mood.

Devin keeps missing the note

Trigger is too broad or too cute. Rewrite with the exact workflow language people use in tickets.

• Pin mode is wrong. A no-repo note may never win against stronger context. Pin to the repo if the rule is mandatory there.
• Item is disabled for your user. Check enable state before rewriting content.
• Content is buried in a mega-note. Split into smaller items so each trigger maps to one action.
• Macro not used. For high-risk paths, type !macro instead of relying on automatic recall.

Devin follows the wrong or outdated rule

• Search for duplicates and conflicting guidance. Advanced Capabilities explicitly supports dedupe and conflict resolution as a knowledge-management job.
• Prefer one promoted enterprise standard over five slightly different org notes.
• Disable the bad note before deleting, so you can A/B which version was steering sessions.
• Update content the same day the engineering practice changes. Knowledge is not a quarterly wiki project.

Suggestions create noise

• Dismiss aggressively. Not every chat correction deserves permanent memory.
• Regenerate with sharper feedback when the draft is almost right.
• Require a human owner for enterprise promotions. Suggestion volume is not the same as policy quality.

Knowledge vs DeepWiki confusion inside the team

If engineers keep pasting architecture dumps into Knowledge, route them to DeepWiki indexing and, for large monorepos, .devin/wiki.json steering. If they keep hoping DeepWiki will invent deploy freezes and review policies, route them back to Knowledge with explicit triggers and pins.

A weekly hygiene loop that stays small

1. Review pending suggestions.
2. Merge obvious duplicates.
3. Disable notes that caused a bad session.
4. Promote only notes that survived real use in at least a few sessions.
5. Export or copy critical procedures into the team's durable workspace so onboarding is not trapped in one vendor tab.

Devin AI gets faster when the library is small, specific, and scoped. The goal is not maximal documentation. The goal is reliable recall of the constraints your humans already enforce in code review.