How ChatFox is built, integrated and governed.
The homepage explains why a ChatFox system could be useful. This page explains how we approach the technology underneath it: architecture, data, integrations, security and the controls around what AI is allowed to do.
Every section starts in plain English. The technical detail sits underneath it, so you can skim or dig in.
How a ChatFox system works
Not every ChatFox system begins with a message. The same six stages apply whether the trigger is a customer question, a staff search, an uploaded document or an event in another system.
Something happens
A system is triggered by a real event in the business.
- A customer asks a question
- A member of staff searches for information
- A document is uploaded
- A new enquiry arrives
- A system event triggers a process
ChatFox receives the request
The request arrives through whichever interface that system uses.
- Website
- Internal web application
- API
- A connected business system
The right context is applied
The system uses the information and controls configured for it, and nothing else.
- Approved company information
- Structured databases and documents
- Business rules
- Conversation or task context
- User permissions
- Connected system data
AI is used where appropriate
Where the task calls for it, a suitable model interprets, classifies, extracts, reasons over or generates information.
- Not every action needs a model
- Deterministic work stays deterministic
- The model is chosen for the task
Checks and controls are applied
Before anything is returned or performed, the controls configured for that system run.
- Validation
- Permission checks
- Safety rules and scope restrictions
- Human approval where required
- Business-specific rules
An answer or action happens
Something useful occurs, or a person takes over with the full context.
- Information is returned
- An enquiry is qualified
- A CRM record is created
- A calendar action is performed
- A document is structured or a database searched
- A staff member is notified, or the task is passed to a human
AI is one component, not the whole system.
A reliable business application usually combines AI with structured software, approved information, defined rules, integrations and appropriate human controls. We design the architecture around the job that needs to be done.
Not everything should be left to AI
Deciding what the model handles and what conventional software handles is most of the engineering. Getting that split wrong is how AI projects become unreliable.
Deterministic work
- Permissions
- Database operations
- Validation
- Authentication
- Business rules
- Audit records
- Deterministic processes
Interpretation and language
- Understanding natural language
- Classifying enquiries
- Extracting information
- Searching complex knowledge
- Interpreting documents
- Generating natural responses
Not every action carries the same risk
Rather than a blanket policy, actions are grouped by consequence. The level of checking is set per system during design.
Answering an approved question
Returning information the business has already approved for that audience.
Creating a CRM lead
Writing structured data into a business system where the format and permissions matter.
Financial or compliance impact
Anything with financial, operational or compliance consequences for the business.
The detail, by topic
Each topic opens with the short version. Expand for the technical detail.
We do not force every project into one architecture
A customer-facing assistant, an internal knowledge system and an AI-enabled database are different pieces of software. They are designed differently, deployed differently and secured differently. The architecture follows the use case.
View technical detail
Systems we build
- Customer-facing assistants
- Internal web applications
- AI-enabled databases
- Knowledge systems
- Workflow applications
- API-connected services
- Bespoke interfaces
What shapes the design
- The use case and the actions the system must perform
- Existing systems it has to work alongside
- The data required, and where that data lives
- Security requirements and user roles
- Client infrastructure constraints
The implication is that capabilities described elsewhere on this page are not automatically present in every system. Where something is specific to the existing ChatFox agent platform rather than to bespoke work, it is labelled as such below.
Where ChatFox hosts application data, it is hosted in the UK
Where ChatFox hosts application data, that data sits on Amazon Web Services in the London region (eu-west-2). Clients retain ownership of their business data. Where a project requires a different agreed architecture, the arrangement is defined during solution design rather than assumed.
View technical detail
What this covers
- Application data
- User inputs
- Documents
- Structured records
- Conversation data, where the system is conversational
- Logs
- Configuration data
Hosting position
- ChatFox-hosted infrastructure resides within the United Kingdom (AWS eu-west-2).
- AWS London operates under UK GDPR-compliant data processing terms.
- ChatFox enters into a Data Processing Agreement with every client, defining roles, purposes, legal bases and obligations on both sides.
Third-party processing
This is the part worth reading carefully. Even where data retained by ChatFox is UK-hosted, data passed to external services is processed according to those providers' infrastructure and terms.
- AI model providers
- Meta and WhatsApp, where WhatsApp is a channel
- CRM platforms
- Payment services
- Other client-selected integrations
Which third parties are involved depends entirely on what a given system connects to. That list is established during design and documented for the client.
Ownership and export
Clients retain ownership of their business data. Export and portability requirements are agreed according to the system being built.
AGENT PLATFORM
The existing ChatFox management portal provides export of conversation histories, end-user details and configuration for customer-facing agent deployments. Bespoke applications define their own export requirements during design.
Provider flexibility, rather than a fixed model
We are not tied to one AI provider. The model is selected for the task and the client's requirements, and can be changed. We deliberately do not publish a list of specific model versions here, because that list would be wrong within months.
View technical detail
What drives the choice
- Performance on the specific task
- Data handling requirements
- Cost
- Reliability
- Client preference
- Compliance requirements
Providers we can work with
- OpenAI
- Anthropic
- Microsoft Azure AI, which offers UK and EU data residency options
- Appropriate open-source or self-hosted models
Commercial arrangement
Where appropriate, clients use their own AI-provider account and credentials, so that the contractual and data-processing relationship sits directly between the client and that provider. The commercial and technical arrangement is agreed during solution design.
AGENT PLATFORM
For customer-facing agent deployments, the client holds their own account with their chosen AI provider and ChatFox is granted API access to operate the system on their behalf.
Reading from and writing to the systems you already run
A system that can only answer questions is worth far less than one that can also act. Where an existing platform provides a suitable API, we can integrate through it, in both directions.
View technical detail
Reading information
- Customer records
- Product data
- Availability
- Documents
- CRM records
- Internal databases
Writing information
- Create and update CRM records
- Book appointments
- Save structured data
- Trigger workflows
- Add notes
- Update internal systems
What integration feasibility depends on
Not everything can be integrated, and it is better to establish that early than to discover it during a build.
- API availability
- Authentication methods supported
- Permissions available to the account we are given
- Rate limits
- Data structure
- Vendor restrictions
What if our system does not have a standard integration?
ChatFox can work with documented REST APIs, client-built endpoints and other agreed integration methods. Where a full API is not available, we can work with the client's technical team to establish whether purpose-built endpoints can provide the required read and write functionality.
Scoped access, recorded actions, and AI-specific risks taken seriously
These systems touch real customer data and real operational tools, so they are built with the access controls you would expect of any business application, plus controls for the risks that are specific to AI.
View technical detail
Access control and least privilege
Systems are given the narrowest access that allows them to do the job. Credentials are scoped to the specific operations required rather than issued broadly, and application permissions are defined per system.
Credential management
Integration credentials are held securely and scoped per integration. Where a client prefers to issue and control their own credentials, that is accommodated during design.
Logging
Actions performed by the system can be recorded so that what happened, and when, is reviewable. The depth of logging is set per project.
Data retention
Retention is configurable and agreed with the client rather than fixed by us.
Prompt injection and AI-specific risks
Where a system reads content it did not author, such as an uploaded document, a web page or an inbound message, that content is treated as untrusted input rather than as instructions. Controls include scope restrictions on what the system is permitted to do, validation of proposed actions, and human approval on sensitive operations, so that a manipulated input cannot by itself cause a consequential action.
AGENT PLATFORM
The existing ChatFox management portal uses one-time-passcode access. Authentication for bespoke applications is designed according to the project and the client's own identity requirements, and is not assumed to match the portal.
The system asks permission in proportion to the consequences
Rather than a single "human in the loop" claim, actions are classified by consequence and the level of checking is set accordingly. The three levels are shown above.
View technical detail
How this is applied
- Which actions a system may perform at all is defined during design, not left open.
- Proposed writes can be validated against expected structure and business rules before they are committed.
- Actions classified as sensitive can be held for human confirmation rather than performed automatically.
- Handover to a person can carry the full context of what happened up to that point.
Why this matters more with AI
A model can be wrong or can be manipulated. Treating its output as a proposal to be checked, rather than as a command to be executed, is what makes the difference between a demonstration and a system a business can rely on.
Systems are monitored and supported after launch
Application activity, workflows and integrations are monitored so that failures are noticed by us rather than reported by your customers. Support continues after launch as a matter of course.
View technical detail
What is monitored
- Application activity
- Workflow execution
- Integration health and failures
- Error conditions requiring intervention
Ongoing support
Systems are refined after launch as the business and its requirements change. That is part of how we work rather than a separate engagement.
How people actually reach the system
The interface is a design decision, not the architecture. The same underlying system can be reached through a website, through WhatsApp, through an internal application, or by another system over an API.
View technical detail
Website
A web chat interface delivered as part of the managed service, with data passing directly from the end user's browser to ChatFox infrastructure over TLS. Document upload is supported. No third-party messaging platform is involved.
Delivered through the official WhatsApp Business API. The client holds their own WhatsApp Business account, contracted directly with Meta, and ChatFox is granted API access to operate the system on their behalf. Inbound traffic is processed through secure webhooks. Document upload is supported.
Because the channel is Meta's, message data travels through Meta's WhatsApp Business API infrastructure before reaching ChatFox. For clients with strict data residency requirements, the web channel combined with a UK or EU-region model provider gives the more controlled end-to-end path.
Internal applications
Some ChatFox systems are staff-facing web applications rather than conversational customer interfaces: search interfaces, knowledge systems, product databases, data-management tools and internal operational applications. These are built as applications in their own right, with their own access model.
APIs and system-to-system
A system can be triggered by another system rather than by a person, where the integration and authentication method have been agreed.
On standards
ChatFox is not certified to ISO 27001 or ISO 42001. These systems are designed with the control thinking behind those standards in mind: scoped access, recorded actions, defined retention, validation and human approval. We would rather state that accurately than imply a certification we do not hold.
The short version
If you read nothing else on this page.
Have a technical or security question?
Bring us your architecture, integration, security or data requirements and we'll work through them with you.
Or ask Basil, an example of our customer-facing agent capability, about how that side of things works.
