Documentation

    Getting started

Core concepts

You finished Getting Started and built or explored the Support Router — a workflow that routes customer messages to the right help. This page names the building blocks you see in GraphN and how they connect. Use it as a map before you read deeper reference material.
For the full path from these building blocks to a published, observable production run, see the GraphN AI workflow platform overview.
GraphN sidebar showing Home, Workflows, and the Resources section
GraphN sidebar showing Home, Workflows, and the Resources section

How the pieces fit together

A workflow is the container: it describes the steps and how data moves. Agents do the language-and-reasoning work inside those steps. They run on models you pick, call tools from MCP servers or functions, pull context from knowledge bases, use storage for files when needed, and can rely on secrets so credentials never sit in plain text.

Workflows

A workflow is the orchestration container for your automation. It defines inputs, the graph of steps, and outputs. You open and manage workflows from Home using Workflows — that is where you see what you have built and open the canvas or template for a flow like Support Router. You can also browse the public AI workflow blueprint catalog to compare real inputs, stages, resources, and output contracts before deployment.
Relates to the rest: A workflow wires agents (and other steps) together; it does not replace them. Think of it as the blueprint that says which agents run, in what order, and what each step receives.
Example: The Support Router workflow is one workflow: it takes a customer message and runs it through the routing hub you saw in the guide.
Support Router workflow canvas showing agents inside the Order Hub
Support Router workflow canvas showing agents inside the Order Hub

Agents

Agents are the LLM-powered actors that read instructions, decide what to do, and produce responses or handoffs. You browse and edit them from the sidebar under Agents (in Resources).
Relates to the rest: Each agent uses a model, may call MCP servers or functions, may search a knowledge base, read or write storage, and may use secrets for protected values — all configured per agent and workflow.
Example: Remember the four agents in Support Router? Each of those is an agent: one greets and routes the conversation, and the others specialize in orders, returns, and product questions.
Agent editor showing Triage_Agent configuration and model assignment
Agent editor showing Triage_Agent configuration and model assignment

Functions

Functions are custom Python code you maintain as workspace resources. They show under Functions in the sidebar. You attach them where the workflow or agent needs deterministic logic outside the model’s free-form reasoning.
Relates to the rest: Functions complement agents: agents handle language and judgment; functions handle repeatable code paths. Agents can invoke the functions you define, alongside tools from MCP servers.
Example: In Support Router, the heavy lifting is agents plus store tools; if you later added a step that normalizes order IDs or scores urgency before routing, you would implement that logic as a function and connect it in the workflow.

MCP servers

MCP (Model Context Protocol) servers expose tools — structured actions with inputs and outputs — that agents can call during a run. You manage them under MCP Servers in the sidebar. They are how agents reach external systems in a controlled way.
Relates to the rest: Agents use MCP tools together with functions and optional knowledge bases or storage. Secrets often back API keys those tools need.
Example: In Support Router, the store integration (look up orders, tracking, returns, product search) is provided as MCP tools so the specialist agents can fetch real data instead of guessing.

Knowledge bases

Knowledge bases are searchable document stores you attach when answers should come from your own material. Open Knowledge Bases in the sidebar to create and manage them. Deleting a knowledge base from the UI, CLI, API, or a workflow helper (kb.delete) is permanent and cannot be undone. Vectors and document metadata are purged; cancellation of in-flight ingest and media-object cleanup are best-effort.
Relates to the rest: Agents query a knowledge base when you connect it to their workflow or configuration — alongside MCP tools and functions.
Example: If you extended Support Router with policy PDFs or an internal FAQ, you would put that content in a knowledge base so the agents can cite it when policies apply.

Storage

Storage is file storage for your workspace — buckets you use when a run needs to read or write files. In the sidebar it appears as Storages.
Relates to the rest: Workflows and agents reference storage when steps produce artifacts (exports, attachments, intermediate files). It sits beside knowledge bases (documents for search) rather than replacing them.
Example: A support workflow might write a generated summary or receipt to storage for the next step or for download.

Secrets

Secrets hold encrypted credentials — API keys, tokens, and similar values — that agents and integrations use without exposing them in instructions or logs. Open Secrets in the sidebar under Resources.
Relates to the rest: You reference secrets when configuring agents, MCP servers, or other parts of a flow that must authenticate to a service.
Example: If your Support Router connected to a live help desk API, you would store the API key as a secret and wire it into the tool configuration instead of typing it into prompts.

Models

Models are the LLMs available when you configure an agent. The list comes from what your workspace can run or import; you choose one in the agent editor (the Model control when you create or edit an agent). You can also open Models in the sidebar to review what is available.
Relates to the rest: Every agent runs on exactly one selected model at a time; changing the model changes cost, latency, and behavior for that agent’s role in a workflow.
Example: In Support Router, the triage and specialist agents each use a model you pick in the agent settings — the same workflow can use different models for different agents if you want to balance speed and quality.

Next steps

  • AI workflow blueprints — start from a pre-built workflow organized by use case
  • Tutorial: Document analysis — customize a template for a real use case
  • DSL Reference — the workflow YAML format in depth
  • API Reference — every endpoint for programmatic access
  • Models Reference — built-in models and custom model import
  • Function SDK Reference — writing custom Python functions
  • GraphN FAQ — concise answers about agents, workflows, models, execution, and security
Previous

Developing with agents

Next

Workflow DSL