How it fits together
FlowLakes gives AI one job: apply judgment at machine scale so human attention is spent only where it matters. The platform breaks that into a few purpose-built pieces — judgments decide (shown as Decisions in the admin UI), investigators explain, work items handle ad-hoc instructions, and agents are the governed identities that do the working. Whatever produces a change, every write converges on the same path: a reviewable proposal, a human approval, a deterministic and audited apply. One review experience, one audit trail, one set of permission dials, no matter which AI did the thinking.
The map
Which piece does what
| You want | Reach for | A workflow? |
|---|---|---|
| ”When X happens, decide or fill a value” | a judgment on a trigger | no |
| ”Why is this happening?“ | an investigator agent | no |
| ”Go do X across these records” (one-off) | a work item to an operator agent | no |
| A fixed multi-step procedure | a workflow, as always | yes, that is the workflow |
| ”Keep this outcome true, continuously” | a judgment with a reconcile schedule | no |
Your existing propose-mode agents keep working unchanged; they are the standing per-record workers, and their proposals ride the same write path as everything above.
Where the chat assistant sits
The Flow chat is not a separate AI. It calls the same tool registry as the admin pages, which gives it three roles: it is the front door for creating things (describe the judgment or work item you want; the draft is validated and created only when you confirm), it is your counterpart at review moments (ask “why did it choose P3?” against the stored rationale, or dispatch an investigator and get the finding back in the conversation), and it provides MCP parity — an external AI holding a FlowLakes identity gets exactly the same tools with the same fail-closed permissions. Chat can never become a side door: reads answer immediately, but every mutation goes through the same confirmation, validators, and approvals as any other caller.
Good to know
- The compounding loop is the payoff. Recurring instructions graduate into standing judgments; every human correction in the review queue is captured as an eval case; the crystallizer uses those to draft improved versions (which cannot activate without passing their eval) and, where the pattern is pure repetition, proposes a plain business rule that removes the AI from that path entirely. Cost per decision falls over time while accuracy rises from your own corrections.
- Three control dials, none touching the model’s reasoning: what the AI can read (its service account’s permissions), what it can propose (output contracts and step-kind allow-lists), and who approves (approval policies and default approvers).
- Failures are honest. An AI that cannot read a table says so in a finding; it does not invent data. A run that produces no deliverable is marked failed with the underlying cause, never quietly “completed”.
How it connects
- Now do it: Judgments for the decision primitive, Work items for ad-hoc instructions, Agents for identities and autonomy modes.
- The write path in detail: Plans and governance.
- The security posture behind all of it: Safety model.