The workflow engine
is now an agent.
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, pauses 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.
Two chats, one workflow: designed with the agent, then run in its own session — forms and approvals included.
ITSM workflows, reimagined
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.
The ticket pipeline
Process as software: repeatable, but rigid — fixed forms, fixed states, humans as glue.
- Fill in the formOne field wrong and it bounces back.
- Wait in the queueYour request is #14 in line.
- Hand off between teamsContext is lost at every hop.
- Chase the status“Any update on my ticket?”
The AI chat session
Process as improvisation: flexible, but never the same twice.
- Ask the agent in chatNo form, any wording.
- The agent plans and actsA fresh plan every time — and a slightly different one.
- No gate for an approverWhoever is chatting decides. Nobody else sees it.
- Session over, plan goneThe next request starts from zero.
The chat-driven workflow
An SOP you run together with the AI: as flexible as a chat, as repeatable as a procedure.
- Describe the intent in chatNo form. The Skill knows what to ask.
- The plan is kept as a workflowThe task graph the agent drafted from the Skill — published once, run as often as needed.
- Humans approve the moments that matterPublishing the design, and every tool call that changes something.
- The agent executes and verifiesLive progress in the same conversation.
SKILL.md file in a Git repository — versioned, reviewable, and readable by anyone on the team.Plan. Approve. Execute.
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.
The agent turns intent into a task graph
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.
Humans gate the moments that matter
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.
The agent walks the graph
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.
Three roles, one conversation
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?”
The applicant
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.
The approver
Gets a notification, opens the session, and decides right in the chat — with a comment. Only the designated approver can resolve an approval.
The agent
Plans the task graph, requests approvals at the right moments, executes each step per the Skill, and reports progress as it goes.
Notifications that carry you to the decision
Approval requests and session completions land in each user's notification bell and deep-link straight into the relevant conversation.
An audit trail on every approval
Who approved, what they wrote, and exactly when — persisted on the approval record and browsable in the admin console.
Everything a workflow needs, nothing it doesn't
Agent Skills in Git
Procedures live as SKILL.md files in Git repositories, cloned on first run. Version them, review them, read them — like any other code.
A plan you can run again
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.
Approval gates mid-run
Before a destructive step, the agent requests approval from a specific user and pauses. Approve / Reject / Return buttons appear in the chat — for that user only.
MCP tools, scoped per task
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.
Rich UI inside the chat
Through the A2UI protocol the agent renders buttons, forms, and cards inline — and your clicks flow back into the run as tool results.
Bring your own LLM
Gemini by default; OpenAI and Anthropic models via LiteLLM. Swapping providers is one environment variable.
An open-protocol stack
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.
Run it on your machine
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