An agent that does the admin after the enquiry

A chat assistant faces outward. It answers questions from visitors on your website and hands you the ones worth your time, which is covered on our AI chat assistant page. An agent faces inward. It takes a job that has landed in your business and carries it through intake, records, drafting, and follow-up across whatever systems that job touches. One is about capturing more leads. The other is about handling the admin without hiring another person.

That's the first thing we check, because it decides whether the project is even possible. Systems with a proper connection available, like Microsoft 365, Google Workspace, HubSpot, Jobber, and QuickBooks, are the straightforward case. Plenty of practice management and trade software is closed and won't let anything write into it. Where that's true we say so rather than build a workaround, and the agent does everything up to that point and hands a person the last step. If the job only needs a few apps talking to each other by a fixed rule, that's AI automation and it costs less than an agent. Tell us what you run and we'll tell you which of those you're dealing with.

There's a fixed project price to build it, quoted once we've mapped the job, and a monthly cost to run and maintain it after launch. We won't put a number on this page, because a single agent that files enquiries and a build that spans four systems aren't the same size of project. On a 30 minute call we'll tell you roughly where your job lands, what it would save you in hours, and whether that trade is worth making yet. If it isn't worth making yet, we'll tell you that too.

One agent, one job, fixed scope. We map the process first, agree exactly what the agent is allowed to do on its own, and build the narrowest useful version of it. That version runs alongside your team, with a person releasing anything a customer sees, so you can judge it on real work before widening what it touches. If mapping the process makes the fix obvious without an agent at all, that is a good outcome and we will tell you. Book an introductory call to walk through it.

Both are planned for, because both will happen. The agent runs inside a boundary you approved, so it handles the cases you described, escalates the ones you didn't, and holds anything that reaches a customer, quotes money, or touches health information until a person releases it. A fallback path is part of the design rather than an add-on, so if the model is slow, down, or answering poorly, the request drops into a normal queue and a person picks it up. Safety-critical responses are pre-approved and fixed rather than generated, so that layer keeps working even when everything around it degrades. A system that only works when every part is healthy isn't finished.

You pick. For Canadian residency we run the model through AWS Bedrock in the Montreal and Calgary regions, inside your own cloud account rather than ours, and for a US business the same setup runs in a US region. Where residency is not a hard requirement, other options are cheaper or faster, and we will tell you which trade you are making. The system scrubs personal details before a message reaches the model either way, so identifying information stays in your own systems instead of being sent through it. At launch you get a plain-language data map showing what moves where, which is what your lawyer or your privacy lead will want when they review it.

From your constraints, not our preferences. The questions that decide it are what your data is allowed to touch, how much residency matters, how much judgement the task needs, and what it costs per run at your volume. A clinic handling health information and a contractor chasing quotes should not end up with the same setup, and we will show you the trade before we build anything.

No, and you should not be. Models get deprecated, change their pricing, and have bad days, so we build with a fallback rather than one hard-wired provider. Where it makes sense we route through a layer like OpenRouter, which turns swapping a model into a configuration change instead of a rebuild. Open-weight models such as Kimi, GLM and DeepSeek are on the table too, and for some work they are the better answer on cost or on keeping everything inside infrastructure you control.