Loading
An agent with write access to your CRM, calendar and customer records is a security surface. Here are the controls.
A lot of automation marketing implies that the goal is removing people from the process entirely. We think that is the wrong target, and in most business workflows it is also the wrong engineering decision. Automation should absorb the repetitive coordination. Judgement, exceptions and anything hard to reverse should stay with your team, by design rather than by accident.
These apply regardless of configuration. They are not settings.
Ten practices applied across every build. None of them are optional extras.
Every integration gets its own credential, scoped to the narrowest permission set that lets it do its job. An agent that only needs to create calendar events does not get permission to delete them. Where a platform offers coarse scopes only, we say so rather than pretending the scope is tighter than it is.
In the software we build, authorisation is enforced at the database with row-level security rather than by filtering in application queries. The difference matters: a forgotten condition in a query is a data-exposure bug, whereas a database policy fails closed.
An AI agent's permitted actions are an explicit allow-list in configuration, not an instruction in a prompt. An agent with no capability to issue a refund cannot be persuaded into issuing one. We constrain by what is possible, not by what we have asked the model to avoid.
Payments, refunds, cancellations, payouts, deletions and anything else that is hard to undo are built as approval steps by default. The system prepares and presents; a person authorises. This is a design default we would need a specific reason to remove.
We capture the fields a workflow actually needs and no more. For a booking that usually means name, contact and appointment type - not a full customer history. Data you never collected cannot leak.
API keys and tokens live in environment configuration or a managed secret store, never in source control, never in client-side code, and never in a prompt. Credentials are rotatable, and we document what to rotate if you need to.
Automated actions write an attributed, timestamped log entry. This is what makes a disputed change traceable and an unexpected outcome debuggable. An automation you cannot audit is one you cannot trust with anything that matters.
Steps are retried where retrying is safe and escalated to a person where it is not, with idempotency keys so a retry cannot duplicate a booking or a charge. A workflow that fails silently is worse than the manual process it replaced.
We test the failure paths explicitly, not just the happy path: what happens when an API is down, when input is malformed, when a caller says something unexpected, when two requests race. Emergency and escalation paths are tested every time.
Error rates, failure patterns and unexpected agent behaviour are monitored after go-live, with alerts to a channel someone actually reads. Launch is the start of the operating period, not the end of the engagement.
Five places an agent touches something consequential, the failure mode for each, and the control we apply.
Risk
An agent with write access can corrupt records at scale faster than a person can.
Control
Scoped credentials, create-and-update only with deletion excluded, match-before-create to prevent duplicate storms, and full audit logging of every write.
Risk
Over-collection and over-exposure - the agent holding or repeating more than it needs.
Control
Minimal field capture, role-based read access, and automated messages that deliberately exclude sensitive detail in case a device is shared.
Risk
An incorrect or duplicated financial action.
Control
Agents never handle card data; they link to the platform's own secure flow. Refunds and payouts are human-approved, and every financial action is idempotent.
Risk
Double bookings, or a slot offered that cannot actually be filled.
Control
Availability read live at the moment of offering, bookings written transactionally with a conversation-keyed idempotency key so a retry resolves to the same event.
Risk
Broad read access turning one compromised credential into full exposure.
Control
Row-level security, per-integration credentials, read-only access wherever writing is not required, and no direct database access from client-side code.
If we cannot answer these clearly for your specific workflow, that is a reason to be cautious - of us or of anyone else.
Scoping a build includes deciding what the automation may do on its own. That conversation happens in discovery, before anything is built.
