GraphN by Lightning AI
Source-backed answers about building and running AI agent workflows with GraphN. Browse platform concepts, workflow design, tools and data, models, APIs, security, and the product's identity.
What the platform is, what teams build with it, and how GraphN relates to Lightning AI.
GraphN is Lightning AI's platform for building, deploying, and operating production AI agents and multi-agent workflows. Teams compose models, tools, knowledge, and application logic as executable workflows, then run them through the web app, API, or CLI.
GraphN supports workflows for document analysis, retrieval-augmented generation, research, content review, customer support, software engineering, data processing, and media generation. Public blueprints provide deployable starting points that teams can adapt to their own data, tools, prompts, and output requirements.
GraphN is for teams that need to move an AI workflow from an idea to a repeatable production integration. Developers can work through the API, CLI, YAML DSL, and Python function SDK, while other builders can compose and test the same resources in the visual web editor.
A GraphN workflow defines inputs, execution steps, data flow, and outputs. An agent is an LLM-powered actor inside that workflow: it follows instructions, runs on a selected model, and can use functions, MCP tools, knowledge bases, storage, and secrets.
GraphN is Lightning AI's platform for building and running production AI agent workflows. It is not affiliated with that earlier 3D visual-programming product.
How GraphN workflows are composed, tested, published, versioned, and executed.
A GraphN workflow is an executable graph with defined inputs, ordered or branching steps, and an output. A workflow can orchestrate agents, Python functions, MCP tools, connectors, conditionals, loops, parallel analysis, handoff routing, and judge loops.
A GraphN agent is a reusable, LLM-powered resource with instructions and a selected model. It can produce text or structured output, call approved tools, retrieve workspace knowledge, and hand work to other steps according to the workflow around it.
A GraphN blueprint is a pre-built workflow package for a specific use case. It can include the workflow graph plus agents, functions, MCP servers, input examples, and output contracts, so teams can deploy a working baseline and then customize it instead of starting from an empty canvas.
Yes. The web editor provides a canvas and resource configuration panels, while the YAML tab exposes the same workflow DSL for code-based editing. The CLI can validate and update DSL files, so visual and repository-based workflows use the same underlying definition.
Yes. The editor and API support test runs, and a dry-run can execute inline DSL and resource definitions without persisting them. This lets teams validate inputs, prompts, tools, branching, and outputs before creating a production version.
Publishing creates a versioned workflow with its DSL and resource snapshots. Production runs use the published state instead of an unfinished draft, and the workflow can then be invoked from its API endpoint or through the GraphN CLI.
Yes. GraphN records published workflow versions, including the DSL and resource snapshots when available. Teams can inspect prior versions and restore a workflow, with the option to restore linked resource specifications as well.
How agents reach external systems, run deterministic code, search documents, and work with files.
GraphN agents can call tools exposed by Model Context Protocol servers. An MCP tool has structured inputs and outputs, giving an agent a controlled way to query or update an external system instead of placing that integration logic inside the prompt.
Use a GraphN function for custom Python logic that belongs to the workflow, such as validation, transformation, scoring, or deterministic processing. Use an MCP tool when an agent needs a structured action supplied by a tool server, especially for an external service or reusable integration.
A GraphN knowledge base is a searchable document collection that agents and functions can query for workspace-specific context. Documents are embedded for semantic retrieval, and searches can return ranked chunks with optional reranking for grounded research and question-answering workflows.
Delete from the Knowledge Bases UI (list bulk delete or the detail page), with the CLI (`graphn kb delete <id> --force`), via the API (`DELETE /v1/{workspace_id}/knowledgebases/{kb_id}`), MCP (`graphn_kb_delete`), or inside a workflow function with `await kb.delete(kb_id)`. Deletion is permanent: there is no soft-delete or restore. A successful call purges vectors and document metadata; cancellation of in-flight ingest and media-object cleanup are best-effort.
A knowledge base is optimized for searching and retrieving relevant document content. GraphN storage is object storage for source files, generated artifacts, attachments, and intermediate outputs; a workflow can use storage for files and ingest selected content into a knowledge base for retrieval.
Yes. GraphN workflows can upload files to storage, convert supported documents, ingest their content into a knowledge base, retrieve relevant passages, and produce structured results. The Company Knowledge Search blueprint and document-analysis tutorial demonstrate this storage-to-retrieval workflow shape.
Yes. Workflows can define input and output schemas, and agents can be configured with structured output requirements. Functions and MCP tools also use explicit parameter and result shapes, allowing downstream applications to consume predictable JSON rather than only free-form text.
Built-in models, imported endpoints, custom model weights, multimodal inputs, and model testing.
Yes. Every GraphN agent selects one model at a time, and agents in the same workflow can use different models. This lets a workflow use a coding model for software tasks, a vision model for media inputs, or a general model for routing and synthesis.
The agent model picker supports chat and vision models available to the workspace. GraphN also registers specialized text-to-speech, embedding, and reranking models for voice and retrieval features, although those specialized models are not selected as an agent's primary language model.
Yes. GraphN can register an OpenAI-compatible chat endpoint such as vLLM, Ollama in compatibility mode, OpenAI, Gemini through its compatible API, or OpenRouter. GraphN also supports custom model imports from Hugging Face or S3, including supported LoRA adapter deployments.
Yes. The imported-model page can stream a test response so you can verify the endpoint, credentials, and model identifier. The API also provides connection testing and model discovery against OpenAI-compatible endpoints.
Yes. Vision-capable agents can work with text, images, and supported video input, while multimodal knowledge bases can index text and images together. Workflows can combine those model calls with storage, conversion, media functions, and structured outputs.
How published workflows are invoked, authenticated, monitored, and developed from external tools.
A published GraphN workflow can be run from the web app, the GraphN CLI, or its workspace-scoped HTTP endpoint. The workflow's API tab provides the exact URL and a request example with the required input wrapper.
Yes. Synchronous runs return the workflow result in the request path, while asynchronous runs return an execution identifier that can be polled or watched. Async mode is the better fit for workflows that may exceed a normal client timeout.
GraphN API requests use a Bearer token. Workspace API keys use the `gn_` prefix, are scoped to one workspace, and are the normal choice for automation; the workspace in the request URL must match the workspace authorized by the key.
A workflow execution can return its identifier, status, output or error, and an execution trace. Depending on the run, the trace can include spans, timing, token usage, resource references, and per-node results for inspecting how the graph completed.
The GraphN CLI can authenticate, inspect workspace resources, deploy blueprints, validate and update workflow DSL, dry-run drafts, publish resources, start production runs, poll executions, and display logs. It also includes local documentation topics for workflow building and debugging.
`graphn init` can add GraphN guidance to a repository for Cursor, Claude Code, Codex, and AGENTS.md. The AGENTS.md target covers every tool that reads that convention, including Zed, OpenCode, Amp, Roo Code, and GitHub Copilot. Gemini CLI reads GEMINI.md by default, so it only picks up AGENTS.md if you add it to `context.fileName` in `.gemini/settings.json`. `graphn mcp-serve` additionally exposes CLI operations as MCP tools, so a coding agent can inspect, validate, test, and update GraphN resources through structured commands.
Workspace boundaries, credentials, API-key handling, CLI telemetry, and the first workflow.
GraphN organizes workflows, agents, functions, models, knowledge bases, storage, secrets, and API keys by workspace. Workspace API keys authorize one workspace, and a request for a different workspace is rejected rather than exposing that workspace's resources.
Credentials should be stored as GraphN secrets and referenced by agents, MCP servers, imported models, or other integrations. Secret APIs return metadata and a preview rather than the complete stored value, keeping credentials out of workflow instructions and normal resource responses.
Treat a GraphN workspace API key like a password. The full key is shown when it is created, so save it in a secure secret manager, never commit it to source control, and delete the key from workspace settings when it should no longer have access.
Yes. The GraphN CLI collects diagnostic telemetry by default, redacts API keys and bearer tokens, and supports permanent or per-session opt-out. Use `graphn telemetry disable` for a persistent opt-out or set `GRAPHN_TELEMETRY_DISABLED=1` for one session.
The getting-started guide takes you from sign-in to a published Support Router workflow in about ten minutes. The blueprint uses bundled mock store data, so the first run does not require an account or API key for a third-party service.
Join the GraphN Discord at graphn.ai/discord to talk to the team directly: questions, bug reports, and workflow design help all land there. For sales conversations, the Request demo form on the landing page reaches us too.
Build your first GraphN workflow
