Forward deployed engineering field note: make the boring path deterministic first

One pattern I would use in almost every practical AI implementation: make the boring path deterministic before you add the agent.

In forward deployed engineering, the agent should usually not be the first version of the workflow. The first version should be a plain map of what already happens when the work goes well.

For example:

- what triggers the workflow?

- what source records are required?

- which fields decide the route?

- what should happen automatically every time?

- what needs human review?

- what counts as an exception?

- what should never be done without explicit approval?

That boring path becomes the control surface.

Then the agent can help around it:

- read messy context

- draft the next action

- explain why a record looks risky

- classify the exception

- prepare a handoff packet

- suggest the next owner

- summarize what changed

But the deterministic path still owns the guarantees: routing, permissions, approvals, writeback rules, retries, escalation, and audit trail.

The failure mode is trying to make the agent own everything at once. Then every edge case becomes a prompt problem, every bad write becomes a mystery, and every operator has to guess what the system thought it was doing.

A better deployment question is:

What part of this workflow should be boring every time, and what part actually needs judgment?

If that split is clear, the agent has a job. If it is not clear, the agent becomes a very fluent way to hide process debt.