---
title: Working with Graphite Atlas
purpose: Starter knowledge file for an AI agent connected to the Graphite Atlas MCP server
generated: 2026-08-05
point_types: 28
path_types: 37
source: https://docs.graphiteatlas.com/connect-ai/skills-and-plugin
---

# Working with Graphite Atlas

This is a starter file. Upload it as a knowledge source on your agent, then edit it to match
your organization — the type names below are the standard Atlas language and apply to every
atlas, but the examples are generic and worth replacing with your own.


## What Atlas is

Graphite Atlas is a model of how an organization actually operates. Not its data — its operations. People, the positions they hold, the processes they run, the steps inside those processes, the systems used, the documents produced, the risks carried, and the outcomes measured.

The distinction matters when deciding whether Atlas can answer a question. A data warehouse knows how many invoices were paid late. Atlas knows who approves an invoice, which system they use, who they hand it to next, and what happens if that person is on vacation. That knowledge usually exists nowhere else — it was captured from interviews, documents, and process walkthroughs.

Two building blocks:

- **Points** — things. Every Point has a `name` and a `type`.
- **Paths** — typed relationships between Points. A Path's type is stored in its `name`.

## The types

**Actors — who is involved**

| Type | Means |
|---|---|
| Person | A specific individual. Dana Reyes. |
| Position | A role, independent of who holds it. Controller, VP Engineering. |
| Group | A named collection of people. Finance Team. |
| Organization | A legal or business entity. |
| Vendor | An external supplier or provider. |
| Agent | An autonomous AI actor. |

**Actions — what gets done**

| Type | Means |
|---|---|
| Process | A named body of work with steps. Monthly Close. |
| Step | One atomic unit of work inside a Process. |
| Approval / Review / Decision | Specific step kinds with a judgment attached. |
| Handoff | A transfer of *responsibility* between actors. |

**Resources — what work uses**

| Type | Means |
|---|---|
| System | Software that does work. NetSuite, the ERP. |
| Document / Artifact | Something produced or consumed. An invoice, a report. |
| Policy | A rule the organization holds itself to. |
| Equipment, Skill | Physical assets; human capabilities. |

**Outcomes — what it's for**

| Type | Means |
|---|---|
| Outcome | A result the organization wants. |
| Metric | How an Outcome is measured. |
| Risk | Something that threatens an Outcome. |

## Relationships worth knowing

| Path | Reads as |
|---|---|
| `has_role` | Person → Position. Dana holds the Controller position. |
| `reports_to` | Position → Position. Reporting lines connect *positions*, not people. |
| `performs` | Actor → Step. Who actually does it. |
| `accountable_for` | Actor → Outcome/Process/Step. Who answers for it. |
| `has_step` | Process → Step. Membership. Every member step needs one. |
| `followed_by` | Step → Step. Order only, not membership. |
| `uses_resource` | Step → System/Equipment. |
| `needs_input` / `creates_output` | Step ↔ Document/Artifact. |
| `provided_by` | System → Vendor. The service, then who provides it. |
| `has_risk` / `mitigates` | What threatens something; what reduces it. |
| `measured_by` | Outcome → Metric. |

Three reading rules that prevent wrong answers:

1. **People hold Positions; Positions report.** To answer "who does Dana report to," follow Dana → `has_role` → Position → `reports_to` → Position → back to whoever holds it.
2. **`has_step` is membership, `followed_by` is order.** A step can be in a process without being first, and sequence edges don't imply membership.
3. **A Handoff is a transfer of responsibility.** A notification or an FYI is an ordinary Step, not a Handoff.

## How to explore

Start wide, then narrow:

1. `list_atlases` — what exists
2. `get_atlas_brief` — a written summary of one atlas, meant to be read before anything else
3. `search_points` — find a Point by name; `semantic_search` — find one by meaning when you don't know the name
4. `get_node_neighborhood` — everything connected to a Point, N hops out. This is where most answers live.
5. `query_cypher` — for counting, filtering, or spanning many points at once
6. `lookup_ontology` — what types exist and what may legally connect to what

## Question patterns

| Question | Route |
|---|---|
| "Who owns X?" | find X → neighborhood → `accountable_for` / `performs` → Position → holder |
| "What does this process involve?" | find the Process → `has_step` → order via `followed_by` |
| "What happens if Dana leaves?" | Dana → `has_role` → Position → everything that Position performs or is accountable for |
| "Where are the manual steps?" | steps with no `uses_resource` to a System |
| "What depends on this system?" | System → incoming `uses_resource` → steps → their processes |
| "What's at risk here?" | `has_risk` from the process or outcome, then `mitigates` for controls |

## Honesty rules

Answer from the graph, and name the Points you used. If the graph doesn't contain something, say that directly — "Atlas doesn't record who approves purchases over $50k" is a useful answer, and the gap itself is often the finding. Do not substitute general knowledge about how companies usually work; the value of Atlas is that it describes *this* organization, and a plausible invention is worse than a gap.