The step you never need to automate

A proposed sync has twenty boxes. Box seven copies a status into a spreadsheet. Box eight reformats the spreadsheet for an email platform. Box nine emails a manager to approve the import. The plan asks which agent should perform boxes seven through nine.

The first question is why those boxes exist. This example is illustrative, not an audit of a real team.

A workflow-design discussion proposes four buckets for work: delete the step, use plain code, use an agent, or leave a human decision. The useful move comes before model selection. Deleting a step can remove the need for all the machinery around it.

Start with the customer-visible outcome

Name the result the workflow must produce. For a store-to-email connection, it might be “a customer who purchased no longer receives a cart reminder.” That result implies state, timing and a suppression rule. It does not imply a spreadsheet, a nightly full export or a manager’s inbox.

The Tajo illustration below keeps the review focused on the proposed mapping and the boundary before activation. It does not implement cart-reminder suppression. For that outcome, the operator must first define the purchase signal and suppression rule. Adding another mapped field would not substitute for either decision.

TajoConcept illustration · Example data

Review a sync before it runs

Sync customer updates to my email platform.

Tajo MCP appDraft

Customer sync

StoreEmail platform

Field mapping

Source field	Destination field	Rule
email	EMAIL	Direct
first_name	FIRSTNAME	Direct
last_name	LASTNAME	Direct

Synthetic preview passed

3 fields mapped · No destination writes

Activation requires approval.

Preview mappingCreate draft

Illustrative layout based on Tajo's mapping tools. A synthetic preview and a saved draft do not activate a sync.

Walk the existing path backward from the result. For each step, ask what would fail if it vanished. A real control has an answer: consent would be lost, a payment dispute would be ignored, or an unauthorized send could occur. A habitual handoff may have only a historical answer: the old system needed a file.

The deletion bucket is not permission to erase safeguards. Inspect the purpose of each step before choosing a bucket.

1. Required outcome

   customer result
   work backward
2. Inspect steps

   purpose and control
   remove dead steps
3. Retained work

   owned and testable

The audit identifies the deliverable and the dependencies that genuinely protect it. If a spreadsheet carries a business judgment that is absent elsewhere, the judgment must be preserved even if the file disappears.

Step type	Question	Example in an illustrative cart flow
Remove	Does it protect or produce the required outcome?	A duplicate export nobody reads
Plain code	Is the rule exact and stable?	Suppress a reminder when a verified purchase exists
Model judgment	Does the step require bounded interpretation?	Classify a free-text request for the right team
Person or approved policy	Does the choice grant authority or carry material consequences?	Approve access to customer data

The table is a design tool. It does not report how any company’s actual steps were classified.

Put exact rules in code

An API call, field validation, timestamp comparison or permission check does not become better because a model improvises it. Code can express an invariant, run the same way twice and produce an inspectable failure. Use it where the rule can be stated.

For the cart example, a purchase event may arrive late or twice. The program should identify the order, compare current state and refuse a reminder when the purchase is known. If the system cannot establish whether a purchase happened, it needs an uncertainty state. A model cannot grant itself permission to guess that the customer did not buy.

Some work resists exact rules. A support request might say, “I bought this yesterday but the receipt shows my old address.” Routing that message could use a bounded semantic judgment. The output should be a known team or “uncertain,” not an open-ended instruction to alter the order. Keep the model’s decision separate from the code that enforces access and writes state.

Why one agent can hide the steps

“One agent could read the workflow and do everything.” A demo can make that look simpler. Production still needs someone to explain why the agent may view a record, which actions it may take and how a bad action is reversed. A broad agent often hides the same steps inside a prompt and removes the labels that made them auditable.

A second objection is that a four-bucket audit itself costs time. It does. Keep it short. Choose one customer result, list the steps needed to deliver it, and ask what each step contributes. The exercise is valuable only if it shrinks the work or clarifies ownership. An elaborate audit of every adjacent system becomes another box.

Test the classification with a normal case and a failure case. If a removed step was secretly a control, the test should reveal it. If a model judgment cannot be evaluated on examples, narrow it or return the decision to a person. If code requires changing on every customer exception, separate the stable mechanics from the local business rule.

The audit also needs a stopping rule. A team can keep decomposing every task until the classification exercise costs more than the saved work. Stop when each retained step has an owner, a trigger and a testable reason to exist. Record the one uncertainty that would change the design, then test it in the smallest live slice. For a sync, that might be whether a purchase event arrives soon enough to suppress a queued reminder. The integration guide gives a broader planning sequence; the four buckets keep that sequence from preserving unnecessary steps. Revisit the classification when the workflow or its permissions change.

The cheapest step is the one the outcome never required.