Approval flows
Actions outside the pre-authorised rules — irreversible, financial or visible to a customer — require confirmation by a named person before they proceed.
Security & governance
Control is designed in, not added afterwards.
Security, governance and data-handling requirements are defined during system design. Where a project has regulatory or contractual obligations, those are agreed with your legal or compliance team before production deployment.
Human oversight
Where a person stays responsible.
Automation is scoped by action, not by system. Each action an agent may take is either permitted, permitted with approval, or not permitted — decided during design and recorded.
01
02
Escalation rules
Defined case types leave the automated path immediately and are routed to a person with the context attached.
03
Confidence thresholds
When confidence is low or required information is unavailable, the workflow can stop and escalate rather than produce an answer.
Access & data
Agents receive the access a task requires.
Permissions are scoped per agent and per workflow, in the same way a new employee would be onboarded — with less access rather than more.
01
Role-based access principles
Access is designed around source and role-based permissions, and the system is configured to respect those boundaries.
02
Data minimisation
A workflow is given the data it needs to complete the task, rather than a copy of everything available.
03
Retention planning
What is stored, where, and for how long is defined during design rather than left to default behaviour.
04
Processing boundaries
Which providers process what, and under which terms, is a design decision agreed with you.
05
Deployment boundaries
Private or customer-controlled deployment options can be considered, and are scoped where technically feasible and required by the project.
06
Credential handling
Integration credentials are held in the deployment environment, never in front-end code.
Production operations
What happens when something goes wrong.
Production behaviour is designed for the failure cases, not only the happy path.
01
Logging
Configured actions and workflow events can be logged for review, so a decision can be reconstructed afterwards.
02
Monitoring
Volumes, failures and escalation rates can be surfaced, so problems are noticed rather than discovered later.
03
Error handling and fallbacks
Where a required system cannot be reached, a workflow can hold the item, retry on a defined schedule and surface it rather than completing the step on incomplete data.
Governance planning
Requirements shape the system, not the other way round.
Deployment architecture, data-processing boundaries and access design are decided during the design stage, so requirements from your IT or compliance function shape the system rather than being retrofitted to it.
Potentially. Feasibility depends on the systems involved, your security requirements and the deployment architecture. These constraints are assessed during discovery and agreed before build, and we document the agreed controls and deployment architecture so your own compliance function can assess them.
Deployment architecture is agreed based on customer requirements, together with which providers are used for the capabilities involved. Both are decided with you during design and documented before production deployment.
Project ownership, infrastructure accounts and handover arrangements are defined transparently before implementation begins. Our preferred approach is to avoid unnecessary vendor lock-in and to make infrastructure ownership clear from the start.
Bring your requirements before the trial starts.
If your organisation has security, governance or deployment constraints, they are easier to design around than to retrofit.