Surry Hills, Sydney
An AI agency in Sydney that starts with the job
An AI agency should be able to name the job the model is doing before anyone discusses the model. Tonic is a Sydney studio that designs and builds those jobs: a chatbot with a boundary, an integration into a system you already run, or a product feature with a user and a failure mode. Strategy, interface and engineering are in-house.
Who this is for
This page is for teams who have a task that might be done with AI and want a studio that will also say when it should not. If you need a website with no intelligent feature, that is a web brief. If you need a campaign, that is a creative brief.
Support or sales repeating the same answers
A chatbot is worth scoping when the questions are known, the source of truth exists, and a human still owns the cases the bot must refuse.
A product that needs one intelligent step
Search, summarising, classification or a recommendation inside a flow you already have. AI integrations put that step in the product instead of beside it as a demo.
A use case no off-the-shelf tool covers
Your data, your workflow, your risk. Bespoke AI is the practice for a feature that has to be designed, evaluated and owned, not switched on from a menu.
How AI projects waste a year
The failures are ordinary. They come from starting with a platform tour instead of a task, and from treating a model as if it were a colleague who does not need a brief.
A pilot with no decision at the end
A demo that impresses a workshop and never meets a user is not a pilot. We define the judgement in advance: what would make you keep it, change it, or turn it off.
A chatbot that answers outside its knowledge
If the bot can talk about anything, it will. We design the boundary, the handoff to a person, and the content it is allowed to use. Tone is set with the brand, not left to a default personality.
An integration that cannot see the record
An assistant that is not connected to the CRM, the catalogue or the policy is a search box with confidence. Integrations are scoped as data and permissions, which is where the time actually goes.
No evaluation, so every anecdote wins
Without a set of real examples and a way to score them, the loudest stakeholder decides the model is “good”. We agree the cases that matter and review them before anyone calls it shipped.
Experience designed after the prompt
The screen, the empty state and the correction path are the product. AI experience is how we keep the model from being a panel glued to an interface that was finished last quarter.
Why scope AI with a product studio
- The job is written downWho it helps, what it may do, what it must not do, and how a person takes over. That page is the brief. The model choice follows it.
- Design and engineering togetherInterface, content and implementation are in the same Sydney studio. The failure states are designed, not discovered by the first customer.
- We already ship softwareAI features live inside products, sites and workflows. The studio builds those surroundings, so the feature is not stranded in a proof of concept.
- A practice with edgesChatbots, integrations, bespoke features and the experience around them are separate scopes. You can buy one. You are not enrolled in a transformation programme by default.
- Room to say noIf a better search, a clearer page or a staffed process would solve it, we will say that. An AI agency that cannot decline a model is a vendor with a script.
AI work we will actually scope
Chatbots with a boundary
Conversational tools for support or sales, tied to approved content, with a path to a person. The practice detail is on chatbot creation and deployment.
Integrations into systems you run
A model step inside CRM, catalogue, knowledge or product flows, including the permissions and the logs you will be asked for later.
Bespoke features
A use case designed from your data and your risk, evaluated before launch, and built so your team can see when it is wrong.
The interface around the model
How someone asks, how they correct, and how they know the answer is partial. That experience is part of the delivery, not a skin applied at the end.
Content and tone
What the system is allowed to say, in the voice of the brand, reviewed by the people who own the customer relationship.
A decision to keep or stop
Evaluation cases, a review, and an owner after launch. A feature without an owner is a pilot that forgot to end.
Selected product work
These published projects are platform and product builds from the Sydney studio. They are not labelled as AI case studies on the work pages. They show how we ship software that has to fit an existing operation. AI engagements use that same delivery model. The portfolio is on our work.
FleetPartners Scoreboard
A dealership and credit platform. Custom software where workflow, data and interface were designed together, which is the same shape of problem as a feature that has to sit inside an operation.
O’Brien
UI, UX, a design system and website development. Included as product-engineering proof from the studio, not as a claim that the site itself is an AI product.
Rhino-Rack
Kiosk design and development. A constrained interface with one job: help someone find the right fit. That constraint is the same discipline we apply when an AI feature has to earn a place in a product.
How an AI engagement is held
Use case before vendor
We do not start from a model catalogue. We start from the task, the data you can legally use, and the person who is accountable.
A written refusal list
Topics, actions and tones the system must not attempt. This is a design artefact, reviewed, not a sentence in a prompt nobody sees.
Human handover
Every customer-facing flow has a way out to a person or a plain page. The bot is not the only channel.
Evaluation on your examples
We score real questions and real records, including the ones the team is worried about, before launch language gets loose.
Sydney design and build
The people who scope the behaviour and the people who implement it are in the same studio. You can sit in the review.
How we take an AI brief from idea to use
Name the task and the owner
What decision or reply is being helped, who is harmed if it is wrong, and who on your side accepts that risk. If those answers are missing, we do not pick a model yet.
A use case a non-technical sponsor can approve or reject.
Inspect the data and the boundary
Where the facts live, who may see them, and what the system must refuse. This step kills a lot of attractive demos, which is the point.
A boundary and a source of truth, or a decision not to build.
Design the experience
The ask, the answer, the correction and the handover are designed with the brand’s voice. We prototype the ugly cases: low confidence, missing data, an angry user.
An interface that shows the limit of the system.
Build and evaluate
Implementation is reviewed against the example set, not against a single impressive transcript. We change the scope if the cases say the task is wider than the brief.
A result you can accept with the failures visible.
Release with an owner
Launch includes monitoring, a content update path, and a person who can turn the feature down. We stay for the iteration that the first real users always create.
A feature in production with someone responsible for it.
FAQs
Do you build chatbots?
Yes, when the questions are bounded and the source material exists. We design the conversation, connect it to the systems it needs, and keep a human path. We will not ship a general bot that is allowed to improvise about your business.
Can you add AI to a site or product we already have?
That is the usual brief. Integrations and bespoke features are how a defined step gets into a website, a service flow or an internal tool. A new product is a larger scope and we will separate the two so you can see the difference.
Will you tell us if AI is the wrong tool?
Yes. Clearer content, better search, or a staffed process is sometimes the whole fix. An engagement can end at that recommendation. We would rather decline the build than wrap a model around a problem it does not solve.
Where is the team based?
Design and engineering are in the Sydney studio. Your subject-matter experts need to be available for the boundary and the example set. We cannot invent your policy from a homepage.
How do you handle risk and accuracy?
By limiting what the system may do, evaluating it on your examples, and designing the handover when it should stop. We do not promise that a model is incapable of being wrong. We design for that fact.
How do we start?
Describe the task, the user, and what “wrong” would cost. If you have sample questions or records, include a few. We reply from Sydney with a view on chatbot, integration, bespoke feature, or no build.