How to Rebuild a Workflow Around the Model

If you want an AI-native product, you do not start with the model. You start with the workflow and rebuild it around the assumption that a capable model is always present. Most teams do this backwards. They take the existing workflow, find spots to insert AI, and call it native. That is bolting on with extra steps. Rebuilding a workflow around the model means asking what the whole job looks like when the tedious parts can be done by the model, then designing for that job. Here is how I actually do it.

Start from the job, not the current steps

Write down the job the user is trying to finish, in plain terms, ignoring how your current product does it. For a bookkeeper, the job is not "categorize transactions in a grid." The job is "produce accurate, defensible books." The grid is just how it is done today, and today assumes a human does every categorization.

Now ask what the job looks like if a model does the tedious middle. The bookkeeper's job becomes reviewing and confirming a set of decisions the model already made, with the odd ones flagged. That is a different workflow, not the old one plus AI. Starting from the job instead of the steps is the whole difference, and it is the practical form of designing a product around a model.

Find the steps the model can absorb

Walk through the current workflow and mark every step that is tedious, repetitive, or judgment the model can make. Those are the steps that disappear or collapse. In intake for a law firm, the model absorbs reading the case, checking eligibility, and drafting the first pass. Those steps do not get an AI assistant, they get removed from the human's plate entirely.

Be aggressive here. The instinct is to keep the human doing the step and let the AI help. That is bolt-on thinking. Native thinking asks whether the human needs to do the step at all, or just confirm the model did it. Most steps can move from "human does it" to "human reviews it," and that shift is where the leverage lives.

Decide where the human stays in the loop

Not every step should be automated away. Some decisions need a human, either because the stakes are high or because the model is not reliable enough there. Map those explicitly. The human stays in the loop where it matters, and the workflow routes those decisions to them clearly instead of making them babysit everything.

This is the part bolted-on products get wrong in both directions. They either trust the model everywhere or make you approve everything. Native workflows are deliberate about the confirm state of each decision, which is why human-in-the-loop is a data requirement, not a UI afterthought. Decide the loop points on purpose.

Put the deterministic gates where they count

Between the model's proposal and the committed result, put gates you actually trust. Validation rules, business logic, checks that catch the plausible-but-wrong output before it becomes real. The model proposes, the gate validates, then the system commits. Never let the model's guess touch production state without passing a gate.

This is what makes a native workflow reliable rather than just fast. The intelligence is probabilistic and the commit is not. That combination is the backbone of agent reliability. Decide which gates are strict and which are soft based on the stakes of each decision, and build them as real infrastructure, not as an apology after the first bad output.

Rebuild the interface to match

Once the workflow changed, the interface has to change with it. Screens that gathered input the model now gathers should shrink or disappear. Screens for reviewing and confirming model decisions should be the center of the experience. If your interface looks the same as before plus a panel, the workflow did not actually change and you bolted on after all.

When I rebuilt case management for CaseSolo, the screens are organized around reviewing decisions, not entering data, because the workflow moved the humans from doing to confirming. The interface is downstream of the workflow, and the workflow is downstream of the job. Get the job right, rebuild the workflow around the model, gate the commits, and the native product falls out of that. Start with the model and you get a wrapper. Start with the job and you get a product worth building around Girard AI or anything else that treats the model as core.