The Unwritten Rules Your AI Workflow Needs

Before automating a workflow, make the business rules behind its decisions explicit: which information matters, what action is allowed, which exceptions change the route, and who decides when the instructions leave a gap.

Start with a conversation. The knowledge may live in a colleague's explanation of a difficult case, a correction to an old procedure, or a distinction nobody thought to write down.

The goal is a rule record that explains the work, supplies the needed context, and makes changes easier to maintain.

Find the decision hidden inside the instruction

Choose one recurring workflow and locate the phrases that depend on shared understanding: “as usual,” “where appropriate,” “use your judgment,” or “send urgent requests straight through.”

Ask the person who knows the work to walk through a recent case they are allowed to share. Where did they hesitate? What information changed the route? What would have made the same request ordinary instead of exceptional? Ask another experienced colleague to explain the same case. Differences reveal decisions the procedure has not settled.

Capture the distinction, its reason, and the approved source behind it. A practice people remember may be current policy, an authorized exception, or a habit that has outlived its purpose. The workflow owner needs to resolve that before it becomes an automated instruction.

OpenAI's practical guide to building agents recommends starting from operating procedures and policies, defining specific actions, and accounting for incomplete information and other variations. Those are useful starting points for turning team knowledge into instructions. The rule record below is our illustrative application, rather than an OpenAI template.

Write one rule that somebody else can apply

Consider an illustrative request-routing workflow. It drafts an internal service assignment from an incoming request, for a responsible colleague to confirm. It may select an approved queue for that draft; it may not confirm the assignment, promise a delivery date, approve extra work, or change a customer's terms.

The procedure's vague instruction is: “Send the request to the usual team.” A more useful rule defines the evidence needed to select that team.

These are invented example rules, not a client policy. In a real workflow, the owner must confirm the inputs, permissions, source roles, and exception route.

The record separates routing from authority to make a commitment. It also exposes a dependency: if the account register is unavailable or ambiguous, the ordinary route cannot be established.

Decide how sources take precedence

A system can retrieve two documents and still have no authority to choose between them. A newer file might be a draft. A procedure might cover ordinary requests while an approved exception applies only to one account.

Define which source governs each decision, its scope, and its effective period. A source list alone does not establish precedence. The owner should state whether a specific exception can override a general rule, who may approve that exception, and what happens after it expires.

If two approved sources disagree and no precedence rule resolves the conflict, expose the disagreement to the decision owner. The AI should show the relevant passages and affected request, rather than silently selecting whichever instruction seems easier to execute.

This builds on the approved-source responsibilities in our AI data governance guide. Here the practical question is narrower: which instruction applies to this decision, and what should happen when the answer is unclear?

Give missing information a useful path

“Ask for clarification” needs enough detail to be executable. Specify what is missing, who can provide it, and what limited work may continue while the team waits.

For our example, a missing service description may permit a clarification draft. It does not permit the AI to invent a service category or choose a queue from a customer's previous request. Where asking the requester is authorized, the workflow can ask the defined question. Otherwise, it can prepare that question for the responsible colleague.

An exception should arrive with a decision to make. “Please review” leaves the colleague to reconstruct the problem. A short explanation of the gap lets them confirm a route, obtain information, or approve a documented exception under the organization's rules.

Preserve judgment where a rule is insufficient

Some distinctions can become explicit conditions. A missing required field can be checked consistently. A current assignment can be read from an approved register. Those checks can often use ordinary automation without asking a model to interpret them each time.

Other decisions remain contextual. An unusual customer situation may require a person to weigh competing priorities. Record what the system may prepare, what context the decision maker needs, and where their discretion begins.

Trying to convert every judgment into a rigid condition can hide the judgment inside an unreliable shortcut. Leaving every decision open-ended can make routine work unnecessarily dependent on a busy colleague. Use the rule to define the ordinary path and the reason for leaving it. Our guide to human review develops the operating design of those decision points.

Test the distinction with examples and counterexamples

Ask the workflow owner for a small, varied set of approved or synthetic cases. Include an ordinary request, one missing a required input, a source conflict, and a request outside the permitted scope. Record the expected route and its reason before testing the instructions.

A useful counterexample changes one important fact. If the ordinary case names one service, change it to two. If a specific exception applies to a named account, substitute an account outside its scope. Does the workflow preserve the distinction, or generalize the exception to everybody?

Anthropic's context engineering guidance recommends clear, relevant instructions and a diverse set of representative examples. It also cautions against trying to describe every possible edge case in an overloaded prompt. Apply that principle by keeping the rule and approved examples coherent, while making the current source available when the decision needs it.

More text does not establish that the workflow understands the rule. Inspect the choices it makes across the examples. When a case fails, determine whether the problem is an unclear rule, missing context, a wrong source, or an implementation error. Each requires a different correction.

Our guide to verifying AI task completion tests whether a run finished; these examples test whether the rule draws the right line.

Maintain the rule when the work changes

Treat the rule record as part of the operating procedure. Name who approves changes and who updates the connected workflow. Record which version became effective and how requests already in progress should be handled.

When a queue changes, an exception expires, or two policies are reconciled, update the affected instructions and examples together, then rerun the examples before the new version takes effect. Check that the previous source no longer governs new decisions. Retain the change history needed to explain earlier routing choices.

Repeated exceptions may reveal a missing distinction, a rule nobody can apply, or a new category of work. A recorded exception should inform a reviewed change, rather than automatically becoming policy.

Start with the sentence your team explains differently

Take one procedure and ask two colleagues to interpret its most ambiguous instruction. Have the workflow owner settle the difference, then write down the required inputs, condition, allowed action, exception, owner, and governing source. Test the rule on a few examples before connecting it to real work.

Myappics advises, builds, runs, and continuously improves digital operations alongside businesses and nonprofits. Your team retains authority over policies and business decisions; we help translate those requirements into a maintained workflow.

To work through a practical next step, book a 30-minute conversation. Bring one procedure your team interprets differently. We can discuss the rules, exceptions, sources, and operating responsibilities it needs before automation.

About the author

Carlos "Charlie" Gil is founder and CEO of Myappics, which advises, builds, runs, and continuously improves AI, data, and digital operations for businesses and nonprofits.

Author profiles: LinkedIn · Mr. BrainCode on X.