AI automation · New Zealand
AI that does the work, not a chatbot bolted on.
Most AI you can buy is a chat widget stapled to a website. This is the other kind — LLMs, retrieval over your own data and custom agents wired into the workflows your business actually runs, built by a senior engineer who’ll also tell you, plainly, where AI doesn’t belong.
In short
What AI automation and agent development actually mean
AI automation means putting a language model to work inside a real process — reading a document and pulling out the fields you need, drafting a reply grounded in your own records, triaging an inbox, or running a multi-step task end to end — instead of leaving a person to do it by hand. Agent development is the step past a single prompt: a model given tools it can call (search your database, look up an order, create a ticket, hit an API) and the logic to decide when to use them, with guardrails and a human in the loop where the stakes need one. Done properly it’s ordinary software with a model as one component, engineered, tested and observable — not a demo that works once and hallucinates on Tuesday. For a New Zealand business sitting on a genuinely repetitive knowledge task, it’s often the difference between hiring for that work and having software do the first 80 percent of it.
What we build
What we build with AI
Practical AI engineered into the workflow — not a generic assistant, not a widget. Most projects are one of these, or a few combined.
LLM integrations in your product
A model wired into an existing app or a new one through a proper API — Claude, GPT or Gemini via the Vercel AI SDK — with streaming, structured JSON output, retries and cost controls, so the AI is a reliable feature rather than a science experiment.
Retrieval over your own data (RAG)
Answers grounded in your documents, records and knowledge base instead of the model’s guesswork: embeddings and vector search on pgvector, hybrid keyword-plus-semantic retrieval, reranking and citations back to the source so replies are checkable.
Document & email processing
Invoices, PDFs, forms and inbound email read and turned into structured data — extraction, classification and routing — with the low-confidence cases flagged for a human rather than silently pushed through.
Custom agents & tools
A model given real tools it can call — query a database, look up a customer, create a record, hit your Xero or CRM — inside a controlled loop with permissions, step limits and an audit trail, for multi-step work a single prompt can’t handle.
AI-in-the-loop workflow automation
The repetitive pipeline automated end to end, with the model doing the judgement step it’s good at — summarising, drafting, categorising, deciding — and deterministic code handling everything that must be exact.
Evals, guardrails & observability
The unglamorous part that makes AI trustworthy in production: a golden set of test cases, regression checks when a prompt or model changes, input and output guardrails, and tracing so you can see what the model actually did and what it cost.
In depth
How to think about building with AI
Where AI earns its place — and where it doesn’t
AI earns its place on tasks that are fuzzy, language-shaped and tolerant of a review step: reading messy documents, drafting from a template, summarising a long thread, classifying free text, answering questions over a pile of your own material. It’s the wrong tool where the answer must be exact and provable — totals, tax, eligibility rules, anything with a right answer a database already knows. The honest failure mode is using a probabilistic model for a deterministic job and then bolting on checks to catch it being confidently wrong. The good pattern is the opposite: let ordinary code do everything that must be exact, and hand the model only the genuinely ambiguous judgement, with its output grounded and checkable. Most real systems are 20 percent AI and 80 percent boring, reliable software — and that ratio is a feature, not a shortcoming.
When you don’t need AI at all
Plenty of “AI” problems are really just automation problems wearing a hat. If the rule is “when a Xero invoice is approved, create the job and email the customer,” that’s a deterministic workflow — an integration, not a model — and it’ll be cheaper, faster and correct every single time, which AI won’t be. If a handful of your staff occasionally need to summarise or draft, an off-the-shelf ChatGPT or Copilot subscription is the right answer and I’ll say so rather than build you a bespoke version of a tool you can rent for a few dollars a seat. Custom AI is worth building when the task is high-volume, specific to your data, embedded in a workflow, and language-shaped enough that plain rules can’t express it. If it doesn’t clear that bar, the responsible recommendation is the simpler, boring option — and you’ll get it from me straight.
Retrieval over your own data (RAG), engineered properly
A model on its own only knows its training data and whatever you paste into the prompt; it does not know your contracts, your product docs or last week’s tickets. Retrieval-augmented generation fixes that by fetching the relevant pieces of your own material at question time and grounding the answer in them. Engineered properly that means real work: sensible chunking of your documents, embeddings stored in pgvector on Postgres, hybrid search that combines keyword and semantic matching so exact terms aren’t lost, a reranking pass to put the best passages first, and citations so every answer points back to its source and a human can verify it. It also means being deliberate about data: your content stays in your own database, API calls go to providers under zero-retention terms so nothing is used to train their models, and where the data is sensitive enough to warrant it, self-hosting an open model is on the table. RAG is where most “the AI made something up” problems are actually won or lost.
Agents, tools and when a single prompt is enough
An “agent” is a model that can call tools and loop — decide it needs to look something up, call a function to do it, read the result, and carry on until the task is done. That’s genuinely powerful for multi-step work: “find this customer’s last order, check stock, and draft the reply.” It’s also more to get wrong, so the engineering matters. Tools are defined with strict schemas and structured outputs so the model returns data your code can trust; every tool runs with real permissions and validation, not blanket database access; the loop has step and cost limits so it can’t run away; and anything irreversible — sending, charging, deleting — goes through a human confirmation rather than being left to the model’s discretion. Plenty of jobs don’t need an agent at all: a single well-constructed prompt with structured output is simpler, cheaper and easier to test, and simpler is the default until the task actually demands more. Part of the work is knowing which one you’re looking at.
Who you actually work with
Not an account manager reselling someone else’s API — Isaac Vicliph, a senior software engineer with a decade shipping software in financial services, designing and writing the code himself. That background matters here specifically: financial systems taught the habits AI needs to be safe in production — validation, audit trails, guardrails, and a healthy distrust of anything that’s confidently wrong. You get one accountable person from the first scoping call to launch, honest advice about where AI helps and where it’s the wrong tool, and a system you own outright at the end — models called through your own API keys, not locked behind a subscription to me. NZ-based, priced in NZD, GST-registered.
How a project runs, and how it’s priced
We scope before we quote. The first conversation is about the actual task — the volume, what the data looks like, where a wrong answer costs you, and whether AI is even the right tool — and it’s a conversation where “you don’t need AI for this” is a real possible outcome. Often the right first step is a small proof of concept on your real data: enough to see whether the accuracy is genuinely useful before anyone commits to a full build, because AI quality is empirical and worth measuring rather than promising. From there you get a written plan — what gets built, which models and providers, how it’s evaluated, what you own — and a fixed price for that scope. No hourly meter, no open-ended estimate. A single document-extraction pipeline is a smaller job than a multi-tool agent, so rather than publish a number that’s wrong for your project, you get a firm one once the work is understood.
Reviewed July 2026 · written by Isaac Vicliph, Tally Digital
Questions
Frequently asked
What is AI automation?
Putting a language model to work inside a real business process — reading a document and extracting the fields you need, drafting a grounded reply, triaging an inbox, or running a multi-step task end to end — instead of a person doing it by hand. Done properly it’s ordinary software with a model as one tested, observable component, not a chatbot widget bolted onto a website.
What is RAG, and why does it matter?
Retrieval-augmented generation. A model on its own doesn’t know your documents, records or knowledge base — RAG fetches the relevant pieces of your own data at question time and grounds the answer in them, with citations back to the source so replies are checkable. It’s how you get AI that answers from your material rather than making something up, and it’s where most hallucination problems are actually solved.
How much does AI automation cost in New Zealand?
It depends entirely on scope — a single document-extraction pipeline is a very different job from a multi-tool agent, so a blanket price would mislead. We scope your actual task first, often start with a small proof of concept on your real data, then give you a fixed price for the build before any commitment. There are also ongoing model API costs, which we design to keep predictable. Tell me the task and you’ll get a firm number back.
How do you stop the AI making things up?
Several ways, layered. Grounding answers in your own data with retrieval and citations so the model works from real sources rather than guessing; strict structured outputs so responses fit a schema your code can validate; letting deterministic code handle anything that must be exact; a golden set of test cases with regression checks when a prompt or model changes; and a human review step on anything low-confidence or irreversible. You can’t make a language model perfect, but you can engineer the system so its mistakes are caught rather than shipped.
Is our data safe, and do you train models on it?
Your content stays in your own database. Calls to model providers go under zero-retention terms, so your data isn’t used to train their models, and where information is sensitive enough to warrant it we can self-host an open model so nothing leaves your infrastructure at all. Access to tools and data is scoped and permissioned rather than wide open. Data handling is part of the scoping conversation, not an afterthought.
Do we actually need AI, or would simpler automation do?
Often simpler automation is the right answer, and you’ll hear that plainly. If the rule is fixed — “when this happens, do that” — it’s a deterministic workflow or integration, which is cheaper and correct every time in a way AI won’t be. If a few staff occasionally need to draft or summarise, an off-the-shelf ChatGPT or Copilot subscription beats a custom build. Custom AI is worth it when the task is high-volume, specific to your data, and genuinely language-shaped. If it doesn’t clear that bar, I’ll tell you.
Which models and providers do you use?
Whichever fits the task — Anthropic’s Claude, OpenAI’s GPT and Google’s Gemini are the mainstream choices, usually through the Vercel AI SDK so the code isn’t locked to one vendor and can route cheaper work to smaller models. Where data sensitivity or cost calls for it, self-hosting an open model is an option. The models are called through your own API keys and accounts, so you own the system and aren’t dependent on a subscription to me.
Are you an AI developer or a marketing agency selling AI?
A senior software engineer who builds AI into real software — LLM integrations, retrieval, document processing and custom agents, engineered and tested — not an agency selling AI-flavoured content or a rebadged chatbot plugin. You talk to the person who designs and writes the code, and part of what you’re paying for is honest advice about where AI is and isn’t the right tool.
Tell me the repetitive task you think AI could handle.
The documents someone reads by hand, the inbox that gets triaged the same way every time, the questions your team keeps answering from the same pile of files — tell me the task and I’ll tell you honestly whether AI earns its place, then scope the smallest build that does the job.