Skip to content

LangGraph Engine

One engine that runs a team of AI agents, where configuration decides what the team does

LangGraph Engine is a development project. A manager agent receives a brief, plans together with the person who sent it, asks counter-questions and hands the work to agents with specialised roles.

  • One engine, many services. The same core can run quite different services, for example a creative agency, just by changing the configuration. The code stays the same.
  • A person stays in control. The plan is approved before the work starts, a person can step in along the way, and the agents turn back to the manager when they need help.
  • Any interface can drive it. The engine shows the progress of a run live and is built to work with different frontends. A first one is being built.
  • Built from a written specification. The requirements are written down first, and the work is done in small steps, each tested before the next.

A learning project in my own time, not client work.

Technical

Architecture & capabilities

The engine as the core, pluggable frontends on top, agents and persistence below (opens full size in new tab)
The engine as the core, pluggable frontends on top, agents and persistence below

Architecture principles

  • The engine is the product; frontends are pluggable. One core, delivered behind an HTTP/SSE boundary, driven by config — build/attach a different frontend per network type without touching the core.
  • Domain-neutral by construction: agent roles, prompts, and seed-data live in configuration (YAML + seed), so a creative-agency network and a financial-advisor network are the same binary with different config.
  • No vendor lock-in in persistence: PostgreSQL accessed via raw SQL/psycopg, no ORM or vendor SDK. Backend and frontend are separate repos — no monorepo, no shared code — coupled only by the API contract.

Capabilities

  • Manager agent runs a planning dialogue, asks counter-questions, then distributes work to role-specialized sub-agents; sub-agents escalate back to the manager when they hit their limits.
  • Human-in-the-loop at the decision points: approve a plan, steer mid-run, or handle an escalation.
  • Tools in an agentic loop (e.g. web search) available to agents during execution.
  • Live run state streamed over SSE; the reference frontend consumes it for new-run, run-list, run-detail, and live-status views.

Design decisions

What Why Resolution
Persistence layer An ORM/vendor SDK would add a dependency and abstraction the engine doesn't need Raw SQL via psycopg against PostgreSQL — direct, inspectable, portable
Backend ↔ frontend coupling A monorepo/shared package would tie the two release cycles together Two separate repos, coupled only by the HTTP/SSE contract; frontend pinned to a Claude Design UI-spec
Per-domain behaviour Forking the code per customer/network would multiply what has to be maintained One domain-neutral core; behaviour comes from config (agent defs + seed-data)

Evolved from an earlier CrewAI proof-of-concept (ai-creative-agency) into the current LangGraph-based, spec-driven rebuild.