Where Does Knowledge Live?

#

A Knowledge Architecture for AI Workers

The problem nobody talks about yet

#

You pair-program with an AI assistant for three hours. It finally understands your PST parsing quirks, your test conventions, and why Phase 1 must not touch Postgres yet. You close the laptop. Next morning, it has forgotten everything that lived only in chat.

Or worse: you did write instructions—in a README, a Cursor Rule, a personal note, and a Skill—and now the assistant follows one on Monday and contradicts another on Tuesday.

This is not a model intelligence problem. It is a knowledge architecture problem.

For decades, teams argued about where information should live: comments, wikis, Confluence, ADRs, runbooks, lint configs. AI coding assistants add a new layer—not because the knowledge is new, but because the retrieval model changed. The assistant does not browse your wiki. It receives a composed context window every session: system instructions, project rules, open files, tool outputs, and whatever you explicitly attach.

If you are a solo developer learning tools like Cursor, Claude Code, or Copilot Workspace, you feel this immediately. If you are a Knowledge Manager, Quality Manager, tech lead, or CISO preparing for org-wide adoption, the same confusion appears at enterprise scale—except now it affects compliance, consistency, and audit trails.

This article gives you a practical taxonomy from two angles:

1. The development environment — how solo developers and engineering teams configure AI coding assistants (Cursor, Claude Code, Copilot, etc.)
2. The operations environment — how organizations deploy AI for business efficiency using terms like AI employee, digital worker, agent registry, skills, rules, and tools

Same words. Related ideas. Different containers. Confusion starts when teams treat them as unrelated vocabularies instead of one knowledge architecture seen from two seats.

Who this is for

#

I use Cursor as the teaching example for the dev angle because it exposes these layers explicitly—Rules, Skills, MCP Tools, subagents, hooks. For the operations angle, I use language already appearing in enterprise AI platforms, vendor literature, and workforce governance discussions. The principles transfer even when product vocabulary differs.

Two angles, one architecture

#

The same conceptual stack appears in both worlds:

The insight: when a vendor says “give your AI employee new skills,” they mean the same thing Cursor means by Skills—procedural capability loaded for a matching task—not HR competencies in the human sense. When they say “rules,” they mean non-negotiable constraints, not “rules engine” business logic (though that can overlap).

Organizations that connect these two columns early avoid the most common enterprise failure mode: developers build beautiful agent config in repos while operations deploy duplicate, ungoverned AI workers in SaaS platforms—with no shared taxonomy.

The core insight: layers, not one brain

#

An AI coding assistant is not a colleague with perfect recall. It is a stack of context layers with different lifetimes, scopes, and invocation models:

The debate is not “which layer is best.” It is which layer owns which kind of information.

Think of it the way KM teams already think about content types:

• Policy → always applies → Rules
• Procedure (SOP) → apply when doing a named activity → Skills
• Capability → something the system can execute → Tools
• Delegated task → assign to a specialist → Agents
• Lessons learned → accumulated operational knowledge → Learn / wiki distillates
• Reference / specification → deep narrative → Docs

Once you see the mapping, governance becomes familiar instead of exotic.

Define the primitives

#

1. Rules — “Always true here”

#

What they are: Persistent instructions injected into the assistant’s context—often on every message, or whenever certain files are open.

Cursor example: .cursor/rules/*.mdc files with YAML frontmatter (alwaysApply: true or globs: **/*.py).

Analogues elsewhere:

Good fit for Rules:

• Folder layout and tooling (“use UV, not pip”)
• Coding standards for matching file types
• Scope boundaries (“Phase 1 does classification only; Postgres is Phase 3”)
• Pointers to where other knowledge lives (“record discoveries in .cursor/learn/”)

Poor fit for Rules:

• Long multi-step workflows (“when debugging, do steps 1–12…”)
• Volatile facts discovered last week (“99% of PST bodies are empty”)
• Personal writing preferences (belongs in user-level preferences)

Example (from a real project):

# AutoTradeBooking Project Conventions

## Tooling

- Use **UV** for dependency and virtualenv management.
- Run commands: `uv run <command>`.

