Translating Workflow Steps into Algebraic Expressions

Hello. In the previous lesson, you learned to read the compact notation that appears in ML writing: labels such as $n_{\mathrm{in}}$, indices such as $t$, Greek letters, and constraint symbols. Now we will use that notation to do something more active: turn a precise description of one deterministic workflow step into algebra.

A deterministic step is one whose output is fully determined once its inputs are known. For example, if a prompt-building step always joins a fixed system prompt, a user request, and retrieved context, then the total prompt-token count is determined by the token counts of those pieces. There is no sampling, model judgment, or probability involved in this specific calculation.

By the end of the lesson, you should be able to identify the output of a workflow step, name its inputs and fixed settings, choose the operations described by the words, and write a clear algebraic equation for the step.

---

From a workflow sentence to an equation

Suppose a workflow specification says:

The prompt builder creates an input prompt by combining the system instructions, the user message, and retrieved context.

This describes a relationship, but it does not yet give us quantities or operations. To formalize it, first ask four questions:

1. What quantity does the step produce?
   Here, we may care about the total number of input tokens.

2. What quantities does it use?
   The token counts in the system instructions, user message, and retrieved context.

3. Which parts vary, and which are fixed?
   The user message and retrieved context may vary from request to request. System instructions may be fixed for a deployment, although they can still be represented by a symbol.

4. How are the inputs combined?
   “Combining” token counts means adding them.

Choose symbols with informative labels:

Quantity	Symbol	Unit
Total input-prompt tokens	$n_{\mathrm{in}}$	tokens
System-instruction tokens	$n_{\mathrm{sys}}$	tokens
User-message tokens	$n_{\mathrm{user}}$	tokens
Retrieved-context tokens	$n_{\mathrm{ctx}}$	tokens

Now write the relationship:

$$n_{\mathrm{in}}=n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}$$

Read it as a complete sentence:

The input-token count equals the system-instruction token count plus the user-message token count plus the retrieved-context token count.

The expression on the right,

$$n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}$$

is an algebraic expression: it calculates a quantity but does not make a complete claim by itself. Adding the equality sign and the output quantity gives an equation:

$$n_{\mathrm{in}}=n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}$$

For workflow design, equations are usually what you want. They document both the calculation and the meaning of its result.

---

A translation procedure that works for workflow specifications

Natural language tends to mix the story of a system with its calculation. Algebra asks you to separate them.

Use this procedure for one deterministic step.

1. State the step’s output in words

Start with a sentence in the form:

This step calculates __________.

For the prompt-builder example:

This step calculates the total number of tokens sent to the model.

This prevents a common mistake: writing an expression but never saying what it represents.

2. Name every input quantity

Use symbols that preserve role and scope:

$$n_{\mathrm{sys}},n_{\mathrm{user}},n_{\mathrm{ctx}}$$

The subscripts do not change the arithmetic. They make the equation understandable later, when a workflow has many token counts.

3. Circle the operation words

The words in the specification usually reveal the arithmetic.

Wording in a workflow description	Typical operation	Example
total, combined, plus, added	addition	$a+b$
reduced by, minus, excluding	subtraction	$a-b$
per call, each, times, scaled by	multiplication	$ab$
split among, average per, divided by	division	$\frac{a}{b}$
total of, entire, combined result	grouping may be needed	$k(a+b)$

These are clues, not magic translations. You must still determine what is being operated on and in what order.

4. Write the right-hand-side expression

For three components combined into a prompt:

$$n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}$$

5. Assign it to the output

$$n_{\mathrm{in}}=n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}$$

6. Validate it with a small numerical test

Suppose:

$$n_{\mathrm{sys}}=180,n_{\mathrm{user}}=70,n_{\mathrm{ctx}}=1,250$$

Then:

$$n_{\mathrm{in}}=180+70+1,250=1,500$$

The result has units of tokens, as it should. This simple check catches many translation errors.

A useful habit is to ask:

If I substituted reasonable values into this equation, would it calculate the quantity described by the sentence?

