useflower.dev

How it works

What flower does with a piece of work, from the agent session where it starts to the commit running on your live site.

  1. 01

    Every agent session is kept and searchable.

    flower reads the full transcript of every Claude Code, Codex and Pi session and indexes it with your commits and docs. An agent can ask where the last session stopped, or why a file was changed before.

  2. 02

    Work starts as a brief.

    You or your agent writes a brief: the spec, how to tell it is done, and a timeline of its questions, reviews and lands. Bigger work is an epic: child briefs built in order.

  3. 03

    Each brief is built in a throwaway container.

    An agent works on the brief's own branch, so several briefs build at once without sharing a checkout. A correction sent mid-build reaches it within about a minute.

  4. 04

    Your checks run, then a model from a different lab reviews it.

    The checks the project declares, such as its tests, lint and build, run in a clean container before the change is reviewed. A model from a different lab then passes it or sends it back with findings, and the checks run again on the merged result before it lands.

  5. 05

    It lands, ships and deploys, then flower checks the live site.

    It lands on the project's branch, ships to your deploy branch and deploys; each project chooses whether shipping waits for a person. flower then checks the live site is healthy and running the commit it shipped.

Every record is linked to the ones around it.

A brief is linked to the sessions, builds, reviews, checks, decisions and deploys around it, and to earlier work on the same topic. An agent picking up a brief gets all of that at once, and a deployed commit can be followed back to why it exists.

Agents message each other, and ask to be told when something changes.

Agents have mailboxes and shared channels, so one can hand work or a warning to another without a person passing it on. An agent can ask to be told when a build finishes, a check fails or a deadline passes.

Decisions reach you as a question with a recommendation.

It shows up in flower's web UI and in the session, and only that piece of work waits for you. You can also follow a change from brief to live site in the browser.

Some rules apply at every step.

  • Permissions: each agent can call only the tools its job needs. Anything beyond that needs a permission a person approves for a set time.
  • Secrets: credentials stay on the server, and a build is handed only what its steps need.
  • Standards: rule sets that read a change and report on it or block it.
  • Alerts: failed checks, failed deploys and stuck work are flagged without anyone asking.

Where to read more

Read the principles, see where it runs, or what flower connects to. flower is built on a set of tools called polystrate.