## Folder Layout

| Path | Purpose |
| docs/ | Design, plans, notes |
| .cursor/rules/ | Cursor agent rules |
| .cursor/learn/ | Domain learnings and operational notes |

That is textbook Rule material: short, stable, universally relevant in that repository.

Design principle: If removing it would cause the assistant to violate project norms on most tasks, it is a Rule. Keep rules thin. They compete for the same context window as your code, chat history, and tool output.

For Quality Managers: Rules are your standards layer—the equivalent of ISO/clinical SOP “always applicable” clauses, but scoped to how work is performed in this codebase.

For Knowledge Managers: Rules should reference, not duplicate, canonical docs. One fact, one home.

2. Skills — “When you are doing X, follow this procedure”

#

What they are: Markdown playbooks loaded when the user’s task matches the skill’s description. They encode process, often with checklists, gates, and explicit “stop until approved” steps.

Cursor example: SKILL.md files in ~/.cursor/skills/ (personal) or .cursor/skills/ (project-shared).

Analogues:

Good fit for Skills:

• “Brainstorm before building anything creative”
• “Debug systematically before proposing a fix”
• “Create a PR: gather diff, draft summary, run test plan checklist”
• “Summarize uncommitted work, commit with proper message, push”
• Team ceremonies with steps and stop conditions

Poor fit for Skills:

• Static facts about the codebase (use Learn or docs)
• Universal conventions (use Rules)
• One-line preferences

Rules vs Skills — the distinction that matters:

Design principle: Skills are lazy-loaded expertise. They save context and encode how work flows, not what the system is.

For Quality Managers: Skills are where verification gates belong: “do not mark complete until tests pass,” “require human approval before deploy,” “run regression checklist for payment modules.” This is directly analogous to QMS work instructions with mandatory checkpoints.

For Knowledge Managers: Skills are procedural assets. They need owners, version history, and periodic review—same as any SOP library.

3. Tools — “I can perform this action”

#

What they are: Callable capabilities—the assistant’s hands. Shell commands, file read/write, browser automation, MCP servers (database query, live API docs, issue trackers).

Analogues:

Good fit for Tools:

• Query live database schema
• Fetch current library documentation
• Run tests, open pull requests
• Search indexed codebase

Poor fit for Tools:

• “Our API returns 404 when…” (that is Learn/docs)
• “Always run tests before commit” (Rule or Skill)

Common mistake: stuffing procedural knowledge into tool descriptions. Tool schemas should describe what the tool does and its parameters. Workflows belong in Skills.

For Security / compliance: Tools define what the agent can touch. Tool allowlists are the new access-control matrix. If an agent can run shell commands and reach production credentials, your tool policy is your security policy.

4. Agents / subagents — “Delegate this subproblem”

#

What they are: Separate context windows with specialized system prompts—spawned to explore, review, run shell tasks, or perform other focused work without polluting the main conversation.

Cursor example: Built-in subagent types (explore, shell, code-reviewer, docs-researcher) and custom agents in .cursor/agents/.

Analogues:

Good fit for Agents:

• Broad codebase search without flooding main chat
• Parallel independent tasks (explore module A while main thread implements B)
• Read-only exploration vs write-capable main thread
• Code review with a fresh, focused lens

Poor fit for Agents:

• Storing team conventions (Rules)
• Repeatable user-facing workflows the main agent should follow (Skills)

Design principle: Agents trade context isolation for coordination overhead. Use them when the main thread would drown in exploration output.

For Knowledge Managers: Subagents are temporary workers, not knowledge stores. What they learn must be written back to Learn, docs, or Rules—or it evaporates when the subagent session ends.

5. Hooks — “On event E, do F”

#

What they are: Lifecycle automation—session start, before/after tool use, commit events, etc.

Good fit:

• Inject lightweight reminders at session start
• Enforce deterministic checks at known points

Poor fit:

• Replacing Skills or Rules
• Complex semantic decisions (“figure out if this needs a PR”)

Design principle: Hooks are syntactic triggers, not semantic understanding. Use them for reliable nudges, not workflow logic.

