AI agent development.

AI agents connected to the business software you already run

The value of an AI agent comes from what it can read and do in your systems. We build agents for New Zealand organisations that connect to accounting, CRM, help desk, document and job management software through official APIs, webhooks and Model Context Protocol (MCP) servers:

Every connection follows the same rules: the agent gets the narrowest access the task needs, reads before it writes, and anything that changes records or contacts a customer goes through a person.

When you need an agent, and when you do not

You need an agent when the steps to finish a task vary from case to case and depend on what is found along the way: which records to check, which person to contact, whether to escalate. If the steps are the same every time, build a workflow automation instead. It will be cheaper, faster and easier to test. Our lesson on when a workflow does not need an agent gives the test.

Agents are still early in New Zealand. Datacom’s 2026 State of AI Index, a vendor survey of NZ organisations with 100 or more staff, found 13% using agentic or autonomous AI. Good first candidates share three traits: a queue of similar but not identical cases, information spread across two or more systems, and an outcome a person can check quickly.

• Accounts receivable follow-up across an accounting system and an inbox.
• Maintenance or service requests that need records checked before a job is raised.
• Research tasks that gather and rank evidence from several sources.
• Internal admin that crosses a CRM, a document store and email.

Agent boundaries: the design document

Before any code, we write down every tool the agent may use and what it is allowed to do with it. Illustrative example: an accounts receivable agent for a New Zealand wholesaler on Xero.

Two rules shape every table like this. An agent never gets a tool it does not need for the task. Anything irreversible, financial or legally significant goes to a person. Our engineering guide to agent permissions and approvals goes deeper.

What you receive

Agent specification

The goal, the tools, stop conditions, escalation rules and what success looks like for one task.

Tool layer

Narrow API wrappers or MCP servers for each system, with a dedicated service identity and scoped credentials.

Approval interface

Where staff see the agent’s proposed action, its evidence and its reasoning, and approve, edit or reject.

Evaluation suite

Real historical cases with expected outcomes, scored on task success, wrong actions and cost.

Observability

A trace of every step, tool call and decision, searchable when someone asks why the agent did something.

Cost controls

Step limits, per-task and daily spending caps, and alerts.

Ownership plan

A named business owner, a technical owner and an incident process.

How we build an agent

1. Discover: write the task down. Collect 50 to 100 real cases, including the hard and ugly ones, and agree what a correct outcome is for each.
2. Prove: read-only first. Build the agent with read tools only and run it on historical cases. Measure whether it reaches the right conclusion before it is allowed to touch anything.
3. Prove: add actions behind approvals. Introduce draft and act tools, each behind human approval, and pilot on live work. Approval and edit rates show where it is weak.
4. Scale: relax approvals by action type. Where the record supports it, low-risk actions move from approval to sampling. Irreversible ones never do.

Evaluation and operational ownership

An agent is evaluated on whole tasks, not single answers. We track task completion, wrong or unnecessary tool calls, unsupported claims, escalation accuracy, and cost and time per task. The suite reruns on every model, prompt or tool change, so an update that quietly makes the agent worse is caught before release. Our engineering guide to AI agent evaluations shows the method, and LLM evaluation services covers it as a standalone engagement.

After launch, ownership is explicit: the business owner decides what the agent may do, the technical owner keeps it running, and both see the same weekly numbers.

What drives the cost

The drivers are the number of tools and systems, the approval interface, building a good evaluation set, and model usage. Agents make many model calls per task, so usage matters more than for a single-step automation. As an illustration with assumed numbers: 12 model calls per task at about 6,000 tokens each is 72,000 tokens; at an assumed blended rate of US$5 per million tokens, that is about US$0.36 per task, or roughly US$720 a month at 2,000 tasks. Check current vendor pricing before relying on a figure. See what custom AI projects cost and test your case in the AI ROI calculator.

Agents we have built and studied

• The Property Management Agent for APL Property is an internal AI agent that handles routine administration for a regional NZ property firm, covering email triage, records, orders and follow-up, with staff keeping the decisions.
• Bebop is an AI sales agent for small and medium businesses, owned and sold by Blackpearl Group (NZX/ASX: BPG). Levy Street engineers work with Blackpearl Group’s AI team on Bebop.
• GTM-Bench is a 72-task benchmark for AI agents doing go-to-market research, published by Blackpearl Group in June 2026 and co-authored by Levy Street team members. It scores every result an agent returns and subtracts points for those below its quality bar, and the paper reports many generalist agents scoring negatively. That is how we evaluate agents: volume of output is not success.

Where agents go wrong

• Prompt injection. An email or document contains instructions the agent follows. Treat all retrieved content as data, and keep permissions narrow so a hijacked agent cannot do much.
• Loops and runaway cost. An agent retries the same failing step. Step limits and budget caps stop it.
• Overproduction. The agent returns fifty weak results instead of five good ones. Score usefulness, not volume.
• Permission creep. Tools get added for convenience. Review the boundary table before each release.
• Silent failure. The agent stops picking up work and nobody notices. Monitor throughput, not just errors.

New Zealand specifics

• Human review. The Privacy Commissioner’s AI guidance expects human review before acting on AI outputs. Agents that touch personal information are designed around the 14 information privacy principles, including IPP 3A since 1 May 2026 if the agent gathers information about people from other sources.
• Data location. Anthropic’s own API offers only US or global processing, while Amazon Bedrock’s AU profile keeps Claude processing in Australia and New Zealand. We record where each agent’s data goes.
• Local systems. Most agents we scope touch Xero, MYOB, Microsoft 365 or a job management system such as ServiceM8.

Written by the Levy Street team in Wellington. Last updated 19 October 2026.