How an engagement runs. Including the parts that go wrong.

Four stages, each with its own deliverables and its own exit.

A process canvas built from sticky notes on a wall
1

Audit & design

Blueprint

Process mapping, a systems audit, maturity scoring and a costed roadmap. Ends with a decision you can act on.

You can stop here
2

Evaluation

Pilot report

One workflow measured against acceptance criteria you set first. Failure modes documented. A go or no-go with the reasoning shown.

You can stop here
3

Deployment & training

Runbooks and trained operators

Full build with your people in it. Two of your team finish able to run, break and repair the system without us.

Our access ends on a set date
4

Next steps & support

Roadmap and an optional capped retainer

What we built, what we deliberately didn't, and what your team should consider next.

Expires; doesn't auto-renew

Three things we do, in that order, usually.

Most clients start with the first and find that half of what they assumed needed AI didn't.

Getting to L1

Process optimization

Map what actually happens, including where it departs from the SOP. Often this alone returns the hours.

L1 to L2

Automation

Deterministic workflows across the systems you run today, without a migration project hiding inside them.

L2 to L3 and L4

Agentic workflows

Agents for work with real variance. Start read-only, summarizing bottlenecks and recommending. Add autonomy as they earn it.

Automation or AI: they are not the same purchase.

Much of what gets sold as AI is a rule with a language model bolted on. It costs more, fails less predictably and is harder to audit. Our default is the simplest mechanism that holds.

Use automation when

Inputs are structured and you want the same answer every time. Cheaper, faster, and it fails in ways you can debug at two in the morning.

Use an agent when

The variance is real: messy documents, open-ended customer messages, drafting from context. Bounded scope, defined thresholds, a person accountable.

Use neither when

The process runs twice a quarter, or it's about to change, or the real problem is that two teams disagree about who owns it. We'll tell you when that's what we found.

Failure is designed before the happy path is built.

The question isn't whether an automated system will get something wrong. It's whether you find out, how fast, and whether you can undo it.

Thresholds before actions

Every decision type gets a confidence threshold and a named human owner. Below it, the system stops and asks. You approve those numbers first.

Fail closed, and loudly

When a step can't complete, the system halts and raises rather than guessing. Silent partial success is the expensive failure mode.

Reversible by design

Anything writing to a system of record can be rolled back, and the rollback is tested during the pilot rather than assumed.

You can see what it did, every time, in plain language.

Every agent writes a readable trail: what it was asked, what it looked at, what it decided, how confident it was, and who signed off. This is a sample run.

Invoice exception agentrun 4,182Sep 14, 09:12
  1. Triggered by new invoice INV-88214 from Meridian Freight, $14,320.
  2. Compared line items to PO-5561. One line ("fuel surcharge", $1,180) had no PO reference.
  3. Checked contract terms. Surcharge permitted to 6% of freight value; this is 9%.
  4. Confidence 0.71: below the 0.85 threshold for auto-approval on this decision type.
  5. Halted and escalated to the AP lead with the clause and calculation attached.
  6. Resolved 09:41: approved at the contracted rate; excess rejected by a person.

You choose the stack; we optimize what's in it.

We don't have a platform to sell you, so the recommendation is never self-interested. We start with what you have, and we say plainly when something else would work better.

Start with what you own

The first question in every Survey is what your current systems can do that nobody switched on. On most engagements a meaningful share of the roadmap turns out to be capability you're already paying for.

We'll tell you when something better exists

If a different tool would remove a real roadblock, we show you the case, the cost and the switching effort. We take no margin on anything we recommend.

The decision stays yours

We won't smuggle a migration into an automation proposal, and we won't hold out on a better answer to protect a simpler scope.

Change management is in scope

A system nobody adopts has a negative return. Training and the conversation with people whose jobs change are part of the build.

Thirty minutes. Worst case, you lose half an hour.

Bring one process. You leave knowing which level it's on, what to fix first, and whether it's worth doing anything at all.