Flow: capturing the real process into software the team works in

The process that runs the company has no home

Ask your head of operations to show you how employee onboarding works, and you won't get a screen. You'll get a monologue. Offer accepted, then someone in people ops creates the record, IT provisions the accounts and orders the laptop, the hiring manager preps the team, and somewhere in there the new hire fills out three forms nobody remembers the names of. It mostly works because one or two people carry the whole shape of it in their heads. When they're on vacation, it doesn't.

The usual fix is to write it all down, and that fix helps the auditors while failing the team. Nobody works in a document, so the real process forks away from it silently, and within a few months the doc describes a company that no longer exists. Our position with Flow is the one in the title: capture the process into software the team works in, not a document that goes stale the day it's written. What makes that possible now is a change in what a step can be. Once a step can be completed by an agent rather than merely described for a person, the diagram itself can run the work.

To be plain about what Flow is: a design-sprint prototype, with interactive screens you can open and sample names and numbers on them, and no shipped product or customer behind it. We've made the broader argument before: the largest share of how work really gets done has never been captured anywhere an agent, or a new hire, can use. First we show the capture, then the dial that hands steps to agents one at a time, then the exceptions that make handing a step over safe at all.

Capture by talking, and nothing saves until a person approves

The prototype's primary action, top-right, is Capture, and the interaction is deliberately low-ceremony: you talk. "Send a paragraph about onboarding," it prompts. You describe a step in plain speech, something like "on day one people ops verifies the I-9 in person before the new hire can be marked active." An agent drafts the pieces back: a step, the role that owns it, a control, and a memory note holding the gotcha. Nothing is saved until a person approves it on the canvas. The software's first job is to lift the process that already exists out of people's heads.

What the capture produces is the second decision. A task manager would flatten the process into an ordered queue and throw away the two things that make a process a process: who owns each part, and what runs in parallel. The screen instead renders the work as it actually behaves. Left to right, across role-owned swimlanes, grouped into the stages the team already names: trigger, prepare, day one, ramp, complete. The trigger is a real event, Offer accepted, with a note explaining that onboarding starts at signature because the two-week prep window is what makes day one work. Then the flow forks into three branches that run at once: IT provisions accounts and hardware, the hiring manager writes the 30/60/90 plan, people ops assigns a workspace and badge. Nobody waits in line, because in the real work they don't.

The structure underneath separates an owner from operators. The header states it plainly: eleven steps, owned by the head of operations, the person accountable for whether the process is correct, current, and improving. In most companies there is no screen anywhere that shows that person the thing they own. The operators are the swimlanes: people ops, IT, hiring manager, and the new hire, tagged an external party. That last lane carries more weight than it looks. Tools in this category typically model only employees, and a real onboarding process hands work to someone who doesn't even have an account yet. Putting the new hire on the board admits that the process crosses the company's boundary, so the picture has to cross too.

A dial on every step, and it turns both directions

The legend across the top reads Manual, Assisted, Automated, and every step wears one of the three. This small tag is where agentic AI actually enters the design. For thirty years, business software recorded work that humans did: open a form, type, click save. An agent changes the verb, because a step can now be a box an agent completes. So Flow puts the grant at the step: a dial you turn, one step at a time, and no whole-process switch anywhere on the screen.

The per-step grant is aimed at a documented failure. Teams resist "automate the process" because it's an all-or-nothing bet on a thing they can't fully see, and the record backs them: in Deloitte's 2018 global RPA survey, only 4% of organizations were operating more than 50 robots (3% the year before), and respondents named process fragmentation as the top barrier to scaling [1]. Tag each step independently and the conversation changes. In the prototype, "create employee record" and "provision accounts & hardware" run fully automated under an onboarding agent, because their rules are crisp and their mistakes are recoverable. "Send welcome packet" and the 30-day check-in are assisted: the agent drafts, a person reviews and sends. The 30/60/90 plan and the day-one welcome stay manual, because they're moments a human should still own.

The dial on every step. Three real steps from the prototype, one per position, and a flagged 'automation candidate' waiting on a human decision rather than a build.

