Mapping a business as a graph of algorithms

Every piece of work can be described as steps and handoffs. A step takes an input and produces an output. A handoff connects that output to the next step. A step that runs the same way each time is an algorithm, whether a person, a machine, or a model runs it. Draw the steps as nodes and the handoffs as edges, and the work becomes a graph of algorithms.

Color each node by who runs it. Gold is a person working alone. Green is a person working with software that drafts, extracts, or proposes, where the person keeps the final say. Blue runs without anyone reading a given case. A red diamond is a decision, and its color marks what kind of node it is rather than who runs it.

The color answers a different question at each scale. On a business map it describes a whole step. Open one node and the smaller graph inside it has no green, because being augmented is a property of the step above, not of anything inside it. Inside there are triggers, code, model calls, decisions, an output, and the point where a person signs off.

Every diagram below reads from left to right.

Three business types

Preparation and client questions are gold today, but the node that will stay gold longest is advisor review, because it owns the sign-off. Submission and deadline control already run in software.

The physical job sits in the same graph as the paperwork around it. That is what makes the map honest: some nodes are gold because nobody has automated them yet, and one is gold because a person has to be on the roof.

The first gold node is the customer placing an order, so it is not an internal automation target at all. The staff surface is fraud review, pick and pack, support, and returns.

One business, at company scale

The trades SME is the case this article follows the rest of the way.

Zoom out from the pipeline and the same business reads as three subgraphs: office, field, and back office. Nothing about the graph theory changes. Departments are clusters, and the edges that cross between them are the handoffs.

Read that way, gold sits in two different kinds of place. One is intake, where an inquiry arrives as free text and someone has to work out what it asks for. The other is the field, where a person inspects a roof and then repairs it. Those two golds are not the same problem. The first is information work that a person does because nothing else does it yet. The second is a person because the work is physical.

Three edges cross a department boundary: the dispatch after a quote is accepted, the supplies that reach the crew, and the completion report that becomes an invoice. Each crossing is a place where someone reads what the last department produced and re-enters it in the next system’s shape. That work repeats, its output can be checked against the source it came from, and a mistake in it is cheap to correct.

Which node to open

Read gold nodes by four things: how often the step runs, how much friction it carries, how cheaply its output can be checked, and how expensive a mistake is to undo. A frequent step whose output can be checked against the document it came from is a stronger candidate than a rare judgment call that is expensive to reverse.

That ranking is why Execute the work never appears below, even though it is the most human node on the map. Not because a roof cannot be automated in principle. Because nothing about it is cheap to verify or cheap to undo.

Three nodes answer the question differently, so all three are worth opening.

The gold node at intake

Inquiry received is gold because an inquiry arrives as free text and someone has to work out what it asks for. Open the node and the sequence is fixed: a model classifies the request into a structured lead, code retrieves prior jobs and the price list, a model drafts the reply and the questions still open.

Two decisions route the case, and both fail toward a person. An unfamiliar job type never reaches the drafting step. A draft whose claims cannot be traced back to what was retrieved never reaches the owner as a draft, it reaches them as an inquiry to read.

What the owner gets is a reply to approve, not a reply that was sent. On the business map the node moves from gold to green: still a person’s call, with the reading and the typing done for them. That approval edge is the whole difference between augmented and hands-off.

The node that already runs without anyone

Invoice is blue on the map, and it is worth opening because it shows what hands-off has to earn. A model extracts the fields. Code converts money to integer cents, checks that required fields are present, and verifies that the totals add up. The routing decision reads the exception list, not the model’s confidence.

Nobody approves anything here, and the reason is not that the step matters less. A wrong field is visible against the invoice itself, and a wrong booking is reversible. Cheap to check and cheap to undo is what buys a node its way to hands-off. Anything with an exception still goes to a person, which is the same fail-toward-human rule as above.

The one node that wants an agent

Qualify & schedule is the only node on this map where a fixed sequence breaks down. Booking a visit depends on answers that do not exist yet: when the customer is free, whether the crew for that trade is available that week, how far the site sits from the other jobs that day. The route cannot be enumerated before the run.

That is the discriminator, and it is the only one that matters: who owns the control flow. In a workflow the order is fixed in code and the model runs inside it. In an agent the model picks the next step at runtime.

An agent is not permission to drop the bounds. The tools are read-only. The number of passes is capped, and hitting that cap is a route, not a crash: the case goes to a person with whatever was gathered. Slots are proposed and never booked, so a wrong plan cannot become a wrong calendar entry.

The same map, after

Put the rungs back on the business map and one specific thing changes. Before, three nodes were gold: intake, the on-site assessment, and the work itself. After, one is.

Execute the work stays gold, and so does the Accepted? decision, because a customer saying yes is not a step anyone should want to automate. Everything between them turns green. Only the repetitive tail is blue: invoice, reminders, reorder.

That distribution is the argument. Most of what a business calls manual work is not a candidate for removal. It is a candidate for augmentation with a person holding the last edge.

Why full automation is the wrong target

Every node carries a rung. Manual, then suggested, then drafted behind an approval gate, then supervised inside bounds, then autonomous. The rung is chosen per node, never per business.

Autonomy is bought with testability. Every step the model owns is a decision nobody can assert on before it runs. So the posture is to start at the lowest rung that does the job and climb only when the work forces it. Boredom with the current rung is not a forcing function.

What the map does not show

Color says who runs a node. It says nothing about whether that node can be trusted to run. That part is invisible on any map, and it is most of the engineering.

An inquiry is untrusted input

The intake node reads text written by someone outside the business. Text a model reads can carry instructions, and a model that follows them has been prompt injected. The defence is not a better prompt. It is policy checks at the three points where the loop touches the outside world: what comes in, which tool calls are allowed, what is permitted to go out. The scheduling node’s read-only tools are one such check, written as a permission rather than an instruction.

Schemas between steps, not prose

The classify step does not hand the next step a paragraph to interpret. It returns a lead against a declared schema, so retrieval parses it instead of guessing. Every seam in these graphs is a schema boundary, which is what makes a single step testable on its own instead of only as part of the whole chain.

That matters more as the chain grows. Steps that each succeed nine times in ten leave a five-step chain succeeding about six times in ten. Chain length is a reliability tax, and it is why each step is cut so its output can be checked by itself.

Grounding is checked, not hoped for

“Every claim grounded?” is a step, not a disclaimer. Where an exact expected answer exists, code compares. Where none exists, a second model call scores the draft against a written rubric, and the reply reaches the owner only if it passes. A confident wrong answer is the normal failure mode of these systems, not a rare one.

Evals before opinions, traces after

A fixture set of past inquiries and past invoices with known-correct outputs gets scored on every prompt change, model swap and schema edit. That is what makes quality measured rather than felt. Without it, “it got worse after the change” stays an opinion nobody can settle.

Every run leaves a trace: what was retrieved, what the model returned, which branch the decision took, what the person approved or corrected. The corrections are the most valuable rows in that log, because they are labelled failures produced by the only person who knows the right answer.

Hands-off costs more, not less

The blue node has no approval step, so everything it needs has to be in the code. Booking the same supplier invoice twice has to be the same as booking it once. A crash halfway through has to resume where it stopped instead of starting again or vanishing. A failure needs its own path that logs with context and reaches a person, rather than a silent retry.

That is the honest price of a rung. Every step up removes a human check and has to replace it with an engineered one.

The map does not tell a business to automate. It says where the work sits, what each node would cost to verify, and which node is worth opening first.

The three business maps are illustrative types, not audits of real companies. The node graphs are drawn the same way: what the work requires, not a record of a customer engagement.