6. Learn / domain notes — “We discovered this the hard way”

#

What they are: Curated operational facts from running the system—often in .cursor/learn/ or equivalent.

Example (from a real email-classification project):

## PST File quirks

- ~3.2 GB archive, ~3,333 messages.
- `plain_text_body` is often empty; most classification relies on
  subject + headers + attachments.
- Many attachments use TNEF (`winmail.dat`); filenames often only in
  transport headers.

No linter would tell you that. No README reader needs it on day one. But every classification bug eventually points here.

Good fit for Learn:

• Data source quirks and edge cases
• Integration oddities not visible in code
• “We tried X; it failed because Y” distillates
• Classification strategy rationale after experiments

Poor fit for Learn:

• Step-by-step deploy procedure (Skill or docs)
• Universal coding standard (Rule)

For Knowledge Managers: Learn is your lessons-learned register—short, actionable, linked from Rules (“when working on PST parsing, read .cursor/learn/project-context.md”). Promote stable lessons into docs; demote outdated ones.

For Quality Managers: Learn captures non-conformance insights and root-cause knowledge that prevents repeat defects.

7. Project docs — “Read the spec when building the feature”

#

What they are: Architecture documents, implementation plans, ADRs, API specs—typically in docs/.

Good fit:

• Multi-phase roadmaps (e.g., “v3 unified pipeline with Postgres”)
• Feature design with trade-offs
• Narrative a new engineer (human or AI) needs for big-picture understanding

Poor fit:

• “Use 2-space indent in Python” (Rule)

The tension: Docs are often too long to inject always. The pattern:

1. Rules say where docs live and when they matter
2. Skills say which doc to read for which task
3. Learn holds distilled operational facts extracted from docs and production

For Knowledge Managers: Docs remain the system of record for specifications. Agent config is the routing layer that tells assistants when and how to consume them.

The operations angle: AI employees in production

#

Everything above describes the developer’s workbench—configuring an assistant that helps you write code. But organizations deploying AI for operational efficiency use strikingly similar vocabulary:

• “Hire an AI employee to handle invoice intake.”
• “Add a new skill for contract review.”
• “Update the rules so it never sends external email without approval.”
• “Connect tools to Salesforce and SharePoint.”

These are not metaphors floating free from the dev stack. They are the same architectural layers, deployed as production workers instead of pair-programming partners.

What “AI employee” actually means

#

AI employee (also: digital worker, AI agent, virtual analyst) is an organizational label for a deployed agent with a defined role—not a legal employment status, and not magic autonomy.

In governance terms, distinguish two things most vendors blur together:

A human analyst is one person. An Invoice Processing Agent definition may spawn one instance per invoice at month-end, or a thousand during peak load. You improve the definition once; every future instance inherits the update. That scaling model is why operations teams reach for HR language—and why HR, IT, and KM must collaborate on the registry, not leave it to whichever team bought the SaaS tool.

If you want the executive framing of agent definitions, instances, and registries, see AI Agents as First-Class Citizens on this blog. This post is the knowledge-layer companion to that workforce governance story.

Operations mapping: term by term

#

Rules in operations = guardrails, not business rules engines

#

In production AI, Rules are always-on constraints the worker must not violate:

• Never disclose customer PII in external channels
• Escalate transactions above ₹10 lakh to a human approver
• Use formal tone for regulator-facing drafts; casual tone internal only
• Do not execute payments; only prepare payment files

For Quality Managers: Ops Rules are your non-negotiables—the AI equivalent of “must” clauses in a QMS. They should be short, testable, and auditable. Put multi-step verification in Skills, not Rules.

Skills in operations = workflows and competencies (loaded on demand)

#

Vendor marketing uses skills for everything from “can summarize PDFs” to “runs month-end close.” Architecturally, a Skill is still: when task type X, follow procedure Y.

Examples in operations:

For Knowledge Managers: Ops Skills are SOPs with execution semantics. They need version numbers, owners, and obsolescence dates—exactly like human-facing procedures. The difference is an AI Skill is invoked, not merely read.

Tools in operations = system integrations (the access matrix)

#

