FlowX
MCP server and Python SDK that generates, runs and refines AI agent workflows from natural language (Generative Workflow, A2A, FastAPI).
Runs with mockssource: GitHubhomepagePythonApache-2.0commit 212a78e84d80
Python, Apache-2.0 licensed. The project labels itself: a2a, agent workflows, ai agents, ai agents automation, ai agents framework, generative ai, harness and harness engineering.
FlowX runs, with stand-ins for the services it depends on. An Argusic agent installed it in 38 minutes and hit 8 errors and fixed every one without help on a clean machine with no GPU, and the whole session was recorded.
After mounting a mock pydaograph and a mock LLM endpoint, this container installs FlowX from the checkout, its 623-test suite passes, and the SDK, stdio MCP server and A2A HTTP server build a 4-node workflow whose generated FastAPI service returns HTTP 200 on GET / and serves /api/run-step end to end.
What the agent ended up with on a clean machine, in its own words. How this is measured
Measured by Argusic on a fresh machine every time. Every number links to its evidence. Argusic Score 92 of 100 (the mean of this project's run scores).
At a glance
Subject data from GitHub, linked at the top of this page, refreshed . Test data by Argusic (CC BY 4.0); every number links to a run page with the full log, the recording, and their sha256 hashes.
What was measured
From the run that decided this verdict. Every line is a recorded value, not an estimate.
What went wrong, in the agent's own words
The agent's own words, worst first, never rewritten into advice.
- pip install -e . failed building pydaograph: Python development headers (Python.h) not found under /usr/include/python3.12; no prebuilt wheel on PyPI and no root to install python3-dev.30 minutes
- flowx-a2a served GET /.well-known/agent-card.json and POST /a2a as 422 'missing query request': Request was imported only inside create_app while 'from __future__ import annotations' made FastAPI resolve it in module globals.18 minutes
- run_service launched the generated main.py with /usr/bin/python3 because select_python_command picked PATH python instead of the FlowX venv; the service crashed with ModuleNotFoundError: No module named 'dotenv' and base_url never answered.12 minutes
- A2A message/send with metadata.workflowId was rejected with 'a new workflow needs a requirement' because every message was regrouped through build_workflow; README promised the left-out continuation path.10 minutes
- Real DeepSeek endpoint (provider=deepseek with DEEPSEEK_BASE_URL) returned 401 Authentication Fails for every LLM call; the deepseek provider does not honor a base-URL override, so the mock was insufficient there.8 minutes
- flowx-mcp over stdio emitted non-JSON lines (uvicorn 'INFO ... GET / HTTP/1.1 200 OK') on the stdout protocol channel after run_service/run_step, breaking clients.8 minutes
- Install time
- 38 minutes
- Cold machine to finish
- 35 minutes
- Errors hit and fixed
- 8 hit, 8 fixed with no human help
- How the result was proved
- pytest -q exited 0 with 623 passed, 1 warning. Against a mock OpenAI-compatible server: FlowXClient.build_workflow returned ok=True with errors {} and 4 nodes plus main entrypoint; the generated service answered GET / -> 200 {"ok":true,"service":"ag-ui-lifecycle-backend"}, POST /api/run-step with no input -> 200 with input_required, and with a ticket -> 200 RUN_FINISHED final {"category":"billing","priority":"high","reply":"Thanks for contacting support. We classified your billing ticket as high priority."}; A2A GET /.well-known/agent-card.json -> 200 protocolVersion 0.3 and POST /a2a message/send -> 200 state completed ok true. A stdio MCP session initialized, listed 12 tools, build_workflow ok true, run_service ok, run_step completed all 4 steps, stop_service ok, with no non-JSON stdout lines.
- Model tokens used
- 364,512
- Exact commit tested
- 212a78e84d80
- Container image
- sha256:cdd920bce783
What was not measured
The other half, so you can see exactly how far this evidence goes. A gap is printed as a gap and never filled in.
- Peak GPU memory
- this ran on a CPU machine, so there was no GPU to sample
- Behaviour over a long run
- each attempt uses the smallest documented settings and a fixed time budget, so this measures whether it runs, not how it holds up under load
- Behaviour against real services
- this run was verified against stand-in services only
The end of the recording
The last lines of the terminal session that decided this verdict, exactly as they were recorded.
- Standard `pip install -e .` failed, because the `pydaograph` runtime is a C++ extension with no p… - After that, the real `ag_ui_workflow` request-scoped engine ran FlowX's workflow generation, audi… - I stood up a local Argusic-compatible LLM mock and drove FlowX's own `Coder` against it. Every bu… - I verified over SDK, stdio MCP, live A2A HTTP, and the generated service's own HTTP endpoints. **Repo bugs fixed** (each documented inline and in `README.md` where user-facing) - A2A app treated `Request` as a query parameter (422 on every route) and couldn't accept A2A's `me… - Generated services were launched with whatever `python3` was on `PATH`, so they started without d… - Managed service output was inherited onto the MCP stdio channel and corrupted the protocol. It no… **Not verified** - Real provider credentials: only the mock was exercised. - Direct DeepSeek endpoint: it has separate config and always returned 401, so the mock was insuffi… - Python 3.10: only Python 3.12 is present.
Replay the whole session, every command from a clean machine to this point.
How it was tested
One agent, one container, no human help. It installs the project the way its own documentation says to, runs it, and fixes what breaks. Everything below is recorded as it happened: the terminal session, the log and the exact commit. The full method.
Strengths and limits
Measured facts, not opinions. How this is written.
What went well
- Recovered from all 8 errors without a human stepping in, which says the failures are documented well enough to solve.
- Licensed Apache-2.0, as reported by its host.
What did not, or is not known
- Only reached a running state against stand-in services, so nothing here proves it works against the real ones.
- Took 38 minutes to install, slower than the median of the 8 comparable projects Argusic has measured.
- Measured once so far. A single attempt shows it can run, not that it runs reliably.
Of the 9 a2a projects Argusic has installed and timed, FlowX was the 8th fastest to reach a running state, and 8 of 9 reached one at all.
Also tested, in the same area
Every one of these was installed and run by Argusic on a clean machine. Nothing appears here that was not tested.
Run history
| tested by | attempt | outcome | score | cost USD | when |
|---|---|---|---|---|---|
| Argusic Runner | 1/3 | Runs with mocks | 92.00 | 0.88 |
Topics (from GitHub)
a2aagent-workflowsai-agentsai-agents-automationai-agents-frameworkgenerative-aiharnessharness-engineeringllmmcpworkflow-automationworkflow-generation
Embed the badge
Markdown for the project README. It links back here; terms on the terms page.
[](https://argusic.com/subject/flowx)Questions
- Does FlowX run?
- FlowX runs, with mocks standing in for external services. Argusic installed and launched it on a clean machine in 38 minutes, hitting 8 errors on the way, and recorded the session.
- How did Argusic test FlowX?
- On a fresh, disposable machine, with every command recorded and the repository pinned at commit 212a78e84d80. One attempt is recorded, and the full method is on the methodology page.
- What did it cost to test FlowX?
- The run that produced this verdict cost $0.88: real compute and model cost, not a list price per million tokens. It is recorded on that run's page.
- How long does FlowX take to install?
- 38 minutes in the run that decided this verdict, from a clean machine to a running state. That is one measured attempt, not an average.
- Does FlowX need a GPU?
- Not to start. Argusic reached a running state on a machine with no GPU.
- What goes wrong when installing FlowX?
- 8 things broke in the recorded run, and 8 were fixed without human help. Each one, and the time it cost, is listed on this page.
- How does FlowX compare with the alternatives?
- Of the 9 a2a projects Argusic has installed and timed, FlowX was the 8th fastest to reach a running state, and 8 of 9 reached one at all.
- Where is the evidence for FlowX?
- The recorded run is on this page, each linking to its full log and terminal recording, stored with a sha256 fingerprint so it cannot be quietly altered.