What is an AI harness, and when does it help your business?

The Friday afternoon problem

Picture a small electrical business in Hamilton. The jobs are finished, the van needs restocking and someone still has to turn a week of hurried notes into invoices. AI looks like an obvious way to get that last bit done.

Paste the notes into a chat window and it will probably produce something tidy. But which customer does each note belong to? Was that replacement part supplied or just discussed? Are those prices current? A polished paragraph won’t answer those questions for you.

This is the gap an AI harness is meant to close. It gives the model a defined job, supplies the right information, limits what it can do and checks the result before anything important happens.

What an AI harness actually is

The model is the part that interprets information and generates a response. A prompt tells it what you want. The harness is the surrounding software and workflow that makes the response useful in a real system.

That can include fetching approved records, calling a tool, keeping track of progress, checking a result and stopping for someone’s approval. A saved prompt can be part of it, but a prompt alone doesn’t enforce access permissions or prevent the same invoice being created twice.

The term appears often in software development. Anthropic’s work on harnesses for long-running agents, for example, describes using saved progress and verification to help coding agents work across sessions. The business examples here apply that broader idea to everyday administration; they’re proposed workflows, not claims about a ready-made product.

1. Define the jobOne clear task and a stopping point.
2. Supply the factsApproved records for that task.
3. Prepare a draftAI handles the language work.
4. Check the detailsSoftware checks IDs, amounts and missing fields.
5. Review and actA person approves the exact result.

You can trial parts of that process manually. Once you automate it, the important rules need to live in software outside the model. “Please be careful” is a request, not a control.

A Tradify and Xero example

Back to the electrician. Suppose the business already uses Tradify for jobs and Xero for accounts. Tradify has an established Xero integration. I’d work around that existing process first.

A sensible first task is preparing the invoice description from approved job notes. The model gets the notes for one job and a short example of the business’s writing style. It produces plain English describing the work recorded as completed. If the notes don’t establish whether a part was fitted, the draft flags that question.

The customer ID, job reference, quantities and prices come from the business records. Ordinary software checks them against those records; the model doesn’t make them up. The owner sees the draft beside its source notes, makes any correction, then uses the normal invoicing process.

There should be one route that creates the invoice. If Tradify is handling the transfer into Xero, a separate AI integration shouldn’t also create it. That’s an easy way to turn a time-saving idea into duplicate paperwork.

A custom Xero workflow is another possibility: its Accounting API supports draft invoices. That still needs an authorised integration, record checks and review. It isn’t something a chat window can do just because you mention Xero.

The useful gain here is less rewriting and copying. The harness keeps the job attached to the right customer and gives the owner a manageable decision to make.

A MYOB example: make the numbers easier to read

For a Wellington service business using MYOB, I’d consider a weekly receivables summary before automating customer correspondence.

An approved export or authorised integration supplies the relevant unpaid invoices. Software calculates the totals and ageing buckets for a stated date. The AI turns those checked figures into a short explanation, with invoice references the owner can follow back to the records.

It might say which invoices need a look. It shouldn’t invent a reason someone hasn’t paid, promise that money will arrive next week or send a collection email on its own.

MYOB’s invoice documentation covers different invoice layouts, so a custom integration needs to match the actual product and account. A workflow designed for Xero won’t automatically fit MYOB. These are examples using software familiar to NZ businesses, not built-in AI features being promised by either vendor.

Get the New Zealand details right

Small local settings can cause surprisingly large mistakes. Make NZD explicit. Show a date as “7 September 2026” when ambiguity matters. Use the business’s actual time zone, such as Pacific/Auckland, so a scheduled task accounts for daylight saving.

Keep tax calculations in the accounting software, with the business’s approved tax settings. IRD says GST-registered businesses charge 15% on most taxable supplies, but there are exceptions. A language model shouldn’t decide the GST treatment from a vaguely worded job note.

Privacy deserves the same practical care. For an invoice description, the AI may need the work notes without the customer’s phone number or home address. Send what the task needs. Check the provider’s retention, training-use, access and hosting arrangements before connecting customer information.

The Office of the Privacy Commissioner’s AI guidance recommends a privacy impact assessment before starting and regular updates as things change. Using a familiar NZ software brand doesn’t, by itself, establish where every connected AI service processes data or whether your proposed use meets your obligations.

Give the workflow rules it can actually enforce

I’d start with read-only access and drafts. Let the first version prove that it can help before giving it permission to change business records.

Be specific about the stopping conditions. A missing customer match goes to a person. An unknown price stays blank. A proposed bank-account change is outside the workflow. The approval screen should show the exact content and destination of an action; changing either should require a fresh review.

Emails and uploaded documents are source material, not instructions that can grant the system new permissions. The application should enforce allowed actions even if the model produces something unexpected.

Retries matter too. If an integration times out, it must check whether the action already succeeded before repeating it. Keep a job reference and returned record ID, and use the platform’s duplicate-prevention features where available. Record enough to investigate a failure, while avoiding unnecessary personal information in logs.

Have an obvious pause switch and a normal manual way to finish the job. Someone also needs to own failed runs, connection changes and updates to the instructions. Otherwise the maintenance work quietly lands on whoever notices the problem first.

Measure the finished job, including the tidying up

Before paying for a large build, try a small set of representative tasks. Twenty or thirty is a reasonable starting point for a pilot, with straightforward examples and awkward ones. That’s enough to expose some practical problems; it isn’t proof that a rare error can’t happen.

Run the same tasks through the current process and the proposed one. Keep customer data out of an unapproved test environment. For each task, record:

• Total staff time, including checking and corrections.
• Whether the result was accepted without changes.
• Wrong customers, amounts, missing facts or duplicate actions.
• The software and model cost per completed job.

A fast draft that takes longer to check than to write has failed the test. So has a system that saves a few minutes on ordinary jobs but creates hours of work on unusual ones.

Keep a small set of known examples to rerun when the model, instructions or integration changes. A second AI reviewer can help spot issues, but it can also share the first model’s blind spots. It doesn’t replace checking the source records.

Start with the admin job you keep putting off

My starting point would be one recurring task, one person responsible for it and a clear definition of “done”. Drafting job descriptions or explaining a checked report gives you something useful to test without handing over the whole business.

Sometimes the answer is already in the software. If the problem is moving an invoice from Tradify to Xero, configure that existing connection before adding AI. A fixed rule or a decent form may solve the problem more cheaply. Anthropic’s guidance on building effective agents makes a similar case for starting with the simplest workable approach.

If you’re still choosing tools, the NZ small-business software guide covers the surrounding systems. For a smaller first experiment, try the practical prompts for everyday admin.

And if there’s a particular job you’d like to make less painful, tell me about the workflow. Which information goes in, what needs to come out and where does someone currently have to stop and fix it? Those details are a much better starting point than buying another AI subscription.