PRODUCT_02 FLOWBASE IN_BUILD
One inbox. Judged, routed, and mostly handled.
FlowBase classifies everything that arrives, has a second model check the first one’s work, and acts only when confidence clears the threshold set for that kind of message. Everything else lands in a review queue with its full reasoning attached.
What it does, and where each part stands
-
Signed webhook intake shipped
A signed inbound webhook creates an event and runs the pipeline in-process, no queue required to get started. Redelivering the same message returns 202 duplicate and creates nothing.
-
Confidence routing shipped
One score decides: auto-execute, human review, or escalate. Thresholds are set per workflow, and a threshold of 1.00 means never auto-execute, which is how legal workflows ship.
-
A second model checks the first shipped
A judge reviews the classification before anything runs and returns an adjusted confidence, which is the number the router acts on. Its verdict, confidence and notes are stored on every decision, so you can read why, months later.
-
Review queue shipped
Approve fires the action. Modify overrides the category, priority or draft and stores the correction. Reject fires nothing. Keyboard-first, because it is a queue someone works.
-
Thirteen composable steps shipped
Classify, judge, draft, extract, normalize, route, deduplicate, summarize, translate, enrich, match and more, assembled per workflow rather than hard-coded into one.
-
Failure paths shipped
A classification that fails lands in the review queue as a failure (the error, the step that failed and the original message attached), so nothing that arrives is silently dropped.
This is probably you
- A shared inbox gets triaged by hand every morning before anyone starts working.
- Most of what arrives is routine, and the exceptions are the only ones that matter.
- A wrong automatic reply costs enough that nobody trusts a rules engine with it.
- You want the easy ones handled and the rest handed over with the reasoning attached.
Shapes it has been configured into
Wrappers of the same engine, not separate products. Where a line carries a figure, the figure is a design target from the scenario named beside it, not a customer result.
- INBOX TRIAGE Your inbox triages itself, and the hard ones reach a person with the reasoning attached. DESIGN TARGET · email-triage scenario
- INVOICE INTAKE Invoice data extracted, matched to POs, and queued for approval. Automatically.
- LEAD ROUTING Every inbound lead scored and routed before your sales team opens Slack.
- TICKET TRIAGE Support tickets classified and drafted on arrival. Urgent ones skip the queue.
Two numbers we measured. Two we are aiming at.
Measured figures name the run that produced them and come from a review packet in the product’s own repository. Design targets name the scenario they belong to. There is no third kind of number on this page.
What it costs
Set on the assessment call.
FlowBase is in build, so the conversation is about what your workflow needs and when it is ready, not a number we would have to revise once we know.
What we will not claim
In build means intake, idempotent redelivery and the failure path have run on a live stack: a classification that fails reaches the review queue as a failure rather than disappearing, and approving a queued decision fires its action through a real connector. The model steps have not completed on a live stack, because no model key has been provided, so no golden run has been scored and there is no measured accuracy. Also left: a drafted reply is not yet sent back to the person who wrote, webhook subscriptions are stored but not yet delivered, and FlowBase does not call AskBase or WatchBase.
Thirty minutes tells you whether FlowBase fits.
A fixed agenda, a one-page map back within two business days, and no pitch. If FlowBase is the wrong tool for your problem, that is what the map will say.
Book Free Assessment