That is stronger than merely checking whether the equation “looks mathematical.”

---

Deterministic does not mean “all inputs are constant”

A workflow step can be deterministic even when some inputs change between runs.

Consider this description:

The system estimates the input cost by multiplying input tokens by the configured input price per token.

Let:

Quantity	Symbol	Unit
Input cost	$C_{\mathrm{in}}$	dollars
Input-token count	$n_{\mathrm{in}}$	tokens
Input price	$p_{\mathrm{in}}$	dollars per token

The algebraic model is:

$$C_{\mathrm{in}}=p_{\mathrm{in}}{n}_{\mathrm{in}}$$

Here, $n_{\mathrm{in}}$ will generally vary with each request. The price $p_{\mathrm{in}}$ might be fixed by your selected provider and model for a particular period. Yet the step is deterministic: when the values of $p_{\mathrm{in}}$ and $n_{\mathrm{in}}$ are supplied, the output cost is fixed.

The units provide a built-in check:

$$\left(\frac{\text{dollars}}{\text{token}}\right)(\text{tokens})=\text{dollars}$$

If your proposed formula produces “dollars times tokens squared,” or “dollars per token,” when the target is a dollar cost, pause. Either the intended quantity or the operation is wrong.

This is one reason units are useful in AI-systems design. They make a formula testable before you have production measurements.

---

Order matters: subtraction, division, and “less than”

Addition is forgiving:

$$a+b=b+a$$

The order does not change the result. Subtraction and division are different:

$$a-b\ne b-a$$

and

$$\frac{a}{b}\ne \frac{b}{a}$$

So read wording carefully.

Suppose a context-management step is described this way:

The remaining token budget is the maximum context size minus the tokens already used.

Define:

• $n_{\max }$: maximum allowed context tokens
• $n_{\mathrm{used}}$: tokens already used
• $n_{\mathrm{remain}}$: remaining token budget

Then:

$$n_{\mathrm{remain}}=n_{\max }-n_{\mathrm{used}}$$

A quick reality check helps. If the maximum is $8,000$ tokens and $6,500$ are used, the remaining budget should be positive and relatively small:

$$n_{\mathrm{remain}}=8,000-6,500=1,500$$

Reversing the terms gives $-1,500$, which contradicts the intended meaning of “remaining budget.”

The wording “less than” is especially easy to reverse. Consider:

The remaining budget is 500 tokens less than the maximum budget.

Starting from the thing being described—remaining budget—gives:

$$n_{\mathrm{remain}}=n_{\max }-500$$

The phrase does not mean $500-n_{\max }$.

---

Parentheses preserve the workflow’s structure

Parentheses are not decorative. They tell the reader which calculation happens first.

Imagine a workflow policy that says:

The system reserves 10% of the combined system, user, and context tokens for formatting overhead.

Let $n_{\mathrm{overhead}}$ be the number of reserved overhead tokens. “10%” is $0.10$, so:

$$n_{\mathrm{overhead}}=0.10\left(n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}\right)$$

The parentheses say: first find the combined prompt size; then take 10% of that total.

Without parentheses:

$$n_{\mathrm{overhead}}=0.10n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{ctx}}$$

only the system tokens are multiplied by $0.10$. That is a different workflow rule.

Take a numerical case:

$$n_{\mathrm{sys}}=200,n_{\mathrm{user}}=100,n_{\mathrm{ctx}}=700$$

The intended rule gives:

$$n_{\mathrm{overhead}}=0.10(200+100+700)=0.10(1,000)=100$$

The incorrect ungrouped version gives:

$$0.10(200)+100+700=820$$

The huge discrepancy is a reminder that the algebra must preserve the meaning of the workflow sentence, not merely contain familiar-looking symbols.

---

A worked translation: context selection with a fixed reserve

Let us formalize one complete deterministic step from a plausible agent harness.

Before calling the model, the context manager sets the retrieved-context allowance to the model’s maximum context size minus the system prompt, user message, and a fixed safety reserve.

The output is not the final prompt size; it is the allowance for retrieved context. This distinction is essential.

