Every customer is a developer. Every workflow has agents.
There are two places AI lives in flow. One is the build tooling — the same one our engineers use — opened up to every tenant and partner, so that any technological need the business has can be met inside the platform. The other is a set of focused agents that work inside the platform's processes, under written policy, with a person one step away.
The build tooling isn't reserved for us.
flow is developed with an AI engineering workflow: a natural-language interface over the platform's code base, components, tests and deployment gates. Every tenant gets that same workflow, scoped to their environment. What a customer or partner describes — a screen, a report, a whole process, an integration — becomes real software in the platform, versioned, tested, reviewed and deployed, not configuration in a no-code layer beside it. It's the reason one platform can aim to cover every technological need of a business: what isn't there yet is built, not bought.
A procurement lead asks
What people build
flow builds it
- Read the request; map to
suppliers.documents,procurement.dashboard - Generate the report query, screen and permission rules
- Add automation: expiry − 14d → WhatsApp template to supplier contact
- Run the tenant's test suite and policy checks
- Review gate → deploy to tenant · version 1.0 · rollback ready
| Supplier | Document | Expires | Reminder |
|---|---|---|---|
| Atlas Components | ISO 9001 | 14 Dec | 30 Nov · scheduled |
| Nir Transport | Insurance certificate | 3 Oct | 19 Sep · scheduled |
| Segev Packaging | Tax withholding | 30 Sep | sent · read |
How it stays safe
- Every build runs in the tenant's boundary with the tenant's permissions — it cannot see or touch another tenant
- Generated code goes through the platform's automated tests and policy checks before a review gate
- Versioned deployments with instant rollback; changes are attributed to the person who asked
- Data-access rules and audit are the platform's, not the generated code's, to decide
Who uses it
- Operations leads who used to file tickets with IT and wait a quarter
- Solution partners who deliver a bank's or insurer's specific workflows on flow
- Platform partners who package capabilities and ship them to hundreds of tenants
- Our own team — it is the same tool; customers are not on a lesser track
What it changes commercially
- No change-request backlog and no custom-development quotes for routine needs
- Partners keep the margin on the capabilities they build and resell
- Roadmap independence: what your deployment needs isn't gated on our priorities
- Transparent, usage-based AI cost — no per-feature licensing
Requests that became product — in hours, not quarters.
“Show clients who haven't sent documents this month, with a WhatsApp reminder button.”
Became a screen with per-client completeness, owner assignment and a one-click templated reminder. Now shipped as a standard capability to every firm on the platform.
“After a claim is opened, ask for photos, run them through our damage-estimate API and book a garage from our approved list.”
Became an agent skill calling the partner's own component, with a handover rule when the estimate crosses a threshold.
“When a customer reports an outage, check the line, push a remote reset, and only then offer a technician slot.”
Became a service-agent flow using the operator's OSS API as a tool — with technician scheduling from the field-service system.
“Let suppliers ask about invoice and payment status on WhatsApp without calling accounts payable.”
Became a supplier-desk agent with read-only ERP access, plus a weekly report of what suppliers asked and where the ERP had no answer.
Focused agents, one job each, inside the system of record.
We don't run one general assistant that tries to do everything. Each agent has a job, a set of tools (components and records it may use), a policy, and a place in the workflow. That's what makes them explainable to an auditor, testable by an engineer and trustworthy to the person who inherits their work.
Identity
Chooses and runs the verification level a request needs: OTP, document + liveness, voice, device signals, or none.
Service
Answers from policy and the record; opens cases, books, changes, cancels, explains — and cites its source.
Transaction
Executes in core systems within limits: transfers, refunds, plan changes, orders, claims. Logs every call.
Risk
Scores requests with fraud and risk components, challenges anomalies, freezes and escalates.
Collections
Reminds, offers options within policy, reschedules, and hands hardship cases to a person.
Scheduling
Books, moves and confirms across calendars, field-service systems and clinic schedules.
Documents
Requests, receives, classifies, extracts, and asks again when something is missing or unreadable.
Co-pilot
Prepares the summary, the draft and the next action for the human taking over. The 90%.
Supplier
Answers status questions from the ERP, collects documents, routes quotes and invoices.
Workforce
Handles HR self-service, shifts, approvals and policy questions on the employee desk.
Supervisor
Reviews samples of agent and human conversations against policy; flags drift and training needs.
Builder
The build tooling itself — turning a request into tested, reviewed capability inside the tenant.
What an agent may do is written down — per agent, segment and channel.
A policy card defines the tools an agent can call, the limits it operates within, the verification it requires, and what happens above the line. Policies are versioned and owned by the business, and the audit log records which version allowed each action.
- Limits by amount, frequency, customer segment, time of day and channel
- Verification level required per action, enforced by the identity agent
- Handover rules: to whom, with what context, and what the person can do
- Simulation mode: replay last month's conversations against a new policy before enabling it
- Kill switch per agent and per tenant
Model-agnostic by design. Your data stays yours.
Default: Claude from our cloud
Agents and build tooling run on Anthropic's Claude models served from flow's cloud. Usage is metered and shown per tenant; no per-feature licensing. Your data is not used to train models.
Bring your own contract
Enterprises route inference through their own model agreement — Claude, OpenAI or another provider — with data-class rules deciding what goes where. Policies, tools and audit stay in flow.
Inside your boundary
For regulated deployments, inference can run in a private cloud region or on infrastructure you control. Same agents, same policies, different network.
People's corrections are the training signal — not your customers' patience.
Every time a person edits a draft, rejects an action or answers something the agent couldn't, flow records the difference. Those differences turn into proposed policy and knowledge changes that the business reviews and enables — and into test cases that every future version has to pass.
- Shadow mode before go-live: the agent drafts, people send, accuracy is measured
- Golden test sets per tenant, run on every policy and model change
- Supervisor agent samples conversations against policy and tone guidelines
- Containment, approval and edit rates reported per agent and per segment
About the AI in flow
Can customer-built code break the platform?
Can an agent hallucinate a transaction?
How do you keep the agent from answering outside policy?
Do you train on our data?
What languages do agents work in?
Bring a workflow. Leave with an agent running it.
In a working session we take one of your real processes, write its policy card, connect the components, and show the agent, the handover and the audit log.