Explore Flowstate

The Flowstate platform
Flowstate Helm

Know what AI costs. See what you get back.

Understand spending, share budgets and connect AI use to the work it supports.

Recent insights All insights

Buy tokens, rent GPUs, or own the rack?

Open-weight models are now good enough to make self-hosting a financial question rather than a capability one. I modelled four options, an office rack, colocation, rented GPUs and per-token APIs, to find where each one actually wins. The answer turns on utilisation, and it isn't the one the internet keeps giving.

Turn a $3m AI bill into $1.9m

Most teams overpay for AI twice without noticing: they run everything through the default flagship model, and they buy the tokens on a metered plan they can't see into. An intelligent proxy fixes both. Here is the maths, a calculator you can drag, and where Flowstate fits.

Start with the work All use cases

Understand AI spending and value

See where the budget goes and what the business gets back.

Share one AI budget across your tools

Fund people, teams and projects across connected services.

Give your team more capacity

Reduce the preparation, checking and follow-up around recurring work.

Connect AI use to delivered work

Follow AI activity into projects, code and business results.
Quick links
Flowstate / People + AI Talk through your priorities
Documentation
Get help
Docs / Flowstate Sail

How an application works

A Flowstate Sail application is a workflow that does the work, the records it keeps, the systems it reads and writes, and the screens people use to check it. People who use the application never need to see the workflow. They see what it produces in Workforce.

flowchart LR
  T["Something starts it<br>a schedule, an event, a button"] --> S["Steps<br>rules · AI agents · code"]
  C["Connections<br>your systems"] --> S
  S --> P["A person decides"]
  P --> E["Effects<br>write to your systems"]
  E --> R["Data store<br>the records it keeps"]
  R --> V["Views in Workforce"]

An example

A monthly finance report could work like this:

  1. On the first working day of the month, the workflow starts.
  2. It reads actuals from your finance system and budgets from Flowstate.
  3. An agent drafts the commentary, and a judge checks the draft against your rules.
  4. The finance lead approves it from their Inbox.
  5. The workflow saves the figures to a data store, and the report view in Workforce shows them.

Drafts, versions and live

You change a workflow as a draft. Nothing you change in a draft affects the application people use.

When the draft is ready, you publish it. Publishing freezes it as a version that can’t change. You then deploy that version to an environment, such as a test environment or live. A live version can be paused or rolled back to an earlier one. See Publish and deploy a workflow.

Who a run acts as

A run acts as the person who deployed the version, so it can only do what they can. In a test environment, a run acts as the person who started it.

Every run is recorded

Each run keeps a record of every step: what went in, what came out, which rule fired, who decided and what it cost. See Follow a run and fix one that stopped.