Useful help. Clear permission. You stay in control.
An intelligent agent is software that can carry out tasks on someone’s behalf through connected services. For a patient, that could mean finding an appointment and booking it with their approval. For a dental practice, it could mean preparing a supply order or following up on an administrative request.
Cadmus could develop agents that reduce the time patients and practice teams spend coordinating these everyday tasks. A person could ask an agent to prepare options for review or authorize it to complete a defined task within agreed limits. People should be able to understand what an agent may access, arrange, or spend, see what it has done, and withdraw permission for further actions.
Authorized agents are an exploratory extension of BOCA. Its proposed identity, dental intelligence, and payment capabilities could provide a foundation for useful tools within the ecosystem—and, over time, for applications beyond it.
01 / WHAT AGENTS COULD HELP PEOPLE DO
Fewer steps for patients. Less coordination work for practices.
For a patient / From finding a time to confirming a visit
A patient could ask an agent to find an appointment at their practice that fits their availability. With access to participating scheduling systems, the agent could check openings, present suitable options, and book the patient’s choice. If the patient had already authorized booking within specific days and times, it could complete that task and return a confirmation.
The patient would spend less time calling, checking availability, and exchanging messages. Further possibilities could include requesting a record they want transferred, checking available coverage information, or arranging a payment they approve.
For a practice / From a supply shortage to a prepared order
With access to inventory information the practice maintains, an agent could identify supplies due for replenishment, check prices and availability from approved vendors, and prepare an order showing quantities, delivery dates, and total cost. The team could review and approve it before purchase.
A practice could also authorize routine reorders within defined product, vendor, and spending limits. An unavailable item, proposed substitution, or cost above the limit would require further approval. Staff could spend less time assembling routine orders while retaining control over exceptions.
Similar assistance could help teams track outstanding record requests or coordinate administrative follow-up. These tools could complete useful work with fewer handoffs while bringing decisions that need attention back to the person responsible.
Emerging infrastructure is beginning to take shape
Cadmus cannot know which standards or financial rails will ultimately prevail. The opportunity is to design Authorized Agents for an increasingly interoperable environment—one in which identity, permission, credentials, and payments may be checked across services rather than relying entirely on today’s manual workflows.
02 / WHAT ROOTPRINT COULD ADD
Different accounts. Different agents. The same person.
Smartphone security can strongly authenticate someone’s access to a device or account. But a person could create several accounts under different names and securely sign into each of them. Each account could pass its security checks without necessarily establishing whether those accounts belong to different people or the same person.
Rootprint is designed to help answer that question. By comparing dental evidence connected to professionally verified care, Rootprint and DentAI could flag an attempted registration that appears to belong to someone already enrolled—even under another name. A new account would not automatically establish a new person.
That distinction matters when agents act for people. Someone might use one agent to arrange appointments and another to manage payments. Where participation depends on individual eligibility, those agents should still trace back to the same person. Creating more accounts or agents should not multiply a person’s benefits or votes.
That human connection is only one part of delegated action. The account or credential still has to be authenticated. The system also has to know which agent is acting, who authorized it, what it is allowed to do, how long that permission lasts, and whether the action it is requesting falls within those limits. Rootprint could help establish the person behind that authority; the surrounding authorization and enforcement systems would determine what the agent is actually allowed to do.
For example, a member organization could allow an agent to claim a benefit on someone’s behalf, such as a reward earned through participation. Rootprint could help establish which person the agent represents. The organization would check that person’s eligibility and whether the benefit had already been claimed, while a separate permission check would confirm that the agent was authorized to act. This could help protect members’ access to benefits intended to be shared fairly.
The same foundation could make legitimate participation easier. With the person’s permission, an agent could present proof of a verified qualification or membership to a service that accepts it. Privacy-preserving proofs could allow the service to check the relevant fact without receiving dental images or unrelated personal information.
Rootprint’s proposed contribution is the human identity behind the authority: helping credentials, history, and accountability remain connected to the same person as they use different accounts and agents. Authentication, agent identity, permissions, enforcement, and auditability would remain separate parts of the system.
A clear task. Defined limits. Permission that can be withdrawn.
A practice could authorize an agent to reorder specified supplies from approved vendors within a monthly budget. That permission would define what it may purchase, which vendors it may pay, how much it may spend, and when the authorization expires.
The agentInterpret the practice’s goal
Propose an order
The systems accepting the order or payment
Check permission before acting
Product and vendor
Approved
Budget
Enough budget remains
Permission
Still active
Additional approval
Required?
Defined limitsAuthorization expires
Fits the practice’s authorizationOrder or payment could proceed
Outside the authorizationShould not execute
Ask for further approval / Decline the purchase
Review what the agent orderedWithdraw permissionReject further actions
Check permission before acting
The agent could use AI to interpret the practice’s goal, review inventory, compare approved products and vendors, and propose an order. But before an order or payment could proceed, the connected services would need to check that the proposed action still fits the practice’s authorization.
That check could include whether the product and vendor are approved, whether enough budget remains, whether the permission is still active, and whether the proposed action requires additional approval.
Those limits should be enforced by the systems accepting the order or payment. They should not depend solely on the agent remembering or correctly interpreting its instructions. If the proposed action falls outside the authorization, it should not execute.
This separation is also appearing in emerging agent-payment infrastructure. Google’s Agent Payments Protocol (AP2), for example, requires agent actions to be checked against defined authorization rules before they are processed.
Ask when the task exceeds its limits
If an item is unavailable, a substitute is proposed, or an order would exceed the remaining budget, the agent would ask for further approval. The practice could approve the specific change, revise its instructions, or decline the purchase.
Permission for one exception would not automatically expand the agent’s ongoing authority.
See what happened—and stop further activity
The practice should be able to review what the agent ordered, what it spent, and which approval supported each action. It should also be able to withdraw permission before the original expiration date.
Connected services would need to reject further actions under an expired or withdrawn authorization. An order already placed or a payment already completed might require a separate cancellation, refund, or dispute process.
Cadmus would need to develop and test these controls across the services its agents use. Rootprint could support the identity behind a permission; the authorization and transaction systems would enforce what that permission allows.
04 / HOW BOCA’S SYSTEMS COULD SUPPORT THE WORK
Connected capabilities could help an agent complete the task.
An agent arranging care or a payment could draw on several parts of BOCA. Each would contribute information or perform an authorized action relevant to the task.
Identity and dental information
Rootprint could support the continuing identity of the person represented. When a task requires interpretation of dental records, DentAI could provide specialized analysis—for example, helping organize treatment information for a practitioner to review. Practitioners would remain responsible for clinical judgment, with treatment choices made by patients and their care teams.
An agent could also help a patient understand a treatment plan their dentist has proposed. Using information approved for that purpose, it could explain unfamiliar terms, walk through the planned steps, and help the patient prepare questions for their care team. Explanations would need to stay faithful to the practitioner’s plan and direct questions requiring clinical judgment back to the treating practice.
Prime’s core systems would apply coverage rules and provide the resulting contribution information. An agent could use that information to help explain a patient’s remaining balance or arrange an approved payment. The financial infrastructure would check the payment authorization and carry out a permitted transfer.
Verifiable financial rules
Selected blockchain infrastructure could help when multiple participating services need to verify the same payment conditions, authorization history, or financial events. For example, when an agent orders supplies for a practice, a smart contract could enforce the spending allowance for payments processed through it, record completed payments, and make the remaining allowance verifiable to participating systems.
Blockchain would not be required for every agent transaction. Conventional signed credentials, databases, and payment services could perform many of the same functions where they are better suited to the task. The choice would depend on what needs to be shared, verified, or enforced across participating systems.
This would still require reliable connections to the services involved, tested rules, and defined processes for changes and disputes.
Permission to perform a task should come with appropriate limits on information access. An agent arranging a payment may need the amount owed and the intended recipient, without needing the patient’s clinical history. A service checking eligibility could receive a relevant proof rather than the private evidence behind it.
Auditability should make authorized activity accountable while protecting personal information. The design would need to establish which records remain private, who can inspect them, and what can safely be verified across participating systems.
05 / USEFUL TOOLS WITHIN BOCA—AND BEYOND IT
Agents people could use. Capabilities other developers could build on.
Cadmus could pursue two related opportunities: agents that help patients and practices complete useful tasks, and specialized capabilities that other developers integrate into their own services.
Tools for patients and practices
Patient assistance, practice administration, and purchasing tools could be offered through subscriptions or integrations with dental software. A practice might pay for help coordinating routine work; a patient-facing service could make appointments, treatment information, and approved payments easier to manage.
These tools could eventually serve practices and patients outside BOCA. Individual capabilities could be developed and tested separately, with their value measured by the work they complete reliably and the time they save.
Capabilities other agents could use
Cadmus would not need to build every agent or every piece of the infrastructure those agents use. If Rootprint proves useful and interoperable, other developers could potentially integrate Rootprint-supported identity or eligibility proofs into their own agent services.
For example, a household-shopping agent might need to demonstrate that its user holds a valid membership or qualifies for a particular offer. A Rootprint-supported proof could help connect that credential to the person the agent represents, while the receiving service separately checks the agent’s permission and applies its own rules.
Cadmus could also build on open standards and infrastructure developed elsewhere for agent identity, authorization, credentials, wallets, and payments. That creates a possible role for the company on both sides of the ecosystem: using compatible infrastructure where it is useful while providing differentiated identity or verification capabilities that other services may choose to integrate.
The commercial opportunity
Subscriptions, software licensing, and integration services could provide revenue where these capabilities deliver enough value for people or organizations to pay for them. That value could come from less administrative work, fewer repeated identity checks, or more reliable access to services that depend on verified participants.
Agent-to-agent and machine-to-machine commerce could create additional ways to charge for useful capabilities. Emerging protocols such as x402 are being developed so software agents can pay other services automatically for individual API calls, data, verification, or other digital resources—including transactions small enough that traditional payment methods may be impractical. If Cadmus develops capabilities that other agents find useful, some could potentially be offered on a pay-per-use basis alongside subscriptions, software licensing, and integrations.
That could create a commercial role for Cadmus even when another company builds the agent itself. An outside agent might, for example, pay to use a Cadmus verification or identity capability when it needs one, rather than requiring its developer to purchase an entire Cadmus product or become part of the BOCA ecosystem.
That opportunity would not depend on any particular payment rail, stablecoin, or micropayment protocol. Cadmus could use compatible infrastructure where it proves useful rather than building the underlying payment network itself.
Successful products could help Cadmus fund further development across its architecture. The opportunity would grow through capabilities that earn adoption—first in the settings BOCA understands, then wherever their usefulness can be demonstrated.
06 / WHAT NEEDS TO BE DEMONSTRATED
Useful agents require reliable control.
Authorized agents would need to complete tasks reliably while staying within permissions people can understand and change. Defined limits would need to be enforced consistently by the connected systems, including when an agent misunderstands a request, receives manipulated instructions, or attempts an action outside its authority.
Security and recovery would also need to hold up in practice. The system would need to resist misuse of stolen accounts or credentials, allow permissions to be withdrawn, support recovery when access is compromised, and protect private information throughout the process.
Agents would also need to work reliably across the services they depend on, with clear records of what was authorized and what occurred. When something goes wrong, responsibility, correction, cancellation, refunds, or other remedies would need to be understandable. Rootprint would need to demonstrate measurable value over existing identity systems for the agent uses proposed here.
The central test is whether people can delegate useful work with less effort while retaining meaningful control over their information, money, and decisions.