Phase 9: Team Workflows & AI-Native Process · 45 min · Claude Code · MCP · Python
Knowledge Management for AI-Native Teams
A new hire who is productive with the codebase but useless with the team's AI agent hasn't really onboarded — the agent's context is now part of what 'knowing the codebase' means.
Hiring signal: Treating a team's shared context (rules files, skills, institutional knowledge exposed to agents) as a maintained asset with its own audit and onboarding process shows you understand context engineering as team infrastructure, not a personal productivity trick.
What you will learn
- Explain what shared context (rules files, skills, MCP-exposed knowledge) means as team infrastructure rather than individual habit
- Run a context audit: identify what a new team member needs to be productive with the team's AI agent on day one
- Distinguish institutional knowledge that belongs in a shared, agent-readable artifact from knowledge that should stay in a person's head or a wiki
- Design an onboarding pattern for AI-native teams that includes agent context, not just codebase and process knowledge
Introduction
Knowledge Management for AI-Native Teams
A new hire, three weeks in, is a genuinely strong engineer — reads the codebase fine, ships a correct PR on their first try. But their AI agent keeps proposing changes that violate conventions nobody wrote down anywhere the agent could see: it doesn't know the harness maintainer has to review anything touching approval_gates.json, it doesn't know the team's drift gate treats spec and code changes as one commit, and it doesn't know there's a skills/ directory with three tested prompting patterns for exactly this kind of task. A veteran engineer's agent doesn't make these mistakes, not because the veteran is smarter, but because their agent has access to context the new hire's doesn't. The new hire read the codebase. They didn't read the team's context — because as far as they knew, there wasn't one to read.
Shared context as team infrastructure
A solo developer's rules file, skills, and prompting habits live in their head and their local config, and that's fine — there's only one person to keep in sync. A team has the same problem code has always had: knowledge that lives in one person's head doesn't scale past that person. The team-scale answer is the same one code adopted decades ago — write it down somewhere shared, versioned, and reviewed, not somewhere personal and invisible. For an AI-native team, that means the rules file(s) an agent reads, the skills directory, and any MCP-exposed institutional knowledge are checked into the repo like code, reviewed like code, and treated as broken when they go stale, the same way a broken build is treated as broken.
A personal prompting trick that never gets shared isn't a productivity win, it's a bus factor
If one engineer has privately figured out the exact phrasing that gets the team's agent to correctly apply the harness conventions, and that phrasing lives only in their own head or scratch notes, the team hasn't actually solved the problem — it's solved for one person. The fix (a shared skill, a rules-file addition) costs almost nothing compared to every other engineer rediscovering the same trick independently, or worse, never discovering it and shipping worse output than they could have.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers The context audit: what does a new hire actually need?, What belongs in shared context, and what doesn't, Onboarding as a two-track process, Build It — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy