Scoped connections
One connection per system, with the minimum permissions the task needs. Read-only wherever write access is not essential. Separate credentials per workflow, so one can be revoked without breaking the others.
AI integration
Give AI safe access to the systems you already run
An assistant is only useful if it can see the actual diary, the actual stock, the actual file. We build the access layer that makes that possible without handing a model the keys to everything.
Every business already has the systems an AI needs: a calendar, an accounts package, a CRM, a shared drive, a practice management tool. What it does not have is a controlled way for an assistant to read from them and act on them. Without that layer, AI stays in a chat window and the real work stays manual.
We build a narrow, documented interface between the assistant and each system: what it may read, what it may write, which actions require a person, and what gets recorded. The model can then do useful work — check availability, draft a reply, update a record — without a human copying data between tabs.
What we build
An access layer, not a back door
A permission model
Roles mapped to actions: what an assistant may see, what it may draft, what it may send, and what must be approved by a named person. The same rules apply whether the request comes from a person or an agent.
An audit trail
Every request, response, edit and approval recorded with a timestamp, the user or agent responsible, and the data touched. Exportable, because an auditor will eventually ask.
A documented interface
If we expose your systems through an API or an MCP-style server, the schema and examples are yours. Another developer can pick it up without reverse-engineering our work.
Access levels
The default is the least access that works
| Capability | Default | Requires approval |
|---|---|---|
| Read a record or document | Allowed within the workflow's scope | No — logged only |
| Draft a reply or document | Allowed | Yes, before sending to a customer |
| Update a non-critical field | Allowed where reversible | No — logged with before/after |
| Change a price, booking or invoice | Blocked by default | Yes, by a named role |
| Delete a record | Blocked | Not supported |
| Export data to a third party | Blocked | Separate decision and contract |
No migration. No rip-and-replace.
No migration. No rip-and-replace.
- Legacy modernisationIf the system has no usable interface, we can build one in front of it.
- Agentic automationThe workflows that use the access layer day to day.
- AI governanceThe policy and evidence that sit around the technical controls.
Questions
The things people ask first
Is this the same as MCP?
The Model Context Protocol is one way to expose tools and data to an AI assistant. We use it where it fits, and a conventional API where it does not. The protocol matters less than the permission model and the audit trail.
Do we have to move our data to the cloud?
No. We can connect to on-premise systems through a local service, or to hosted systems through their APIs. Data residency is a design decision, and we will document where each copy lives.
What if a supplier does not offer an API?
We can often work through a documented export, a webhook, email ingestion or a database view. If there is genuinely no safe route, we will say so rather than build something fragile.
How long does an integration take?
A single-system read-only connection can be days. A multi-system workflow with write access and approvals is usually weeks. The blueprint sets the scope before build starts.
Related
Let’s find out whether technology is the answer
Tell us what you are trying to achieve. We will tell you honestly whether we can help, what it would take, and roughly what it would cost — before anyone signs anything.