AI automation

Every engagement follows the same order: diagnose, deploy, run. You can stop after any stage and keep what that stage produced, so stopping early never wastes the money already spent.

The last row is the other way in. When the audit finds that the blocker is tooling (request types, permissions, automations nobody owns), the fix is a fixed-scope Systems project, and it can roll into an AI build once the ground is ready.

Embedded is a working arrangement with four conditions, and I state them before anything is signed:

• Two to three days a week inside your tools. I work in your Slack or Teams and in your Jira or Monday, not in a separate portal you have to remember to check.
• A named process owner on your side. Without one, I do not start. The owner decides what the process should do; I make it do that.
• A weekly demo of working software. You see the thing running against your own data every week, never a status report about it.
• Access through accounts you control. Your data stays in your systems, and you can switch my access off in one place.

Most AI pilots I get called into failed before the model mattered. Retrieval returned documents a user should never see because permissions were inherited wrong. An agent changed configuration and nobody could say what it changed. An automation ran for months with no owner. None of those is a model problem.

Camunda’s 2026 survey of 1,000 process decision makers at companies with 1,000+ employees reports that "72% of organizations say process-related challenges have caused AI initiatives to fail" (Camunda press release, 9 September 2026). That sample is enterprise. In a mid-market team of 50 to 500 people the gap is the same kind, but it is easier to see, because one person can still describe the whole process end to end.

I run every engagement on a method I call Supervised AI Delivery. It turns four principles into practice: a baseline before writing anything, a legible plan, business decisions kept with humans, and every change auditable and reversible. The audit sets the baseline; a deployment runs plan, approve, execute; the retained stage keeps the audit trail.

Here is an illustrative plan card, with made-up numbers, in the shape every change takes before it runs:

A plan is written so the person approving it does not need to read code. The full reasoning behind the principles is in the guide on supervised AI administration.

Configurations I make in your systems belong to you. Forge apps and AI engines are either handed over, with the source code deployed to your own developer site, or kept and run by me under an ongoing arrangement; we agree which in the engagement contract, and neither is the default.

Saying no early saves both of us an audit fee. I am the wrong choice for:

• Teams that want a chatbot demo for a board meeting.
• Companies with no process owner and no access to their own data.
• Projects that need a ten-person team or round-the-clock support.
• Problems a configuration change or an off-the-shelf app already solves. The audit will tell you so, and that answer is part of what you pay for.

Deployments are scoped and priced at the end of the audit, once both of us know what the build actually involves. A typical range will appear here after three have shipped, not before.

Viter is one engineer. The person on the first call is the person who maps your process, writes the plan and ships the build, so nothing is lost in a handover between sales and delivery. My background is ten years of running Atlassian and operations tooling, including as internal Jira lead at Aroundtown, and AI builds for clients such as Auditlab, where a plain-language query engine inside Jira saves 70 hours of audit work a month.