Skip to main content
A useful context repository gives every important entity or topic one clear home. Its structure should reflect how your company works and make it easy for people and agents to find, update, and connect related knowledge. There is no single required folder tree. Start with a small structure that matches your organization, then add detail when real content needs it.

​
Choose a starting structure

One common approach follows business functions:
company
engineering
growth
operations
product
This works well when most knowledge has a clear departmental home. Another approach separates company-wide knowledge, ongoing team responsibilities, time-bound projects, and instructions for agents:
agents
skills
company
teams
sales
engineering
projects
  • agents contains reusable instructions and supporting resources for agents.
  • company contains knowledge that applies across the organization, such as strategy and policies.
  • teams contains ongoing responsibilities, processes, and relationships owned by a team.
  • projects contains initiatives with a defined outcome and lifecycle.
Treat these as starting points. You can combine them or use a different taxonomy that gives your information clear, stable homes.

​
Example: sales and customer knowledge

A sales area can separate current customers, prospective customers, and shared sales operations:
teams
sales
customers
acme
overview.md
meetings
2026-09-04-quarterly-review.md
support
sso-login-failure.md
contacts
jane-smith.md
pipeline
northstar
overview.md
meetings
support
contacts
rev-ops
deal-stages.md
qualification-criteria.md
sales-handoff.md
Create meetings, support, and contacts when substantive content exists; empty folders and placeholder files add noise. Keep a company in one account location, and define which source controls whether it belongs in pipeline or customers. When its status changes, move its existing folder rather than creating a second record. Here is a shortened fictional customers/acme/overview.md:
The overview answers the most common questions quickly. Detailed meeting notes, investigations, and contact records remain in their own files and are linked where they support the summary. Use the matching sales structure-file template to tell Qontext how to maintain this layout.

​
Example: projects

Give each cross-team project one primary home, then link to it from participating teams.
projects
customer-portal
overview.md
decisions
2026-09-02-authentication.md
meetings
2026-09-04-kickoff.md
Keep the project goal, owner, status, milestones, risks, and next steps in overview.md. Store detailed decisions and meeting records separately so the overview remains useful as the project grows.

​
Example: agent skills

Keep each independently reusable skill in its own folder:
agents
skills
prepare-customer-meeting
SKILL.md
references
briefing-format.md
SKILL.md contains the core instructions. Supporting references, scripts, or assets live beside it and are loaded only when needed. See Skills distribution for the complete pattern.

​
Practical principles

  • Give each entity or topic one primary record and update it instead of creating duplicates.
  • Combine relevant information across sources into useful summaries.
  • Link to detailed records and evidence instead of copying the same content into several places.
  • Distinguish confirmed facts, conflicting evidence, and open questions.
  • Use consistent names and preserve required names such as SKILL.md.
  • Review the repository for duplicates, outdated summaries, unsupported claims, and broken or missing links.
Use structure files to record these choices as guidance for each folder.