Insights

Every automation conversation starts with a tool and ends with a workflow. Flipping that order is the difference between software that runs your business and software that runs up a bill. Before you scope any automation, answer these five questions about the workflow itself.

1. Does the workflow follow a rule — or does it need judgement?

If the same input reliably produces the same output, it is a rules problem and automation is straightforward. If every case needs fresh judgement — reading context, weighing trade-offs, handling the unexpected — the workflow still benefits from AI, but as an assistant to a human, not a replacement. Be honest about which one you have; the design follows from that answer.

2. How much time does it actually take, and how often?

Automation has a build cost and a maintenance cost. A workflow that consumes a person for an hour every day is a different proposition from one that happens twice a month. Measure the recurring effort before you build, and keep the measure in the business case.

3. Where does the data live, and how do you reach it?

Automation needs access: an API, an export, a database connection, or a human stepping in at the edges. Map the data path first. Workflows that look simple on a whiteboard often hide a data source that is locked down, unstructured or owned by another team. That is a scoping problem, and it is cheaper to find it before the build than during it.

4. What happens when it fails?

A workflow that never fails does not exist. The serious question is what a failure costs and how quickly it surfaces. Retries, logging, alerts and a defined fallback — like routing the item to a person — are not extras. Decide the failure policy before you decide the happy path.

5. What does being wrong cost?

If an error costs a contract or a compliance breach, the automation needs a human checkpoint. If being wrong just means a re-run, it can run unsupervised. The cost of being wrong sets the level of guardrails, review steps and testing the system needs.

Answer these five and you have the raw material for a real scope. Skip them and you have a demo looking for a workflow. If you want help working through them for a specific process, that is exactly what the AI Clarity Session is for.

Model choice is a scoping decision, not a religion. OpenAI, Anthropic and the open-source ecosystem each earn their place in different workflows, and a single system often mixes them. Here is the frame we use when deciding.

Hosted model APIs

Hosted APIs — like OpenAI and Anthropic — are the default for language-heavy features. They bring frontier capability without you operating infrastructure, they scale with usage, and they improve as the provider ships new versions. The trade-offs are data leaving your environment, per-call cost that grows with volume, and dependence on a provider's API and roadmap.

Open-source models

Self-hosted open-source models earn their place on three tests: data that must not leave your environment, call volumes where per-token pricing changes the economics, and the need to control the stack end to end. The cost is yours to carry: the infrastructure, the evaluations, the updates and the operator skill to keep the model current and behaving.

The decision hinges on the workflow

Ask what the model is doing. Extracting fields from an invoice, summarising support threads and answering from internal knowledge each impose different demands on data handling, latency, cost and accuracy. A document-processing pipeline that runs inside your network might use a self-hosted model for extraction while a customer-facing assistant uses a hosted API for reasoning.

Two practical notes. First, capability moves fast in both directions — a model that was the obvious choice six months ago may not be now, so write the integration so the model is a swappable component, not a hard-wired dependency. Second, whatever you choose, the workflow needs an evaluation set: a batch of real inputs with known-good outputs, so you can measure whether a model change actually improves the system. That is the discipline that keeps model choice honest.

Model-agnostic means we make this call per workflow and name it in the quote. If you want a second opinion on your stack, start the conversation.

AI work is easy to start and hard to finish, and the shape of the engagement has a lot to do with why. A fixed-scope package changes the conversation from "what could we explore" to "what will we deliver" — and that discipline is most of the battle.

Fixed scope forces the useful questions

When the deliverable is defined before work starts, someone has to answer the questions that actually determine success: which workflow, measured by what, touching which systems, and explicitly not covering what. Scope documents are where vague ambition meets reality — and it is far cheaper to have that meeting before the build than after three weeks of exploration.

A defined deliverable makes done unambiguous

An open-ended engagement can declare progress forever without ever declaring done. Fixed scope defines done as a concrete state: the workflow deployed, the tests passing, the documentation handed over, the operator walkthrough completed. When the demo and the production system are the same thing, there is nothing left to "land" later — and no gap where value quietly evaporates between excitement and delivery.

What fixed scope does not solve

It does not remove the need to know what outcome you want. If the business goal is fuzzy, a fixed-scope build will deliver exactly what was written down — and that may not be what you needed. That is why scoping packages exist: the AI Clarity Session and the AI Opportunity Audit are themselves fixed-scope engagements whose deliverable is the decision about what to build next. Clarity first, then commitment, then build.

This is the model behind every m00labs package: a defined deliverable, an agreed boundary and a quote approved before the work starts.