Skip to main content
You’re building a LangGraph agent and you want a deterministic decision node — same inputs, same answer, every time, traceable to source. Aethis is already an MCP server (aethis-mcp), and LangGraph has first-class MCP support via the official langchain-mcp-adapters package. No custom adapter needed — register aethis-mcp as a stdio MCP server and its tools become LangChain Tools your graph nodes can call. The runtime decision path stays in formal logic. The LLM still drives the conversation; the eligibility step does not.

Install

You also need aethis-mcp reachable on your PATH. Either install it once:
…or let npx resolve it on first call (slower cold start, no global install).

The recipe

create_agent lives in the langchain package as of LangChain 1.x. The older langgraph.prebuilt.create_react_agent still imports but is deprecated in favour of it, so it emits a deprecation warning on every run. Same prebuilt tool-calling agent; the argument for a system prompt is system_prompt= rather than prompt=.
The agent will call aethis_schema (to discover fields), then aethis_decide (to evaluate), and report the result. The decision itself never touches the LLM — it’s evaluated by the constraint solver on api.aethis.ai and returns a stable decision_id + inputs_hash you can store for audit.

What just happened

The LLM picks the ruleset, parses the user’s free-text, and presents the result. The decision is made by formal logic on the server and is byte-stable across runs.

Anonymous vs keyed paths

  • aethis_decide / aethis_schema / aethis_explain on a public ruleset — anonymous, no API key. Works in the recipe above as-is.
  • aethis_decide on a composed Rulebook (rulebook_id=...) — always scope-gated. Pass an API key via the MCP server env:
  • Authoring tools (aethis_create_ruleset, aethis_generate_and_test, aethis_publish) — require a key and are in private beta. Request access at aethis.ai/developer-access.

When to use this vs an LLM-only node

Use Aethis when:
  • The decision must be stable across runs (audit, compliance, regulated decisions).
  • You need a trace back to the source clause for every result.
  • The rule is encodable (legislation, policy, contract, internal SOP) — anything where “the answer is in this document” rather than “the answer requires judgment.”
Stay LLM-only when:
  • The decision genuinely requires open-ended reasoning.
  • The cost of a wrong answer is low.
  • The rule changes every conversation.
The right pattern is usually both: LLM nodes for routing, summarisation, and user interaction; Aethis nodes for the regulated check at the centre of the flow.

See also

  • Evaluate a case — the four-call pattern (schema → fields → decide → explain) without LangGraph.
  • MCP server overview — full tool list and stdio config.
  • Decision envelope — what’s in the response, and how to use inputs_hash + decision_id for audit.