Frequently asked questions
Straight answers to what teams ask before they start — choosing the first workflow, how we handle your data and provider, Australian compliance, timelines, and how to begin without committing upfront.
# We don't know which AI workflow to start with. How do you help us pick?
We start with a structured scoping process — not a build. We map your candidate workflows, assess which ones are actually automatable at the level of quality you need, and identify the one most likely to deliver a measurable result. You end up with a prioritised list and a build specification for the right first workflow, before any development begins.
# How fast can we get from a conversation to a working agent?
A focused workflow (one document type, one output format, clear acceptance criteria) comes together in weeks, not months — scope, build, test, review. More complex workflows with multiple integrations or higher-stakes output take longer. What determines the timeline most is the clarity of the workflow definition, not the technology.
# What's the zero-risk entry option? How do we start without committing upfront?
We scope the workflow with you, build against your actual documents, and you only pay when the output meets the acceptance criteria you defined at the start. The criteria are documented before a line of work begins. Nothing ships without meeting your bar. It's built for organisations that want confidence before they commit.
# Do you build on our AI provider, or one you manage?
We build on whichever path fits your situation. If you already have a provider relationship (OpenAI, Anthropic, Azure OpenAI, or another), we build on yours, within your existing controls and data tenancy. If you don't have a provider relationship and don't want to manage one, we host and run it for you. We recommend the model that fits the task and explain the evidence for the choice.
# Do you use our data to train AI models?
No. We use enterprise-grade API configurations where training exclusions are in place by default. Your documents are processed to produce the output; they are not used to train or improve the underlying model. If you need this confirmed in writing from the provider, we can help you get that confirmation as part of the build setup.
# Where does our data go? Does it leave Australia?
That depends on the infrastructure choices we make together at scoping time. When we build on your infrastructure, your data stays within the environment you already control. When we host on your behalf, we make data residency decisions explicitly at the outset — for Australian clients, we can operate entirely within Australian-hosted infrastructure. Nothing defaults to an overseas data store without your knowledge and agreement.
# What happens when the agent gets something wrong?
Every agent we build has an acceptance standard defined before it goes live — set by you, tested on your actual documents, not synthetic examples. Outputs go to a human reviewer before they are finalised. The agent produces a draft; the practitioner reviews and approves. When quality drifts in a managed agent (because documents change or new edge cases emerge), our monitoring is designed to surface it so we can update the system before it affects your work.
# Who is responsible if an AI output leads to an error on a client file?
The professional responsible for the work remains responsible. The agent produces a draft; the practitioner reviews, corrects, and approves before anything reaches a client. That is the governance model — not because we require it, but because it is the correct structure for any workflow where a licensed practitioner carries professional responsibility. We build the review workflow into every system we deliver.
# How do you prevent the AI from making things up?
We design the task to constrain the system to the information already in the document. An agent turning a consultation transcript into a GP referral letter is extracting and reformatting — not generating from imagination. The acceptance criteria define exactly what must be present in the output and what would constitute an error. The system is tested until it meets those criteria consistently on real samples before any practitioner reviews it.
# How do you handle our compliance obligations — Privacy Act, CPS 230, professional practice rules?
We incorporate your specific obligations into the build specification from the start. For health information under the Privacy Act, we apply the higher sensitivity standard: data minimisation, purpose limitation, practitioner-controlled access. For financial services under CPS 230, we build operational risk controls and audit trails into the agent's governance layer. For regulated professions with AI supervision requirements, the review workflow is designed to meet those requirements explicitly. We do not certify compliance — we build to your obligations.
# Will this connect to the software we already use?
In most cases, yes. The most common integrations for professional services workflows are Microsoft 365, SharePoint, practice management systems, Google Workspace, and email — all well-understood integration paths. More specific systems are assessed at scoping. If an integration is not feasible within your constraints, we say so before the build starts.
# What happens to the agent after it is built?
An agent that worked when it was built can degrade over time as documents change, models update, or your workflow evolves. In the managed Run model, we monitor quality against the standard set at build time and update the agent when it needs to change. If you have taken ownership of the build, we provide documentation and offer update engagements when your context changes significantly.
Still have a question?
If your question isn’t here, the fastest way to a clear answer is a short scope call — or send it to us directly.