The dial also turns both ways. Each step carries a small toggle: hand a step to an agent, or hand it back to a person. A manual step the system judges ready wears a quiet "automation candidate" marker and waits for the owner to decide, rather than switching itself over; the 30/60/90 plan wears exactly that marker in the shot. There's a coach, too. The header carries an AI insights affordance showing +26% (a sample figure in the demo, like every number on these screens). Open it and the suggestions are specific: send day-one paperwork before day one, auto-draft the ramp plan, trigger provisioning off the applicant system. They stay suggestions until the owner turns the dial.

The exceptions live in the step, in the open

Select a step and a detail panel opens. In the shot it's Provision accounts & hardware, tagged Automated · Onboarding Agent and marked a Sub-process: this one step is itself a whole flow, "device & access provisioning," owned by IT, where accounts get scoped to the position's access group under a least-privilege check and the kit ships three business days before the start date. Nesting a process inside a step keeps the top-level board readable while holding the full depth underneath. The panel opens on a plain-language "how the work is done" list, and a memory tab holds the reasoning behind the step.

Below that sits the part that earns the design its keep: Exceptions & escalations, spelled out in the step itself, where a runbook would have buried them. Three "IF" rules are in the open:

• Background check fails after provisioning: revoke all accounts immediately, don't wait for HR. Routed to the IT administrator.
• Hardware backordered more than five days: notify the manager and the hire, provision the accounts anyway, ship the kit later.
• Hire is a contractor rather than an employee: hold SSO until the background check clears; the agent parks the account in "requested" and a person releases it by hand.

Each of those is a piece of institutional judgment that normally lives nowhere. The "don't wait for HR" clause is a lesson someone learned the expensive way. The contractor rule is the edge case that quietly breaks onboarding at companies that haven't written it down. And this is the condition for trusting an agent with a step at all: the step has to say, out loud, what to do when reality bites and who gets the escalation.

One owner per process, one lane per step, one named escalation

The most delicate design problem was the hand-off. Work crosses from people ops to IT to the hiring manager and out to the new hire, and each crossing is a place where things get dropped. Swimlanes make the hand-off literal, but the design still has to decide who owns a step versus who merely touches it. The answer here is explicit and singular: one owner for the process, each step in exactly one lane, each exception naming exactly one role to escalate to. A lane also carries standing directives of what its role must, should, may, and must not do. IT, for one, must scope every account to the position's access group and must not release SSO before a contractor's check clears. Ambiguous ownership is how processes rot, and how agents cause damage, so the design refuses to allow it.

What the design deliberately holds back

The software is also held back from getting ahead of its user's trust. Nothing captured is saved until a person approves it, every automated step is reversible with one click, and where a step needs real judgment an agent recommends without deciding: after the 30-day check-in, a "next best action" step reads the ramp signals and proposes one of three routes (close onboarding, open a growth plan, schedule coaching), and a person confirms before any route is taken. Once agents complete steps, the owner's day on this board is supervision: approving captures, setting each dial, catching the named escalations. That is Flow's slice of the inversion our fourteen-prototype essay walks in full.

What a generic tool can't carry

A fair objection: swimlanes and status tags are commodity, and a dozen workflow tools draw them. They do. What a generic tool can't carry is the "contractor, hold SSO until the background check clears" rule, because that rule belongs to one company and no other. The value is that the lanes hold this company's eleven steps, these four roles, that specific escalation. Invoice approval, customer onboarding, and incident response would sit beside it, each with its own hard-won exceptions. Fidelity like that only happens when the software is shaped to one organization's real process, which is the case we make in full in the bespoke SaaS post.

There's a payoff one step further on, too. A step captured this faithfully, owner and rules and exceptions included, is exactly the kind of work an agent can take on with confidence.

If your own critical processes live in someone's head today, start with the capture question: what it would take to get yours onto a screen your team recognizes as true.

References

[1] Deloitte, "The robots are ready. Are you?" (global RPA survey, 2018): 4% of organizations operating more than 50 robots, up from 3% in 2017; process fragmentation named the top barrier to scaling.