Skills vs LangChain, LangGraph, MCP, and Tools: A Practical Architecture Guide

Scenario context

These are not competing ideas. They are layers. Tools do one action. MCP standardizes access to actions and resources. LangChain and LangGraph orchestrate calls. Skills package business outcomes with contracts, guardrails, and evaluation. Most production confusion comes from mixing these layers.

---

Internals: control plane vs execution plane

A useful split:

• Control plane: registry, routing policy, ris…

This walkthrough focuses on Deep Dive: Why Layer Confusion Breaks Production Systems.

Before making a design choice, clarify:

• Internals: control plane vs execution plane A useful split: - Control plane : registry, routing policy, risk gating, rollout rules - Execution plane : LangGraph graph run, MCP calls, tool invocation, retries If everythi…
• Skills sit at the boundary and stabilize product expectations while execution internals evolve.
• Mathematical model: route score vs policy eligibility A practical routing pattern: $$ Eligible(s, q) = PolicyAllow(s, q) \land PermissionAllow(s, q) $$ Then score only eligible skills: $$ Score(s \mid q) = a \cdot Fit -…

Concepts in play: llm-agents-and-langgraph, graph-traversal-algorithms, tree-data-structures, design-patterns-gof

Stage 1 — The Layer Cake: What Each Term Actually Means

• A product team shipped a customer support agent that worked in every demo.
• In production, it returned inconsistent refund decisions — sometimes citing correct policy, sometimes hallucinating eligibility rules — because the "agent" was a single LangGraph workflow with no output contract and no…
• The problem was not the model.
• The problem was missing layers.

flowchart TD
    Goal[Define Agent Goal]
    Single{Single tool call or simple chain?}
    Stateful{Multi-step stateful workflow?}
    Contract{Need stable output contract?}
    Cross{Cross-system tool discovery?}

    LC["LangChain (prompt chains, tools)"]
    LG["LangGraph (stateful graph, retries)"]
    Skill["Skill Layer (reusable capability)"]
    MCP["MCP (cross-system protocol)"]
    Both[LangGraph + Skill Layer]

    Goal --> Single
    Single -->|Yes| LC
    Single -->|No| Stateful
    Stateful -->|Yes| Contract
    Contract -->|No| LG
    Contract -->|Yes| Both
    Cross -->|Yes| MCP
    Both --> Cross

sequenceDiagram
    participant R as Router
    participant NA as Node A
    participant E as Edge Condition
    participant NB as Node B
    participant NC as Node C
    participant Term as END

    R->>NA: Start graph execution
    NA->>NA: Process state
    NA->>E: Evaluate conditional edge
    E-->>NB: Condition = "path_b"
    NB->>NB: Process state
    NB->>Term: Transition to END
    Note over NC: Node C not executed. Conditional branch skipped.

Observable outcome: The problem was missing layers.

Stage 2 — Where LangChain and LangGraph Fit, and Where They Do Not

• LangChain and LangGraph are implementation frameworks.
• They help you execute reasoning and workflows.
• They do not automatically define product-level ownership, risk boundaries, or capability lifecycle.
• They build one graph and call it a "skill".

Observable outcome: They build one graph and call it a "skill".

Stage 3 — End-to-End Execution Path: How the Layers Collaborate

• Let us trace one request: "Investigate payment failure spikes and open an incident if needed." This flow exposes the distinction clearly: - LangGraph is the runtime engine for state transitions.
• • MCP is the interoperability channel for tools/resources.
• • Skill wraps the whole thing as a reusable product capability.
• Mini dataset for one run: The skill result is what downstream products depend on.

flowchart TD
    A[User request] --> B[Router chooses PaymentIncidentSkill]
    B --> C[Skill validates input and policy]
    C --> D[LangGraph executes workflow state]
    D --> E[Node calls tools via MCP]
    E --> F[Collects logs metrics and ticket status]
    F --> G[Skill output validation]
    G --> H[Final structured response plus trace]

Observable outcome: Mini dataset for one run: The skill result is what downstream products depend on.

Stage 4 — Real-World Applications: Real-World Patterns That Make This Practical

• Pattern 1: Product support copilot - Tools: CRM lookup, order API, refund API.
• • MCP: centralizes access to those systems.
• • LangGraph: executes decision branches (refund eligible or not).
• • Skill: RefundResolutionSkill returns decision , reason , next action .

Observable outcome: - Skill: RefundResolutionSkill returns decision , reason , next action .

Stage 5 — Practical Example: One Capability Across All Layers

• Example 1: Tool and MCP-facing adapter This example traces a single payment incident investigation capability across all four architectural layers — raw tool function, skill contract with policy gate, LangGraph-orchestr…
• The multi-layer presentation was chosen deliberately because the most common architectural mistake in agent systems is forcing one layer to do the work of all the others.
• When reading the code, focus on where the output contract appears: only the skill layer enforces a stable typed return value, which is what makes downstream integrations predictable regardless of how the internal execut…
• Example 2: LangGraph workflow plus skill boundary This code is simple, but the design principle is important: output contract remains stable even if runtime internals change.

