To draw your go-to-market resource graph, run cargo-ai project graph: it prints every resource in your Cargo workspace (connectors, models, segments, plays, tools, agents and the rest) and what each one points at, as a Mermaid flowchart. Add --project to draw your repository instead, offline, and --plan to colour what the next deploy would create, update or delete.
Mermaid renders in GitHub, in most docs tools and in coding agents, so the graph can go straight into a README or a pull request comment.
The commands #
npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com
cargo-ai project graph # the live workspace, as Mermaid
cargo-ai project graph --project # the local project, offline, no API calls
cargo-ai project graph --project --plan # mark what the next deploy changes
cargo-ai project graph --json > graph.json # the same graph as JSON
cargo-ai cdk graph and the standalone cargo-cdk graph are the same command. --plan only works with --project, because the diff is between your code and its deploy state.
What comes back #
A Mermaid flowchart, left to right. Each resource is a node labelled with its kind and name, folders become nested subgraphs, and the arrow says what the edge means:
flowchart LR
subgraph n0["Outbound"]
n4["play: Expansion"]
end
n1["connector: HubSpot"]
n2["model: contacts"]
n3["segment: Expansion targets"]
n1 -.-> n2
n2 -.-> n3
n3 -.-> n4
n4 -->|"updateContact"| n1
That is the shape, not output from a real workspace. The edge kinds, read from source to target:
| Edge | Meaning |
|---|---|
uses | calls a connector: a workflow action, an agent’s model or MCP server |
feeds | records flow: a connector into its model, a model into a segment, play or agent |
calls | invokes a tool, agent, worker, MCP server or app |
triggers | a play starts the play scheduled after it; a connector’s events start an agent |
parent | a model unified under a parent model |
relates | a relationship between two models |
watches | an alert over a play, tool, agent or model |
With --plan, created resources are green, updated ones amber and deleted ones red and dashed.
--json prints a versioned CargoGraph object (version, source, workspace, nodes, edges, unresolved, integrations). unresolved lists references the graph does not contain, such as a resource deleted outside the project or a modelRef to something the project does not declare. A workspace graph also carries each integration’s logo and colour; a project graph read offline does not.
When to use which #
- The workspace graph answers “what is actually running”: everything in the workspace, including resources nobody declared in code.
- The project graph answers “what does this repository declare”, and needs no login. If a resource file fails to load, the command prints the errors and exits rather than drawing a graph that silently omits the broken resources.
- The plan graph is a review aid: paste it into a pull request so a reviewer sees which part of the engine a change touches. On a connected repository, the plan comment already lists the changes and what the merge sends.
To draw a single play, tool or run step by step rather than the whole workspace, use cargo-ai orchestration node diagram.
More on the lifecycle: GTM as code: the complete guide. Every resource the graph can contain is declared with the Cargo CDK.