AI workflow platform for production systems
GraphN is an AI workflow platform for composing, publishing, invoking, and inspecting production workflows that combine explicit orchestration with agentic steps. The workflow defines the data path; agents use models and approved tools where language or judgment is required.
The workflow lifecycle
From blueprint to production execution
Draft state stays separate from the version a production caller invokes. Each stage has a concrete interface and an inspectable result.
- 01
Start
Deploy a public blueprint, compose visually, or define the workflow in the YAML DSL.
- 02
Compose
Connect agents, functions, MCP tools, models, knowledge bases, storage, and secrets.
- 03
Validate
Use test runs or dry-run inline definitions to check inputs, prompts, tools, branches, and outputs.
- 04
Publish
Create a production version with the workflow DSL and resource snapshots, separate from the draft.
- 05
Invoke
Run from the app, CLI, or workspace-scoped HTTP API in synchronous or asynchronous mode.
- 06
Inspect
Follow execution status, output or error, logs, and traces with timing, token, and per-node detail when available.
Control and autonomy
Deterministic structure. Agentic judgment where it belongs.
Use model-driven behavior inside an explicit graph rather than asking one opaque loop to own the full application.
Deterministic structure
The workflow carries the contract and control flow. Functions handle code paths that should produce the same behavior for the same input.
- Workflow graph
- Defines inputs, ordered and branching steps, loops, parallel work, and outputs.
- Functions
- Run repeatable Python validation, transformation, scoring, and processing.
- Contracts
- Give workflow inputs, outputs, function parameters, and tool calls explicit shapes.
Agentic judgment
Agents handle language, synthesis, and decisions that require a model. Their models, tools, context, and place in the graph remain configured resources.
- Agents
- Apply model-driven language and judgment within the boundaries of a workflow step.
- Approved tools
- Let an agent call configured functions or MCP tools with structured arguments.
- Grounded context
- Attach knowledge bases, files, and selected models where the task requires them.
Deployment and runtime ownership
Know which boundary GraphN operates
Production ownership is easier to evaluate when authoring, orchestration, function isolation, models, and the calling application are named separately.
- Authoring and control plane
- GraphN stores workspace-scoped workflows and resources, validates definitions, and creates published versions with resource snapshots.
- Workflow execution
- Synchronous runs execute in the request path. Asynchronous runs are scheduled durably and return an execution identifier for later inspection.
- Functions and tools
- GraphN functions run in an isolated sandbox. MCP servers remain the structured boundary to external systems and their actions.
- Models
- Built-in and custom-weight models can run behind GraphN's managed inference API. Registered external endpoints remain operated by their provider or your team.
- Your application
- Your application decides when to invoke a published workflow, supplies its input contract, and consumes the returned result or execution status.
Interfaces, evidence, and controls
Operate through defined interfaces
Choose the request mode around latency and lifecycle, then use workspace and execution records as the operating boundary.
API and execution modes
- Synchronous workflow API
- Use when a published workflow can finish inside the caller's request window and return the result directly.
- Asynchronous workflow API
- Use for longer work. The request returns an execution ID that clients can poll, watch, cancel, or use to retrieve logs.
- Gateway modes
- The platform gateway supports synchronous, asynchronous event, SSE streaming, WebSocket, and batch primitives; the modes exposed depend on the configured factory.
- Model inference API
- Call built-in, custom-weight, or registered models through an OpenAI-compatible interface independently of a workflow.
Operational and security controls
- Workspace boundaries
- Workflows, agents, tools, models, data resources, secrets, and API keys are scoped to a workspace.
- Credentials
- Workspace API keys authorize automation. GraphN secrets keep credentials out of prompts and normal resource responses.
- Execution evidence
- Execution records expose status, output or error, and trace detail such as spans, timing, token usage, and node results when present.
- Inference guardrails
- Configured guardrails can inspect chat-completion and text-to-speech traffic before model requests proceed.
Concrete starting points
What to build first
Start with the smallest working resource graph that exercises the boundary you need. Replace demo resources only after the input and output contract is clear.
Route a support request through triage and specialist agents that call a bundled mock store tool.
Build first: only a GraphN workspace; the blueprint includes demo data.
Ingest documents into an existing knowledge base, then answer questions with cited retrieval evidence.
Prepare first: a knowledge base and the documents you want the workflow to search.
Search workspace documents and synthesize an answer with cited sources.
Prepare first: a populated knowledge base with material relevant to the query.
Operational fit
Choose the platform boundary deliberately
The broad platform page defines GraphN's boundary. The linked decision guides compare that boundary with individual frameworks and cloud services.
GraphN is a strong fit when
You need one versioned workflow definition across visual and code-based authoring.
The system mixes explicit orchestration with model-driven judgment.
Models, tools, workspace data, secrets, execution history, and API invocation need a shared boundary.
The team wants to start from a working blueprint and replace resources incrementally.
Evaluate the boundary first when
A small in-process agent loop already meets the requirement and your team wants to own its runtime.
Every dependency must stay inside infrastructure that you operate; verify each managed and external boundary before adopting.
The workload needs a gateway mode or model capability that is not exposed by the selected workflow or factory.
The application has no stable input/output contract yet; define that boundary before adding agents or tools.