An AI employee without tools is an intern without login credentials—full of intent, unable to act.

For Security / CISO: The tool matrix for AI employees is IAM for non-human workers. If you would not give a junior hire full admin on the ERP, do not attach that tool to a production agent.

Knowledge in operations = what the worker is allowed to “know”

#

Operations teams bundle knowledge under many names—knowledge base, RAG corpus, grounding data, playbooks, policies ingested. Architecturally, split it the same way as in dev:

For Knowledge Managers: Your taxonomy work does not disappear—it intensifies. You are now maintaining knowledge for human retrieval and machine retrieval simultaneously. Single source of truth matters more, not less, because the agent will not “ask a colleague” when the wiki is ambiguous.

Agents / AI employees = the worker, not the storage

#

An AI employee is the runtime identity that combines Rules + Skills + Tools + Knowledge for a purpose. It is not where you store procedures—that remains Skills and docs.

Think of the relationship:

Agent Definition (the "role")
├── Rules        → guardrails always active
├── Skills       → procedures invoked by task type
├── Tools        → systems it may touch
├── Knowledge    → corpora it may retrieve
├── Owner        → accountable human
└── KPIs         → accuracy, latency, cost per task, escalation rate

Instances are that definition applied to real work: one invoice, one fund, one support ticket.

An operations example: accounts payable AI employee

#

Compare the same logical layers in dev vs ops:

Same architecture. Different runtime. The KM and Quality teams governing the right column should recognize the left column when engineering ships it.

Who owns what in operations

#

The org chart argument: if you already have roles for policy (Legal), procedure (Quality/KM), and access (IT), AI employees extend those roles—they do not replace them with “the AI team.”

When dev config and ops deployment should meet

#

The healthiest organizations deliberately link the two environments:

1. Skills authored once — A procedure validated in operations becomes a Skill in the repo that engineers use when maintaining the agent code.
2. Learn ↔ incident loop — Production exceptions feed .cursor/learn/ or ops KB; fixes propagate to both.
3. Rules aligned — Compliance guardrails in production match what engineers see when modifying agent behavior.
4. Registry ↔ repo — Agent definition in the enterprise registry points to the Git repo version that implements it.

Without these links, you get shadow AI: operations runs an AI employee built in a no-code platform while engineering maintains a different version in code—and neither team shares vocabulary.

Decision flowchart: one question at a time

#

Use this when adding new information:

Quick heuristics:

Priority and conflicts: who wins?

#

Real systems stack layers with explicit precedence:

1. User’s explicit instruction in chat — highest
2. User-level preferences — personal, cross-project
3. Project rules — repository-specific
4. Skills — procedural overrides for matched tasks
5. Default model behavior — lowest

Anti-pattern: the same instruction copied into Rules, Skills, README, and user preferences. When they drift, the assistant “follows” inconsistently—and users blame the model.

Single source of truth rule: Each fact or procedure has one canonical home. Other layers reference it:

• Rule: “Follow the brainstorming skill before creative work.”
• Skill: “Read docs/atb-v3-plan.md before database schema changes.”
• Learn: “PST bodies are usually empty—see classifier docs for scoring implications.”

For Knowledge Managers: This is classic content governance—avoid duplicate authoritative sources, maintain clear ownership, define promotion path (Learn → docs → training material).

A concrete layering example

#

Consider a project that processes email archives for trade-booking data:

That is a working architecture—not perfection, but intelligible boundaries. A new team member—or a new assistant session—can navigate it.

From solo developer to organization

#

Phase 1: Solo — learn by doing (where you are now)

#

Start minimal:

your-repo/
├── .cursor/
│   ├── rules/
│   │   └── project-conventions.mdc    # thin, always apply
│   └── learn/
│       └── project-context.md         # append as you discover quirks
├── docs/
│   └── feature-plans.md               # specs you actually reference
└── README.md                          # human onboarding only

Habits that compound:

1. When the assistant makes a repeatable mistake, ask: Rule, Learn, or Skill?
2. After a long debugging session, spend five minutes updating Learn—not chat.
3. Before a multi-day feature, write a short plan in docs/; add a Rule line pointing to it.
4. When you formalize a workflow you use weekly, promote it to a Skill.

