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

This is the question nobody answers

Ask a shop what happens when your needs change in six months and the answer is usually a posture: flexible, modular, built to grow. None of that survives a specific request.

The useful version is plain: name the four buckets, then say which one a given change falls into and why. Every system has all four. What separates a good one is where the line sits, and a team that runs its own systems can draw that line without stopping to think.

What lives in each bucket, from systems that are running

These are OCTYN's own, written down before anyone asks, which is the point.

• A settings change on Mooney: which key is active, the daily caps per plan, which provider goes first. Upgrading a key's plan changes no code, because the system already sends work to whichever one has room.
• A small code change on Mooney: a new expense field, a new category, another spoken language, one more backup step. The server-side pieces update on their own, so a change reaches every phone that has the app without a store review. That is why the line sits there.
• A large code change on Mooney: anything that changes what the system hands back, because the instructions, the checker and the expense logic are tied together. Also anything touching the widget, since running two processes at once is structural.
• A rebuild on Mooney: shared team accounts, because storage today is a single file with no structure and no migration path. That fits one person and not a shared team, and OCTYN would say so before taking the work.
• A settings change on the craft retailer's outreach system: the target list is a file per company, and daily volume, the split between markets, inbox limits, send windows and follow-up timing are all values a person can set. Another company already runs on the same system with a completely different target list, which is the proof the split holds.
• A rebuild on the retailer's system: sending at a much higher volume than today, because the research step is deliberately slow and built for care over speed.

Why a glued workflow lands higher up the list

Not because the workflow is a bad choice. Because of where its logic sits.

In a built system, the rule that decides something is a named piece of code, next to a test that fails when it is wrong, with a note saying why it was written. Six months later, someone can find it by searching for what it does, change it, and know from the test whether anything broke.

In a glued workflow, the rule is the shape of the connections. There is no name to search for, no note saying why it was drawn that way, and the only way to know whether a change broke something is to run it and watch. That is fine at three steps. At thirty, a small change becomes an afternoon of clicking, and whoever built it has often moved on.

This compounds with the person more than with the workflow itself. Most of it gets built by whoever needed it that week, in whatever window was open, and the reason lives in their head. A rebuild six months later is often not a technical call. It is that nobody left can say 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 one lands in and why.

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