Business situation
A London accountancy practice finds that prospective clients increasingly ask an AI assistant to find them an accountant, compare services or explain what a firm offers. The practice’s website is written for people. It wants AI assistants to have accurate, current facts about its services and offices — and a proper way to request a consultation.
Why existing tools alone are insufficient
An AI reading a website has to interpret pages written for people, and may pick up out-of-date prices or a service the firm stopped offering. A contact form works for people, but not for an AI acting on a prospect’s behalf. And building a public API from scratch means deciding, securing and maintaining exactly what outsiders may do.
Systems involved
- KroyDB — the practice’s services, locations and articles as structured entities.
- Kroy Publish — the public Channel.
- The practice’s website — built from the same public projection.
Kroy architecture
The practice’s public content lives in KroyDB. Kroy Publish exposes a public Channel with read access to services.read, locations.read and articles.read, and one capability outsiders may invoke: consultation.request. The website is built from the same projection, so what people and AI see agrees. Client capabilities such as documents.upload are available only in client Channels, never the public one.
Workflow
- A prospect asks ChatGPT: “Find an accountant in north London who does R&D tax claims for tech start-ups.”
- ChatGPT reads the practice’s public Channel with
services.readandlocations.readand returns the relevant service and office. - The prospect asks: “Book an initial call with them next week.” ChatGPT invokes
consultation.requestwith the prospect’s details and preferred times. Kroy creates a consultation request entity and notifies the practice. - ChatGPT asks for a list of the practice’s current start-up clients. Kroy refuses: client data is not in the public Channel.
- ChatGPT tries to upload the prospect’s accounts. Kroy refuses:
documents.uploadis only available to clients, in a client Channel. - A partner reviews the request and replies to the prospect personally.
Agent permissions
Any AI can read the public Channel and invoke consultation.request. No AI can reach anything outside the public projection through it.
Human permissions
The marketing lead and partners edit public content; changes are approved before publication. Partners handle consultation requests.
State changes
- A consultation request entity is created with the prospect’s details.
- The request is assigned to a partner.
- Once the prospect becomes a client, a client Channel can be opened for them.
Audit outcome
Kroy records reads of the public Channel, the consultation request, and the two refused requests — with the calling agent where it identifies itself.
External sharing
This workflow is public by design. The public projection contains only content the practice has approved for publication.
Security considerations
- The public Channel exposes only what the practice has chosen, as structured entities.
consultation.requestaccepts a request; it does not create a client relationship or accept an engagement.- Changes to the public Channel go through the same approval as the website, so AI and people see the same approved facts.
Setup requirements
- Services, locations and articles modelled as entities in KroyDB.
- A public Channel with the read capabilities and
consultation.requestenabled. - The Request Consultation Skill, routing requests to the right team.