A useful automation starts with a clear picture of the work people are already doing.
Pick one repeated job. Write down what starts it, which information the team needs, what rules guide the decision, where the exceptions appear, and what counts as finished. That gives you something concrete to improve. It also gives an agent the context it needs to do more than produce a plausible answer.
A single administrative job in a dental practice can cross several systems. Insurance verification may begin with information from the patient, continue through a payer portal or service, and end with details that need to be available to the person discussing treatment. A missed field, an unusual limitation, or an uncertain response needs a clear path back to a teammate.
The same pattern applies to marketing. A website inquiry can lead to qualification, scheduling, follow-up, and a record in the practice's system. The writing is only one part. The useful result is that the right next step happens, the team can see what happened, and someone can step in when the situation calls for judgment.
Anthropic's engineering guide to commerce agents illustrates this approach in another industry. It recommends that agent tools call the core systems and business logic a company already relies on. It also describes putting reusable procedures into skills and keeping critical safety, legal, and brand rules in the system's standing instructions.
The useful lesson for a practice is broader than commerce. The model should not have to recreate the rules every time it works. The surrounding system should supply the approved information, restrict the actions available, preserve the record, and make exceptions visible.
Before building anything, I would map six parts of the workflow:
- The trigger that starts the job.
- The information required before work can begin.
- The systems that hold the source information.
- The rules and preferences the team already follows.
- The point where a person needs to review or approve an action.
- The result and record that prove the job is finished.
Then collect real examples. Include the normal cases, the odd cases, and the cases where the correct action is to stop and ask. A clean demonstration is easy to automate. The exceptions are where a workflow proves whether it can support the practice every day.
The public reference implementation makes the boundary concrete: its examples use fictional businesses, and merchant changes are staged for a person to approve. A deployment still has to supply its own business rules and authorization. That is a useful reminder to inspect what a demonstration actually does before connecting it to a practice's records.
For a practice, that could mean starting with an agent that gathers and organizes information for review. Once the team sees consistent results, a later version can take a bounded action. Each new capability should come with examples that show when it works, when it should refuse, and when it should hand the work to a person.
The measurements should stay close to the job. Did the workflow reach an acceptable result? How much correction did it need? Did it save steps for the team? Were exceptions easy to find? Did the final record contain what the next person needed?
Start with one repeated process that frustrates the team. Sit with the person who handles it, map the actual work, and choose the smallest useful part to automate. Run it beside the existing process, compare the results, and decide together whether it is ready to take on more responsibility.