What does it cost to change an AI workflow six months later?

This is the question nobody answers

Ask a shop what happens when requirements change in six months and you tend to get a posture rather than an answer. Flexible. Modular. Built to scale. None of that survives contact with a specific request.

The useful version is boring: name the four buckets, then say which bucket a given change falls into and why. Every system has all four. What separates them is where the line sits, and a team that has operated its own systems can draw that line without thinking about it.

What lives in each bucket, from systems that are running

These are OCTYN's own, and each one is written down before it is asked for, which is the point.

• Configuration on Mooney: API keys, per-tier daily OCR caps, free and paid limits, which provider is primary. Adding a fourth key or moving one to a paid tier changes no code, because the least-loaded routing finds the higher ceiling on its own.
• Contained on Mooney: a new expense field, a new category set, another speech language, a fifth fallback. Edge functions deploy independently of the app, so a server-side change reaches every installed phone without a Play review. That is why the seam is where it is.
• Large on Mooney: anything that alters what the model returns, because the prompt, the sanitiser and the expense model are coupled. Also anything touching the widget overlay, because two Android processes is structural.
• Rebuild on Mooney: shared team accounts, because storage is a local JSON blob with no schema and no migrations. That is right for single-user local-first and wrong for shared data. We would say so before taking the work.
• Configuration on the aarttsii outreach system: the ICP is a JSON file per tenant, and daily volume, the geography split, inbox caps, send windows and follow-up offsets are all values. A third tenant already runs on the same engine with a completely different ICP, which is the proof the separation holds.
• Rebuild on WhoFits: changing what counts as an interaction edge. Edges accumulate over a window that cannot be replayed, so a different definition of influence means collecting again. The graph is cheap to query and expensive to re-earn.

Why a glued workflow lands higher up the list

Not because the tool is bad. Because of where the logic is kept.

In a built system, the rule that decides something is a named thing in a file, next to a test that fails when it is wrong, with a commit message saying why it was written. Six months later you can find it by searching for what it does, change it, and know from the test whether you broke anything.

In a glued workflow, the rule is the shape of the connections. There is no name to search for, the reason it was drawn that way is not recorded anywhere, and the only way to know whether a change broke something is to run it and see. That is fine at three steps. At thirty, a small change becomes an afternoon of clicking, and the person who drew it has usually left.

This compounds with the person, not the tool. Most glue is built by whoever needed it, in the tab they had open, and the reason is in their head. A rebuild six months later is often not a technical judgement. It is that nobody left can explain what the thing was supposed to do.

Ask for the four buckets before you sign

Take the three changes you are most likely to want in six months. Not hypotheticals: the ones already half-discussed. Ask which bucket each lands in and why.

The answer tells you two things. Whether they have thought about change at all, and whether they will tell you the expensive answer when it is the true one. Anyone who puts all three in configuration is either selling or has not built it yet.

The receipts under this page

Every claim above comes from a system OCTYN built and operates. Each line carries the date it was recorded and where it came from, so it can be argued with rather than taken on trust.