Specialist build shops and independent automation engineers, including OIA. That is the honest answer to who builds custom AI automation and workflow orchestration for businesses, and it is also the least useful part of the answer, because the category tells you nothing about whether the engagement will leave you better off. Here is the position, and it holds for the rest of this piece: a custom AI workflow build is worth buying only when the engagement produces three things you own outright, a written blueprint, pass fail acceptance checks you can run yourself, and a handoff that leaves a named owner able to operate and change the workflow without the builder. Three artifacts. If a proposal is missing one, you are not buying a workflow, you are renting access to someone else's understanding of your business.
The failure mode this rule prevents
The common bad outcome is not a build that breaks, it is a build that works and cannot be changed. Picture the ordinary version of this. A shop wires an intake automation: form submission lands in a webhook, an LLM extracts fields and drafts a reply, a record gets written to your CRM, a Slack message pings the owner. It runs. Everyone is pleased. Four months later your intake form gains a field, or the model version you pinned gets deprecated, or a prompt starts returning the customer's company name in the contact name slot. Now you open the automation and find eleven steps, a JSON transform nobody documented, three prompts written in a text box you cannot search, and one credential connected to a builder's personal account. You cannot fix it. You cannot safely turn it off, because you no longer know what else reads that record. You call the builder back, and the price of a change is not the change, it is the rediscovery.
That is a handoff failure, and it is invisible at go-live. Every one of those builds passes a demo. The demo is exactly where this failure hides, because a demo tests the happy path in the presence of the person who built it. The three artifacts exist to make the failure visible before you pay for it.
Artifact one: the written blueprint
The blueprint is a document that describes the workflow precisely enough that a competent stranger could rebuild it. Not a diagram. Not a Loom video, though a video is a fine supplement. A written document, in your drive, that names things.
Concretely, a blueprint for that intake workflow should state: the trigger and its exact source (which form, which field IDs), each step in order with the system it touches and the account it authenticates as, the full text of every prompt, the model and version pinned at each LLM call, the data written and where it lands including field-level mapping, what happens on failure at each step (retry, queue, alert, drop), and the human decision points with their escalation path. It should also state what the workflow deliberately does not do, which is the section most builders skip and the one that saves you most often. If the workflow does not handle attachments, write that down. Six months from now, somebody will ask why attachments vanish, and the answer should cost thirty seconds, not a support ticket.
Two tests for whether a blueprint is real. First, hand it to someone on your team who did not attend the build sessions and ask them to trace one record end to end using only the document. If they get stuck, the blueprint is a memory aid for the builder rather than a description of the system. Second, check whether the blueprint lives somewhere you control. A document inside the builder's Notion workspace is not yours. Ask for it in your Google Drive, your SharePoint, your repo, on day one, not at the end.
Artifact two: acceptance checks you can run yourself
An acceptance check is a specific input paired with a specific expected output and a pass or fail verdict a non-engineer can render. That last clause is the whole thing. "The extraction is accurate" is not a check. "Submit test record 4 (the one with a hyphenated last name and no company field), confirm the CRM record shows last name Ortiz-Nguyen and company blank rather than the string null, confirm no Slack alert fires" is a check. It has an input you can reproduce, an output you can look at, and a binary answer.
Build the check set around failure, not success. A useful set covers the happy path once and then spends the rest of its attention on the ways the workflow is known to bend: empty required fields, a duplicate submission ninety seconds after the first, a submission with an unusual character set, an input long enough to threaten your context budget, a deliberately ambiguous request that should route to a human instead of getting a confident machine answer, and the behavior when the upstream API returns an error or a timeout. Ten to fifteen checks is a reasonable target for a first workflow. That is not a standards figure, it is a working target, so calibrate for your deployment: a workflow that touches money or health data earns more, an internal drafting assistant earns fewer.
Then insist on the operational part, which is where most check sets die. The checks must be runnable on a schedule by someone who is not an engineer, and the run must take under an hour. Written as a numbered list with test inputs stored in a shared folder, with a column to record pass or fail and the date. Run them at go-live, run them again two weeks later, then monthly. When a model version changes, when an upstream tool ships an update, when you edit a prompt, run the full set before you consider the change done. This is the mechanism that turns a static build into something you can safely modify, and it is the reason the check set matters more than the blueprint over a two-year horizon. The blueprint tells you what the workflow was. The checks tell you whether it still is.
Artifact three: a named owner, named in writing
Handoff is not a training session. Handoff is complete when one specific person, by name, can do five things without contacting the builder: run the acceptance checks, read the run history and tell a normal failure from an abnormal one, edit a prompt and re-verify it, rotate or replace a credential, and shut the workflow off cleanly, knowing what stops when it stops.
Name that person in the engagement scope before the build starts, because the choice changes the build. An operations manager who lives in your CRM will get a different implementation than a technical cofounder: fewer clever transforms, more legible steps, more comments in the places a human will actually look. A builder who does not ask who the owner will be is building for themselves.
The last item deserves emphasis, because it is the one people discover too late. Credentials and accounts must be yours. The API keys sit in your vault under your billing. The automation platform account is registered to your domain with your admin as owner and the builder as a removable collaborator. The model provider account is yours. If the engagement ends badly, or the builder simply moves on, nothing should break and nothing should require a password reset negotiation. Test this before final payment by removing the builder's access for one full business day and running the acceptance checks yourself. If everything passes, the handoff was real. If something breaks, you found out now, at zero cost, instead of during an outage.
What this looks like as a schedule
The three artifacts fit a 30/60/90 shape without stretching. First thirty days: pick one workflow, write the blueprint before writing any automation, and draft the acceptance checks from the blueprint. Drafting checks early is the forcing function, because a step you cannot write a check for is a step you have not specified. Days thirty to sixty: build against the blueprint, run the checks, revise both as reality intrudes, and name the owner if you have not. Days sixty to ninety: the owner operates it. Not shadows it, operates it, with the builder available but not touching. The access-removal test lands in this window.
Budget the owner roughly 2.5 hours per week during that last stretch. Some of that is running checks and reading run history, most of it is the small edits that reveal whether the handoff took. If nobody has that time, do not start the build. An unowned workflow decays into a thing everyone is afraid to touch, and afraid-to-touch is more expensive than not having it.
The questions to ask a builder before you sign
Ask these four, and read the specificity of the answers rather than the enthusiasm.
Show me a blueprint from a past engagement, redacted. If none exists, they do not write them. Ask what the acceptance checks looked like on your last build and how the client runs them now. Vague answers here mean the client is not running them, which means the client cannot change anything. Ask who owned the workflow ninety days after handoff and what they changed without help. A builder with real handoffs has a story, with a role and an example edit. Ask what happens to accounts and credentials at the end of the engagement, and listen for whether the default is your infrastructure or theirs.
We publish this standard because we build to it, and stating it plainly makes us easier to hold to it. The three artifacts are not a differentiator anyone should be able to claim as one. They are the floor. A build that clears it leaves you with a workflow you own, can verify, and can change. A build that does not leaves you with a dependency wearing the costume of an asset.