You do not need a committee. You need one canonical place per fact.

Phase 2: Small team — shared repo config

#

Add:

.cursor/
├── rules/           # reviewed in PR like code
├── skills/          # team SOPs for agent-assisted work
└── learn/           # curated, not a dump

PR checklist additions:

• New instruction not duplicated elsewhere?
• Rule still under ~100 lines?
• Skill has clear description for when it triggers?
• Learn entry dated and sourced?

Phase 3: Organization — governance without killing speed

#

At this stage, most companies have both a dev environment (engineers configuring assistants in repos) and an operations environment (business units deploying AI employees in production). Governance must cover both.

Enterprise patterns that already exist:

You are not inventing governance from scratch. You are extending it to a hybrid workforce—and aligning the dev bench with the operations floor.

Mapping products to the wider market

#

Cursor is useful pedagogically for the dev angle because the layers are visible. Operations platforms (enterprise agent builders, iPaaS orchestrators, vertical SaaS with “AI employees”) expose the same layers under different names:

If your organization’s tool lacks “Skills” today, you can approximate them with named prompt templates and checklists in docs—but you will feel the pain of no lazy loading. That is worth mentioning in tool evaluations.

Failure modes (and what to do)

#

For Quality Managers: Treat “assistant ignored the checklist” as a process failure, not a people failure—in both environments. Was the checklist in a Skill? Was the Skill description matchable? Was verification tool-gated or honor-system? Did operations deploy a different version than engineering tested?

What not to do

#

1. Do not put everything in Rules. Context bloat degrades every task.
2. Do not treat chat as memory. Transcripts are ephemeral; repos are durable.
3. Do not duplicate README content in Rules. README is for humans onboarding; Rules are for agent constraints. Cross-link.
4. Do not skip Learn because “we will fix the code.” Code does not capture why the workaround exists.
5. Do not deploy org-wide Skills without owners. Unowned SOPs rot—human or AI-facing.
6. Do not assume the model " figured it out once." If it mattered, write it down in the right layer.

A starter template you can copy

#

---
description: [One line: what this rule enforces]
alwaysApply: true
---

# [Project] Conventions

## Tooling

- [Package manager, test runner, deploy tool]

## Layout

| Path | Purpose |
| docs/ | Specifications and plans |
| .cursor/rules/ | Always-on agent constraints |
| .cursor/learn/ | Operational discoveries |

## Scope

- [What this project phase includes and excludes]

## Pointers

- Before creative features: use `[skill-name]` skill
- Domain quirks: read `.cursor/learn/project-context.md`
- Architecture: read `docs/[main-plan].md`

Create matching empty files on day one. Grow them deliberately.

Closing: the goal is not more instructions

#

The goal is the right instruction at the right time—whether the worker is a coding assistant at your desk or an AI employee processing invoices overnight.

Solo developers feel this as fewer “why did it forget?” moments. Organizations feel it as auditability, onboarding speed, and consistent quality when dozens of people—and dozens of agent sessions, and dozens of production instances—touch the same knowledge.

AI did not create the need for knowledge architecture. It surfaced it in two places at once: the repo where engineers configure assistants, and the operations floor where business units deploy AI workers. The vocabulary overlaps—Rules, Skills, Tools, Agents, AI employees—and that overlap is a feature, not a coincidence. It is one architecture viewed from two seats.

Rules are policy. Skills are procedures. Tools are capabilities. Agents and AI employees are workers with scoped authority. Learn and knowledge bases are wisdom from operations. Docs are the record.

Get the boundaries right—and align dev with ops—and the system stops being a brilliant amnesiac. It starts behaving like infrastructure your hybrid workforce can actually rely on.

Further reading on dasarpai.com

#

If this topic connects to your broader AI practice, these posts from the same blog series may help:

• Cursor Chat: Architecture, Data Flow & Storage — what actually gets sent each turn
• Agentic AI for Business Leaders — when agents help and when they do not
• AI Agents as First-Class Citizens — governing the digital workforce