For AI agents Autonomous execution

Set targets. Let the agent execute in order.

Give an agent a flat prompt and it improvises the order. Give it a Flowral flow through MCP, and it only ever sees the target that is actually unblocked: it starts it, finishes it, and the next one unlocks itself. No re-prompting, no working ahead of a dependency that isn't done yet.

Start free Connect an agent

✦ Same permissions as the person who connects it · No separate agent identity to manage · MCP connector live today

Agent session · via MCP

work_available()
→ "Add keyboard-accessible fallback" (ready)
   needs: nothing outstanding

item_start("Add keyboard-accessible fallback")
→ picked up (assigned to you)

… agent does the work …

item_complete("Add keyboard-accessible fallback")
→ done, unlocked: "QA across template list views"

work_available()
→ "QA across template list views" (ready)

Ready → in progress → done (nothing skips a state) · Completing checks prerequisites and required deliverables first · Works with Claude, Claude Code, Cursor and any MCP client

Where agent execution breaks down

A prompt has no memory of order

🎯

Targets, not tasks

An objective is only visible to the agent once everything it depends on is actually done.

🔁

No context to rebuild

State lives in the graph, not the chat. A new session picks up exactly where the last one left off.

🔒

Order that actually holds

Dependencies gate readiness structurally: an agent can't start what hasn't unlocked yet.

🧾

A record of what happened

Every start, comment and completion lands in the same activity trail a teammate would leave.

How it runs

Set the graph once. The agent works it end to end.

You define the targets and what blocks what. The agent asks what's ready, does it, and asks again.

The agent only ever sees what's unblocked

Mixed human and agent work in the same flow, moving in the order the dependencies actually require.

✓ Ready means ready. "What's next" only returns work with nothing outstanding in front of it.
✓ Completing unlocks automatically. No separate step to check dependents and open the next one.
✓ State persists between runs. A new session, or a different agent entirely, picks up exactly where the graph says work stands.
✓ Comments carry context forward. The agent leaves a note on what it did and why, for the next run or the next person.

✓Design double-click interactionUI · doneJS

✓Implement double-click handlerdoneAI

▸Handle multi-select edge caseready · in progressAI

🔒Add keyboard fallbackblocked · needs edge case

🔒QA across template viewsblocked · needs 2 more

Before it's a target

Decide what's worth automating, first

Not every repetitive task is a good fit for an agent, and that's a conversation worth having before anything becomes a target. Brainstorms give your team an open canvas for exactly that.

One team mapped it as a Brainstorm: what they redo every week, what's a good fit for an agent, and what needs a human, full stop. No targets, no MCP, just a plain conversation about where the effort actually goes, tagged and assigned before any of it became a flow.

See how Brainstorms work →

The tools an agent uses

The same graph, read and moved through MCP

Not a separate agent API. The same flows your team already sees, exposed as tools an assistant can call.

🟢

work_available / work_mine / work_blocked

What's actually ready right now, across every flow or one, ranked by what's on the critical path.

▶️

item_start / item_complete

Ready → in progress → done. Completing checks the prerequisites and required deliverables first, then reports what it unblocked.

🔗

objective_add / subtask_add / dependency_add

Extend the graph itself: add a new target and wire in what it depends on, from inside the conversation.

💬

item_comment

Leave the trail: what changed, why, and what's still open, for the next run or for a teammate.

Accountability

The agent acts as you, under your role

There's no separate agent identity to provision or audit. MCP signs in as the person who connected it, through Flowral's own login, and every action (starting a target, completing it, leaving a comment) is attributed to that person and bound by their role. An agent with viewer access can comment; it can't complete work it isn't allowed to touch. Dependencies still hold either way: an agent can't finish what a human couldn't.

Deciding what to build against	A flat prompt / checklist	A Flowral target
Order	left to the agent's judgement	enforced by prerequisites
State between runs	re-explained each time	held in the graph
What's next	you decide, every time	`work_available` answers it
Record of what happened	scattered across chat logs	one activity trail, per task
Who's accountable	unclear	the person who connected the agent

Agent questions, answered

Does the agent get its own account?

No. It signs in through Flowral's own login as the person who connected it, and acts under that person's role, just as if they had made the change themselves.

Can an agent complete work a human hasn't approved?

Only if its role allows it. Required deliverables and prerequisites are checked the same way for an MCP-driven completion as for a click in the app.

How is this different from just prompting the agent with a checklist?

A checklist has no memory of state and no structural order: the agent has to be told what's next every time. A Flowral flow computes what's actually ready, remembers it between sessions, and unlocks the next target the moment the one before it finishes.

Which agents does this work with?

Any MCP-capable client: Claude, Claude Code, Cursor, ChatGPT and the enterprise agent platforms listed on the AI and MCP page. Connect once and it's available the same way to every one of them.

Is this a different product from the REST API?

No. Same data, same permission model, same flows. MCP is one more way in, built for a conversational agent instead of code you host yourself.

Building software instead of running an agent? See the REST API.