Skills, knowledge, and tools Private Preview
Every Context Engineering Studio (CES) repository is built from three primitives: skills, knowledge, and tools. A reasoning model uses all three together. Skills define how the agent behaves, knowledge defines what it understands, and tools define what it can act on.
- Skills: How the agent behaves. Reusable, named capabilities such as "Forecast ARR by segment" or "Triage a refund request," authored in markdown with a persona, plus the runtime artifacts (Python, SQL, YAML) the skill invokes.
- Knowledge: What the agent understands. The semantic model, glossary terms, parsed SOPs, policies, and runbooks. The agreed business truth that keeps every consumer answering the same way.
- Tools: What the agent acts on. Query tools, MCP servers, APIs, and workflow triggers. The integrations a repository is allowed to use.
Every primitive is a first-class Atlan asset: discoverable, governed, versioned, and reusable across repositories and agents.
What are skills?
A skill is a named, reusable capability the agent performs end to end. Every skill carries three things:
- Instructions in markdown: The playbook covering business logic, KPI rules, steps to take, and edge cases to call out.
- A persona: Shapes the response. The same skill can answer a frontline user concisely and give a reviewer the full reasoning trace.
- Bundled artifacts: The deterministic code the skill invokes at runtime. This is what makes a skill more than a prompt.
Skills carry artifacts, not just instructions
A skill is markdown plus the executable artifacts it needs to do real work. Where a step is deterministic, attach an artifact rather than asking the model to reason it out. The agent invokes the artifact when the skill calls for it:
Python script Deterministic logic such as a refund-policy validator, or a transform that reshapes a result before it's returned.
SQL template A parameterized query the skill runs on a connected engine.
Definition file (YAML) Metrics, dimensions, joins, and filters that ground the skill in the semantic model.
A skill packaged this way is portable: markdown tells the agent when and why to act; the artifact gives it a deterministic, auditable how.
Refund validation example
A refund-validation skill is one entry in the repository: a markdown skill definition that bundles a Python script as a runtime artifact. The two pieces live side by side in the same skill.
1. The skill definition (validate-refund.md): what the agent reads. Frontmatter sets identity and persona; the body is the playbook the agent follows. Step 2 references the bundled artifact by filename:
---
name: validate-refund
description: Check a requested refund against policy before issuing it.
persona: support-agent
---
When a refund is requested:
1. Look up the order with the `query-orders` tool.
2. Run the `refund_policy.py` artifact with the order total and customer tier.
3. If the script returns `approved`, issue the refund and open a ticket
with the `open-ticket` tool. Otherwise, explain why and escalate.
2. The bundled artifact (refund_policy.py): what actually runs when step 2 fires. Deterministic policy logic that doesn't belong inside a prompt. The script reads inputs from stdin, applies the tier cap, and prints approved or needs_review for the agent to act on:
import sys, json
def evaluate(order_total: float, customer_tier: str) -> str:
cap = {"standard": 200, "premium": 1000}.get(customer_tier, 0)
return "approved" if order_total <= cap else "needs_review"
if __name__ == "__main__":
args = json.loads(sys.stdin.read())
print(evaluate(args["order_total"], args["customer_tier"]))
System skills versus custom skills
Skills come from two places:
System skills (ship with Atlan) Repository generation, semantic-model generation, search, and lineage traversal. How CES does its own work, available to any agent that reads the repository.
Custom skills (authored by your team) Brand voice, an SOP traversal, or a domain-specific calculation. Write once and reuse across repositories instead of restating it in every prompt.
What is knowledge?
Knowledge is the agreed business truth the agent consults. It's the shared layer that keeps every consumer answering the same way, and it has three components:
- The semantic model: The formal slice that maps measures, dimensions, joins, and filters to physical tables and columns. CES stores it as editable YAML and projects it into the format each target engine expects at deploy time. Semantic views are one projection of this model, not the model itself.
- Glossary terms: Certified business definitions linked to columns, so terms like revenue or active customer resolve consistently across every repository that uses them.
- Parsed SOPs, policies, and runbooks: Knowledge folders and files that Context Agents turn into rules, filters, and skill entries (for example, "exclude intra-company transfers from recognized revenue").
Knowledge isn't limited to the warehouse. Runtime knowledge from sources like Confluence, Slack, or an enterprise search connector can be retrieved through tools at query time without first being stored as an asset.
What are tools?
Tools are the integrations and actions a repository is allowed to use. A tool is how the agent reaches information or takes an action:
Query tools Run SQL on scoped tables and columns, or query the catalog (for example, look up a glossary term).
MCP tool calls Anything exposed over the Model Context Protocol, including Atlan's own search, semantic-search, lineage, and query tools, or a third-party MCP server.
APIs An internal service the agent calls (for example, check device status before answering a support question).
Workflow triggers Take an action such as opening a Jira ticket when a metric crosses a configured threshold, paging on-call, or posting to Slack.
Composing primitives
A repository bundles skills, knowledge, and tools for one use case, and that bundle is the deployable unit. Because the three primitives are separated, they're reusable across repositories and agents:
- The same brand-voice skill serves every customer-facing agent in your organization.
- The same revenue definition in knowledge keeps the finance, sales, and exec repositories aligned.
- The same query tool can be exposed to any repository that needs warehouse access.
Larger problems decompose naturally. A scoped repository can behave as a sub-agent, with an orchestrator routing across several of them.
See also
- What is Context Engineering Studio?: the harness, the ADLC checkpoints, and what CES reads from.
- Enable Context Engineering Studio: enable CES on your tenant and assign access.
- Build your context repository: create a repository and generate the semantic model.
- Run simulations: run question sets and apply proposed fixes.
- Deploy to Snowflake: push your context repository to Snowflake Cortex Analyst.
- Deploy to Databricks: push your context repository to Databricks Genie.