What you need done in your business, we make it happen.
What an agent is at Spark.
Not a chatbot. An agent is a designated input with the goal of a designated outcome, and it thinks its own way there. Four things make it one of ours.
A designated input, a designated outcome
It starts from something defined, such as a new lead, a quiet quote or a job brief, and works until a defined outcome is reached. That is what lets us write its rules, test it and know when it is done.
It reasons and solves problems
It plans the steps, reads what comes back from your systems and changes course when something doesn't fit. It works the problem, rather than following a fixed script.
Memory and learning loops
It remembers what it has done and what it has learned from outcomes and corrections, so each run starts from more than the last one did.
Autonomous, locally or in the cloud
It runs on its own, hosted in the cloud or locally on your own hardware, reading and writing your live records inside the guardrails you set.
Seven layers in every agent we build.
From what wakes it up to how it gets better with use. Scroll to follow one run round the loop, or pick a stage to read how we build it.
Trigger
Cron, API call or business event
Triggered by a schedule (cron), an API gateway call or a business event: a new lead lands, a reply comes in, a quote goes quiet.
In the example runThe 9:00am schedule fires. It reads 40 of Harbour Plumbing & Gas's invoices and finds 13 past due.
- Schedule
- A morning brief, a Friday review, a nightly check
- API gateway
- Your app or another system calls the agent directly
- Business event
- A webhook from your CRM, inbox or phone system
- How we build it
- Every trigger is checked before work starts, and each one is built so the same job is not run twice.
Role and rules
Instructions engineered and tested
A designated input and a designated outcome, written as a structured role prompt: who the agent is, what good looks like, and the rules it never breaks.
In the example runIt loads its instructions: friendly and firm, under 90 words, never change an amount, never chase a disputed invoice. A payment plan is drafted as an offer for Kate's sign-off.
- Instruction set
- Eight parts: role, goal, context, rules, tools, output format, examples and tests
- Guardrail rules
- Every “never” is written down and checked by a test
- Test sets
- Tested against worked examples before it ships, and again when the instructions change
- How we build it
- We engineer instructions the way we engineer code, and we test them the same way.
Context
Prompts, instruction files, knowledge and memory
Before it acts, the agent loads what it needs to know: a structured prompt, the Markdown instruction files that hold its playbook, your business knowledge, live records from your systems and memory from earlier runs.
In the example runIt loads its instruction file and Harbour Plumbing & Gas's payment terms, reads each invoice, the job behind it and the last email, and remembers that Owen Grant usually pays after one nudge.
- Prompting
- A structured system prompt sets its role, its goal and the shape of its output
- Instruction files
- Markdown files hold the playbook, the rules and worked examples, versioned and reviewed like code
- Knowledge
- Your price lists, policies and FAQs, plus live records read fresh from your systems
- Memory
- What happened last time, and lessons learned from outcomes and corrections
- How we build it
- Agents get the context the task needs and nothing more, so every answer traces back to a source.
Tools
Look up freely, act on purpose
The agent works through defined tools that wrap your systems: CRM, email, calendar, payments, voice and web. It plans each step, acts, checks the result and changes course when something doesn't fit.
In the example run5 scoped tools: read the invoice, find the contact, draft the reminder, send it from accounts@, approved templates, or a draft Kate has signed off and add a note to the job. Nothing else is in reach. One invoice was paid this morning, so it skips that one and carries on with the other 12.
- Look up
- Find a contact, read a thread, check a calendar
- Act
- Send, book or raise, each through a tool built for that one action
- Scoped access
- Every tool is scoped to exactly what it should touch
- Plan, act, check, adjust
- Long jobs save their progress and resume cleanly. When a step fails, it works out why and tries another route
- How we build it
- Each action runs through its own tool, and the guardrails check every call before it is carried out.
Guardrails
Security, configuration, compliance
Security, configuration and compliance controls over every run. If the system can't confirm a control, the agent doesn't act.
In the example runEvery reminder passes the checks: an existing client, inside business hours, within the daily limit. The one payment plan offer goes to Kate for sign-off.
- Off switches
- One master switch and one per agent, with the reason shown
- Limits and hours
- Daily usage limits, and nothing sent outside business hours
- Approval, where you need it
- Risky actions can require human approval where you need it
- How we build it
- Where approval is on, it is tied to the exact content and recipient, and sending is built so the same send is not made twice.
Outcome
The defined result, delivered
The run ends when the designated outcome is reached, not when the agent runs out of steps. Every item is accounted for: done, skipped with a reason, or handed to a named person.
In the example run12 reminders sent and noted on the jobs, one skipped because it was paid, and the payment plan offer signed off by Kate. Every overdue invoice is accounted for.
- Defined done
- Written into the agent's goal before it ships, so finished is never a judgement call
- Written back
- Results land where your team looks: the job, the CRM record, the inbox
- Nothing dropped
- Anything it couldn't finish is handed to a named person, with the reason
- How we build it
- Each outcome is checked against the goal and tested like any other output.
Logging and learning
Logged, audited, costed, improved
Every run is logged and audited, with its cost. Outcomes and human corrections are analysed and fed back into the agent's instructions, so it improves with use.
In the example runThe run is logged with its cost and every reminder it sent. Owen pays the next day, and that outcome goes into memory for the next run.
- Learning loops
- Each lesson is checked and the test set rerun before it goes live
- Alerts
- A failure alerts a person, and a watchdog catches runs that never happened
- How we build it
- Outcomes feed the agent's memory and instructions, so it gets better with every run.
One run, start to finish, with the guardrails in control.
Guardrails are security, configuration and compliance controls that sit over every run. Follow one: the agent works through the job on its own, and each control does its part along the way.
An input and an outcome
Overdue invoices in, every overdue account followed up out.
New run9:00am- TriggerWeekdays at 9:00am
- InputInvoices past their due date
- OutcomeEvery overdue account followed up
- HostedCloud, Australian region
Every tool is scoped
The agent gets the context and tools the job needs, and nothing more.
Tools this agent can use9:00am- Read the invoiceAllowed
- Find the contactAllowed
- Draft the reminderAllowed
- Send it from accounts@, approved templates, or a draft Kate has signed offAllowed
- Add a note to the jobAllowed
- Pricing, payroll, other recordsOut of reach
The agent gets on with it
It plans its own steps and adjusts when a record doesn't fit.
Working9:02am- Reads 40 invoices, finds 13 overdueDone
- One was paid this morning: skipped, no reminder neededDone
- Matches each to its job and contactDone
- Drafts 12 reminders in Kate's voiceDone
Policy checked before anything goes out
Security, configuration and compliance controls run on every action.
Policy check9:04am- Every recipient is an existing clientPassed
- Inside business hoursPassed
- Within the daily send limitPassed
- Amounts match the accountsPassed
Sign-off, only where you want it
An optional control you set per action. Everything else flows straight through.
Approval rule: payment plans9:05am- 11 routine remindersSent
- 1 payment plan offer, Lena MarshApproved by Kate
Kate switched sign-off on for payment plans. Routine reminders don't need a person.
Finished, logged, learning
Every run is recorded with its cost, and outcomes improve the next one.
Run complete9:06am- 12 reminders sent from accounts@Done
- Notes added to 12 jobsDone
- Run logged and audited, with its costDone
- Outcomes fed back into memoryDone
- Off switchesOne master switch for every agent, and one for each agent.
- Limits and hoursDaily usage limits, and nothing is sent outside business hours.
- Approval, where you need itSwitch it on and risky actions, such as client emails, invoices and deploys, require human approval, tied to the exact content and recipient.
- Fail closedIf the system can't confirm a control, the agent doesn't send.
Wired into the tools you already run.
An agent is only useful if it can reach your records. We connect it the way each system allows, and every tool is scoped to exactly what it should touch.
- APIs
- REST and GraphQL, with OAuth 2.0 or API keys. We work from the OpenAPI spec, map the data between systems, and handle retries and rate limits so records stay in step.
- MCP
- Agents can also call tools over the Model Context Protocol, the open standard AI agents use to find out what a tool does and then use it.
- Webhooks
- Your tools tell the agent the moment something happens: a form is sent, a call ends, a reply lands. Webhooks we receive are verified before any work starts, using the sender's signature wherever it offers one.
- CRM, email and calendar
- The tools your team already lives in, connected through their own APIs, so the agent reads the real record and writes back where your team will look.
{
"name": "send_quote_follow_up",
"description": "Email one customer about one open quote",
"inputSchema": {
"type": "object",
"properties": {
"quote_id": { "type": "string" },
"body": { "type": "string" }
},
"required": ["quote_id", "body"]
},
"annotations": {
"readOnlyHint": false,
"destructiveHint": true
}
}Each action is its own tool, described so the agent knows exactly what it does and scoped to one quote and one customer. The guardrails check every call before anything goes out.
- Or anything with an API
A few straight answers.
- How much does an agent do on its own?
- The whole job, from its input to its outcome, inside the guardrails you set. You choose whether any action needs a person's sign-off. Most don't.
- What if an agent gets something wrong?
- If a check doesn't pass, it doesn't act, and a person is alerted. Every run is logged with its cost, and each correction is tested before it changes the agent's instructions.
- Which AI models do you use?
- The right one for the job: frontier models from Anthropic, OpenAI, Google, Meta and Mistral, or a small local model where privacy or cost calls for it. The same instructions, guardrails and logging apply either way.
- Where does our data live?
- On Vercel and Supabase by default, in an Australian region where needed, or in your own cloud. On that default stack, data is encrypted in transit and at rest.
Related services
Tell us what you need done.
Describe the outcome you want and the systems it touches, and we'll show you how we'd build it.
Or email jack.west@sparkintegrations.com.au