General Competence

Imagine a founder watching an AI tool prepare a customer proposal. The draft appears quickly. She corrects a service detail, adjusts a delivery commitment, and reminds it that this customer has different payment terms. A few minutes later, the proposal is ready.

That is a useful result. It leaves an important question unanswered: could the next proposal reach the same standard without her sitting beside it?

The distinction matters when deciding whether to give AI a larger role in a business. A demonstration shows what is possible under the conditions of that demonstration. Delegation requires confidence in what will happen during an ordinary working week.

What happens when you step away?

When you hand work to a capable colleague, you expect them to understand the assignment, find the information they need, and recognize when something requires your attention. You also expect them to tell you if the job cannot be completed.

Those are useful expectations for an AI-supported workflow.

Here, general competence means dependable performance within a defined responsibility. Routine work moves forward. Unusual situations reach someone who can resolve them. Missing information stays visible. A task is reported as complete only when there is evidence that the required work happened.

The proposal example above is illustrative. The founder may be supplying knowledge the system cannot access, or making a decision that should always remain hers. Understanding that difference determines what can be delegated.

Your corrections reveal what the business relies on

Experienced people make small interventions throughout the day. They remember a customer agreement, notice an unrealistic deadline, or know that a particular request needs approval.

These interventions are easy to overlook because they feel obvious to the person making them. Yet they can carry the knowledge that makes a process work.

Before expanding an AI workflow, record the corrections people make across a sample of real tasks. Look for recurring patterns.

A repeated correction to pricing may point to an unreliable source. A recurring question about who should act may reveal unclear responsibility. A request involving an unusual customer commitment may genuinely need a senior decision.

Each finding calls for a different response. Some require better information or a straightforward rule. Others require a clear approval step. The aim is to make those requirements part of how the work operates.

Give responsibility a clear boundary

“Handle customer proposals” leaves a great deal open to interpretation.

A more useful assignment establishes which information can be used, which terms are standard, who can approve exceptions, and what must happen before a proposal is sent.

Within that boundary, the system can take on meaningful responsibility. It might assemble the relevant records, prepare the proposal, check required details, and route an unusual commitment to its owner.

The person receiving that exception should have enough context to decide. They should be able to see what is unusual, what the customer has requested, and what accepting it would mean.

Good delegation preserves access to judgment while reducing the need for someone to supervise every routine step.

Test an ordinary working week

Before relying on the workflow more broadly, examine how it handles the situations your team actually encounters.

Include a straightforward request, an incomplete one, a changed instruction, and a case where a required system is unavailable. Keep existing approvals in place while assessing the results.

Watch whether the work reaches an acceptable standard, whether exceptions reach the right person, and whether the team can see what remains unfinished. Measure the time people spend intervening alongside the result delivered.

A successful pilot should provide evidence about the responsibility the system can carry and the support it still needs. That gives leadership a practical basis for deciding what to expand, what to improve, and what should remain with a person.

For a closer look at measuring preparation, checking, and follow-up, read “Why your AI workflow still needs so much supervision.”

Build reliability into the way work happens

This is where Rivington’s work begins. We examine how a recurring workflow operates, identify the knowledge and decisions it depends on, and redesign it around clear responsibilities and useful checks.

The AI Workflow Diagnostic provides the starting point: one workflow examined over three weeks, with a practical redesign and implementation roadmap. Implementation and ongoing support are scoped separately. Depending on the work, delivery can involve Rivington, the client’s team, or specialist technical partners.

As the business changes, those arrangements need attention. New services, different customer requirements, and changes in ownership can all affect what the system needs to know and when it should ask for help. Ongoing support keeps the solution aligned with the work it is responsible for.

The practical test is whether work can move forward reliably while your attention is elsewhere, with the decisions that need you arriving clearly and in time.