> For the complete documentation index, see [llms.txt](https://docs.getlynk.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getlynk.ai/concepts/domain.md). # Domain A domain is an agent. Each domain is one team's analytical agent — marketing's agent, sales' agent, finance's agent — with its own vocabulary, its own data of interest, and its own way of reasoning. ## What it is When a user picks a domain, they are picking which agent answers their question. A user always talks to one agent at a time. Designing a domain *is* designing an agent — every choice about what entities to include, what to call them, what skills to write, and what policies to set is a choice about how that team's agent thinks and answers. The triple **domain + branch + build** addresses one queryable agent. See [Project](/concepts/project.md) for how builds and branches scope a query. **Isolation is the definition, not a constraint.** Each domain's agent sees only its own world — sales' agent doesn't know marketing's definitions unless sales pulled them in. When a question can't be answered in the active agent's world, the moves are: ask a different agent, expand this agent's world, or promote shared content to a domain multiple agents can pull from (typically `core`). Cross-domain reasoning is never a runtime mode — it's a modeling decision. Whether a domain may *reference* another is governed by the project [topology](/concepts/lynk-yml.md#topology), declared once in `lynk.yml` — under medallion a domain reaches its own files, the root reference files, and the configured shared domain; peers never reach each other. Create a new domain when a new *audience* arrives whose vocabulary or definitions would be hurt by another team's bleeding in — not per entity. When and how to split, size, and share is [Designing domains](/guides/designing-domains.md). ## Where it lives One folder per domain under `domains/`. The folder name is the domain's name — the domain is derived from the path, with no `domain:` field anywhere. ``` .lynk/domains// ├── LYNK.md ├── GLOSSARY.yml ├── entities/ ├── skills/ └── policies/ ``` Folder names are lowercase alphanumeric with underscores (`marketing`, `core`, `customer_success`) — a domain name can appear in a cross-domain reference (`core.customer` in an [`identity:`/`imports:`](/concepts/entity/schema-yml/identity-and-imports.md)). `core` is the conventional shared domain under medallion but is not a reserved name. See [Layout and naming](/reference/layout-and-naming.md). ## Format A domain is a container, so its format is the folder contract — everything its agent needs to answer questions in its team's language: * [Entities](/concepts/entity.md) the team thinks about — some native to this domain, some pulled in from elsewhere. * [Skills](/concepts/skill.md) for the team's recurring analytical reasoning. * [Policies](/concepts/policy.md) for how the team wants the agent to communicate. * The team's [`GLOSSARY.yml`](/concepts/domain/glossary.md) and [`LYNK.md`](/concepts/domain/lynk-md.md). What goes in is the team's choice. Marketing's agent might pull in `deals` (a sales concept) because attribution requires it; sales' agent might not. The structure provides the primitives; each team composes their agent. ## Examples **A single domain.** The whole project is one agent. ``` .lynk/domains/core/ └── entities/ └── customer/ ├── ENTITY.md └── schema.yml ``` **A team domain building on `core`.** Marketing reuses `core.customer` and adds its own skill. ``` .lynk/domains/marketing/ ├── LYNK.md ├── GLOSSARY.yml ├── entities/ │ └── customer/ # identity: core.customer │ ├── ENTITY.md │ └── schema.yml └── skills/ └── attribution-analysis/ └── SKILL.md ``` ## Validation * A domain folder name is lowercase alphanumeric with underscores. * A domain with no entities passes with a **warning** — an agent with no entities can't answer anything. * Cross-domain references that violate the declared topology are build errors. ## Related * [LYNK.md](/concepts/domain/lynk-md.md) · [GLOSSARY.yml](/concepts/domain/glossary.md) — the domain's orientation and vocabulary * [Entity](/concepts/entity.md) · [Skill](/concepts/skill.md) · [Policy](/concepts/policy.md) — what a domain holds * [lynk.yml → topology](/concepts/lynk-yml.md#topology) — where the reference pattern is declared * [Project](/concepts/project.md) — how domain + branch + build address an agent * Guides: [Designing domains](/guides/designing-domains.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.getlynk.ai/concepts/domain.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.