# Tool function signature

def fetch_payment_metrics(service: str, window_minutes: int) -> dict:
    return {
        "service": service,
        "window_minutes": window_minutes,
        "error_rate": 0.087,
        "p95_latency_ms": 1230,
    }

# In practice this tool may be exposed through an MCP server with typed schemas.

from dataclasses import dataclass

@dataclass
class PaymentIncidentInput:
    service: str
    window_minutes: int

def payment_incident_skill(payload: PaymentIncidentInput) -> dict:
    # 1) Validate boundary
    if payload.window_minutes <= 0:
        raise ValueError("window_minutes must be positive")

    # 2) Graph execution would happen here
    metrics = fetch_payment_metrics(payload.service, payload.window_minutes)

    # 3) Policy gate
    must_open_incident = metrics["error_rate"] >= 0.05

    # 4) Stable contract
    return {
        "service": payload.service,
        "error_rate": metrics["error_rate"],
        "incident_required": must_open_incident,
        "reason": "error_rate_threshold_breached" if must_open_incident else "within_limits",
    }

Observable outcome: Example 2: LangGraph workflow plus skill boundary This code is simple, but the design principle is important: output contract remains stable even if runtime internals change.

Stage 6 — LangChain, LangGraph, and MCP: Concrete Implementation of the Four Layers

• LangChain provides the Runnable abstraction — chainable, composable steps with a uniform .invoke() / .stream() interface.
• LangGraph adds stateful graph execution with checkpointing and cyclic routing.
• MCP (Model Context Protocol) is an emerging open standard for exposing tools and data resources to LLMs over a typed protocol, enabling cross-framework capability sharing.
• This single code block illustrates the separation of concerns: the tool is an atomic function, the LangChain RunnableSequence handles linear orchestration, LangGraph manages stateful branching, and the skill wrapper exp…

# pip install langchain langchain-core langgraph
from langchain_core.runnables import RunnableLambda, RunnableSequence
from langgraph.graph import StateGraph, END
from typing import TypedDict, Optional

# --- Layer 1: Tool — one atomic action ---
def fetch_payment_metrics(service: str, window: int = 15) -> dict:
    """Retrieve error rate and latency; replace with real observability API."""
    return {"service": service, "error_rate": 0.072, "p95_ms": 980}

# --- Layer 2: LangChain Runnable chain — lightweight sequential orchestration ---
enrich_chain = RunnableSequence(
    RunnableLambda(lambda x: fetch_payment_metrics(x["service"])),
    RunnableLambda(lambda m: {**m, "alert": m["error_rate"] >= 0.05}),
)
# Use for simple, linear workflows: result = enrich_chain.invoke({"service": "pay-svc"})

# --- Layer 3: LangGraph stateful workflow — stateful branching and retry ---
class PaymentState(TypedDict):
    service:     str
    metrics:     Optional[dict]
    incident_id: Optional[str]

def fetch_step(state: PaymentState) -> PaymentState:
    return {**state, "metrics": fetch_payment_metrics(state["service"])}

def ticket_step(state: PaymentState) -> PaymentState:
    iid = f"INC-{abs(hash(state['service'])) % 9999:04d}"
    return {**state, "incident_id": iid}

def should_escalate(state: PaymentState) -> str:
    return "ticket" if state.get("metrics", {}).get("error_rate", 0) >= 0.05 else END

graph = StateGraph(PaymentState)
graph.add_node("fetch",  fetch_step)
graph.add_node("ticket", ticket_step)
graph.set_entry_point("fetch")
graph.add_conditional_edges("fetch", should_escalate)
graph.add_edge("ticket", END)
workflow = graph.compile()

# --- Layer 4: Skill — stable product contract wrapping the graph ---
def payment_incident_skill(service: str) -> dict:
    """
    Public capability contract. Internal runtime can change without affecting callers.
    This is what the registry, router, and downstream systems depend on.
    """
    result = workflow.invoke({"service": service, "metrics": None, "incident_id": None})
    return {
        "service":     result["service"],
        "error_rate":  result.get("metrics", {}).get("error_rate"),
        "incident_id": result.get("incident_id") or "none",
    }

print(payment_incident_skill("payments-svc"))

Observable outcome: This single code block illustrates the separation of concerns: the tool is an atomic function, the LangChain RunnableSequence handles linear orchestration, LangGraph manages stateful branching, and the skill wrapper exp…

End-to-end outcome

After working through the stages, you should be able to explain:

• • Tools, protocols, frameworks, and skills are complementary layers.
• • Framework quality does not replace capability modeling discipline.

Alternatives considered

Sequence View: Tool-Only Agent vs Skill-Centric Agent

A tool-only approach may skip S and return free-form text.

Decision Guide: What to Build at Your Current Maturity

Quick rule set:

Failure and degraded modes

Trade-offs & Failure Modes: Trade-offs and Failure Modes

• Detection: You should not force everything into skills.
• User or operator impact: You should not force everything into skills.