A2Flow is a chat-driven workflow engine. It rebuilds ITSM-style workflows — service requests, change execution, announcements — around an AI agent: it plans the work as a task graph, s for the humans who must sign off, and executes the rest. The plan is kept as a workflow, so the next run follows the same steps.
Classic workflow engines are repeatable but rigid: fixed forms, ticket queues, handoffs between people, and mostly waiting. A chat with an AI agent is the opposite: flexible, but the plan it made is gone when the session ends, and nobody signed off on it. A2Flow keeps the procedure and the approvals from the first, the conversation from the second, and hands everything in between to the agent.
Process as software: repeatable, but rigid — fixed forms, fixed states, humans as glue.
Process as improvisation: flexible, but never the same twice.
An SOP you run together with the AI: as flexible as a chat, as repeatable as a procedure.
SKILL.md file in a Git repository
Every run passes the same two gates: nothing runs until a human has published the design, and no tool call that changes something goes through until the designated approver has said yes.
In a design session it reads the Agent Skill, breaks your prompt into task templates with explicit dependencies, and registers the whole DAG in one call — cycle detection included. Adjust it by chat or by hand; nothing runs yet.
Publishing the workflow is the approval of the plan — a run starts from it with nothing to confirm. Tool calls that change something gate on a designated approver: Approve / Reject / Return controls render right in the chat, listing exactly the calls they authorize, and only that person can resolve them — anyone else gets a 403.
Press Run and the agent starts at once in the run's own workflow session. Tasks move pending → in_progress → completed in dependency order, calling only the MCP tools bound to the current task, and the agent asks its questions through forms drawn right into the chat.
A workflow session is a shared chat. The applicant, the approver, and the agent all post into the same thread — no side channels, no “any update on my ticket?”
Runs a published workflow. Answers the agent's questions — in the forms it draws into the chat — and watches the tasks progress in the same thread.
Gets a notification, opens the session, and decides right in the chat — with a comment. Only the designated approver can resolve an approval.
Plans the task graph, requests approvals at the right moments, executes each step per the Skill, and reports progress as it goes.
Approval requests and session completions land in each user's notification bell and deep-link straight into the relevant conversation.
Who approved, what they wrote, and exactly when — persisted on the approval record and browsable in the admin console.
Procedures live as SKILL.md files in Git repositories, cloned on first run. Version them, review them, read them — like any other code.
The task graph the agent drafts from a Skill is published as a workflow — a real DAG, dependencies enforced, cycles rejected — and every run walks the same graph, rendered as a sortable table or an auto-laid-out graph that updates as the agent works.
Before a destructive step, the agent requests approval from a specific user and s. Approve / Reject / Return buttons appear in the chat — for that user only.
Register MCP servers, and the agent binds only the tools each task needs at plan time. At run time, a task can call nothing but its own tools — and every server A2Flow starts runs in its own bubblewrap sandbox.
Through the A2UI protocol the agent renders buttons, forms, and cards inline — and your clicks flow back into the run as tool results.
Gemini by default; OpenAI and Anthropic models via LiteLLM. Swapping providers is one environment variable.
The chat UI streams AG-UI events from a FastAPI backend, and the agent draws A2UI surfaces into the chat. Agent Skills come from Git, tools come from MCP servers, and one relational database holds it all.
The whole stack — PostgreSQL, backend, frontend — comes up with Docker Compose. Bring a Google API key and you're two commands away from your first workflow.
$ git clone https://github.com/kaitoy/a2flow.git && cd a2flow$ echo GOOGLE_API_KEY=your_google_api_key_here > .env$ docker compose up --build# open http://localhost:3000