Graph Structure Basics

This library expects each LangGraph file to expose three things:

1. Input – a Pydantic model describing the input state.

2. Output – a Pydantic model describing the output state.

3. compiled_graph – the compiled StateGraph instance.

These names are required so the configuration loader can locate them when building a Function App.

A minimal example is shown below, taken from the test graphs:

from pydantic import BaseModel
from langgraph.graph import StateGraph, START
from typing import Optional

class Input(BaseModel):
    input_text: str

class Output(BaseModel):
    update: Optional[str] = None

class MergedState(Input, Output):
    pass

def test(state: MergedState) -> dict:
    return {"update": "ok"}

compiled_graph = (
    StateGraph(input=Input, output=Output)
    .add_node("test", test)
    .add_edge(START, "test")
    .set_finish_point("test")
    .compile(name="test_graph")
)

Every graph in your project should follow this pattern so that the YAML loader can import it correctly.

The key takeaway is that langgraph_func does not change how you write graphs. You build them exactly as you would when using langgraph directly. By keeping the same pattern, any graph can be imported and exposed as an API endpoint or reused as a subgraph in another graph.

When a graph is registered through the YAML configuration it becomes available as a normal Azure Function. Other graphs can call this function via call_subgraph, enabling powerful composition and easier debugging.