Define the quantities

Meaning	Symbol	Unit
Retrieved-context allowance	$n_{\mathrm{ctx},\max }$	tokens
Model context limit	$n_{\max }$	tokens
System-prompt size	$n_{\mathrm{sys}}$	tokens
User-message size	$n_{\mathrm{user}}$	tokens
Safety reserve	$n_{\mathrm{reserve}}$	tokens

Identify the calculation in layers

The starting quantity is:

$$n_{\max }$$

The workflow then removes three quantities from that total:

$$n_{\mathrm{sys}},n_{\mathrm{user}},n_{\mathrm{reserve}}$$

So the full equation is:

$$n_{\mathrm{ctx},\max }=n_{\max }-n_{\mathrm{sys}}-n_{\mathrm{user}}-n_{\mathrm{reserve}}$$

The same rule can be grouped to emphasize that all three quantities form the total reserved space:

$$n_{\mathrm{ctx},\max }=n_{\max }-\left(n_{\mathrm{sys}}+n_{\mathrm{user}}+n_{\mathrm{reserve}}\right)$$

These two versions are equivalent because subtracting each component one at a time has the same result as subtracting their sum.

Test the equation

Suppose:

$$n_{\max }=16,000,n_{\mathrm{sys}}=900,n_{\mathrm{user}}=1,100,n_{\mathrm{reserve}}=2,000$$

Then:

$$n_{\mathrm{ctx},\max }=16,000-(900+1,100+2,000)$$ $$n_{\mathrm{ctx},\max }=12,000$$

This formula makes a design assumption explicit: the safety reserve is a fixed number of tokens. Later, you might decide the reserve should depend on task type or desired output length. For now, it is enough to see how a verbal rule becomes a model that can be evaluated, audited, and changed.

---

One step can combine several inputs with different weights

Not every deterministic workflow step is simply a total or a subtraction. A scoring rule can give inputs different importance.

For example:

A routing score equals a base score plus twice the retrieval-quality score minus the latency penalty.

Let:

• $s_{\mathrm{route}}$: routing score
• $b$: fixed base score
• $q_{\mathrm{retrieve}}$: retrieval-quality score
• $p_{\mathrm{latency}}$: latency penalty

Then:

$$s_{\mathrm{route}}=b+2q_{\mathrm{retrieve}}-p_{\mathrm{latency}}$$

The coefficient $2$ means that each one-unit increase in retrieval quality contributes two score units. The negative sign means a larger latency penalty lowers the routing score. This is still a deterministic calculation: provide the three inputs and it produces one score.

The same pattern appears in basic predictive models, where each feature contributes its value multiplied by a weight.

For the moment, do not treat the image as a model you need to train or fully interpret. Its immediate lesson is structural: one output can be defined as a base amount plus several carefully named, weighted input contributions. You will return to this form later when studying linear functions, vectors, and optimization.

---

A compact quality check before accepting an equation

Before treating a formula as a faithful description of a workflow step, check five things:

1. Output check: Is the left-hand side exactly the quantity the step is supposed to produce?
2. Input check: Does every quantity used on the right-hand side have a definition?
3. Operation check: Do plus, minus, multiplication, division, and parentheses match the wording?
4. Unit check: Does the right-hand side have the same units as the output?
5. Reality check: Does substituting a small, sensible set of values produce a plausible result?

This approach matters when reading papers as well as when designing systems. A formula may be correct algebraically but still be a poor model of a workflow if it omits a relevant input, encodes an unstated assumption, or uses the wrong quantity as its output.

---

You can now translate a deterministic workflow rule into algebra by identifying its output, naming inputs with meaningful symbols, mapping the wording to operations, preserving grouping and order, and checking the result with units and example values.

The central distinction is worth retaining:

$$\text{expression}\text{versus}\text{equation}$$

An expression computes a value. An equation assigns that expression to a named output and makes the workflow relationship explicit.

Next, you will make this idea more general by treating a workflow rule as a function: a named input-output mapping that can be evaluated for different inputs.