wanmol/goal-flow

What it claims

A LangGraph framework with two authoring paths that can be nested: a workflow graph node can host an agent loop, and an agent can call sub-workflows as tools. The README says neither plain graphs nor plain agent loops are enough alone, and nesting them is the point of the design. The load-test claim has a stated setting: two replicas, each with 2 vCPU and 4 GB RAM, sustained 100 concurrent conversations "with no measurable regression in time-to-first-token". The authors attribute this to an async, I/O-bound streaming pipeline, so you scale by adding replicas rather than using bigger machines.

How it works

flowchart LR
    dify["Dify DSL .yml"] --> tx["wf_code_generator.py"] --> wf["BaseWorkflow subclass"]
    code["agent_kit agent"] --> wf
    req["POST + Bearer"] --> auth["auth_validator: token → Workflow"] --> wf
    wf --> proc["StreamProcessor"] --> ad{"DataAdapter"}
    ad --> d1["Dify SSE"]
    ad --> d2["OpenAI SSE"]
    ad --> d3["custom"]

• Routing: each Bearer token maps to one registered Workflow instance in goalflow/api/auth_validator.py, so the token itself selects which workflow runs.
• Transpiler output: the transpiler emits class YourWorkflow(BaseWorkflow[BaseState]), which wraps a LangGraph StateGraph and exposes execute(), stream() and resume(). resume() is the human-in-the-loop path.
• Cancellation: /stop is implemented by having the generate services poll a stop flag in Redis.
• Storage split: Redis holds hot messages, conversation variables and stop flags. MySQL holds durable messages, HITL reviews and conversation variables.
• Endpoints: /v1/chat-messages, /v1/workflows/run, /v1/*/suggested and /stop, plus HITL and report endpoints.

How to use it

You need Python 3.12, Redis (cluster or standalone) and MySQL.

git clone <your-repo-url>
cd goalflow
cp .env.example .env          # then fill in real values
# editable install — puts the `goalflow` package on your path
pip install -e .
goalflow-server                   # serves on http://localhost:8000
# or, without installing:  python start_server.py

• Layout: the repo uses a src/ layout. Imports are goalflow.* (e.g. from goalflow.node import LLMNode) and agent_kit.*.
• Dependencies: there are no git submodules, and a Dockerfile ships with the repo.
• Skills: these are SKILL.md data files under skills/.
• Docs: the transpiler, custom data adapters and agent nodes each have tutorials under docs/.

Limits

• Leaked credentials: the README carries an explicit warning that real credentials are still in git history and must be scrubbed with git filter-repo and rotated. Treat any clone as containing leaked secrets. Do not publish a fork without following docs/security-and-open-sourcing.md.
• Internal URLs: internal service URLs are still hard-coded in a few places.
• Vendor defaults: the code was extracted from an internal system and leans toward Alibaba Cloud OSS and Qwen/DashScope defaults. The authors say the reusable core is the node library, the Dify transpiler, the adapter abstraction and agent_kit. Expect to replace the rest.
• Infrastructure: Redis and MySQL are both required. MySQL is slated to be replaced by Elasticsearch for durable message storage, so the persistence layer may change.
• Visual editors: only Dify is supported for now. Support for other builders is listed as planned.
• Licence: MIT. The vendored agent_kit is relicensed under MIT as part of the project; check src/agent_kit/NOTICE.md if its provenance matters to you.
• Load test scope: the result gives no model, prompt length or test methodology, and no throughput figure beyond the 100 concurrent conversations.