Governance and Data
Placing autonomous agents inside an operational process raises legitimate questions about control, accountability and data. We would rather answer them on a public page than in an uncomfortable meeting three weeks into a build. Our positions on each are set out below, and they form part of every engagement rather than being negotiated case by case.
Authority is explicit
Every workflow we design states where automated authority begins and where it ends. An agent may prepare a document but not issue it. A transaction may complete below a defined threshold and escalate above it. A change to a live workflow may require a named approver. These are not defaults inherited from a platform. They are decisions taken with you at Design, recorded in the design document, and enforced in the build.
Accountability remains with people
Automating a task does not transfer responsibility for it. Every live workflow has a named owner within your organisation and a named owner within ours, both recorded in the handover documentation. Where a workflow touches a regulated activity, we expect your compliance function to be involved at Design rather than shown the result.
Actions are auditable
Agent actions are logged. Inputs, outputs, decisions and escalations are recorded in a form you can inspect and export. Where a regulator, an auditor or a client asks why the system did what it did, the answer is retrievable rather than reconstructed after the fact.
Access and data handling
We work to the principle of minimum necessary access. At Discovery we agree which systems and datasets fall within scope, what level of access is required, and how long anything we hold is retained. Where analysis can be conducted on anonymised or sampled data, we conduct it that way. Access is revoked at the conclusion of an engagement unless there is a documented operational reason to retain it.
We will execute your non-disclosure agreement and your data processing agreement. If any element of a proposed design would sit awkwardly with UK GDPR, we will say so before it is built rather than after.
Model and platform selection
Models and platforms are selected per workflow, against the sensitivity of the data, the accuracy required, the latency the process can tolerate and the commercial constraints. We are not tied to a single vendor, and the reasoning behind each selection appears in the design document. Where a workflow requires data to remain within a specific jurisdiction or within your own tenancy, that becomes a design constraint we build to.
Failure doesn't mean business halts
Every step in a workflow has a defined failure behaviour. Systems become unavailable, interfaces change, inputs arrive malformed. The question is not whether that happens but what the workflow does when it does: hold the item, alert the owner, fail visibly, and under no circumstances produce a plausible but incorrect result without flagging it.
Nothing is trusted before it is tested
No workflow touches live data or a live client until it has completed dry runs against known-good data and operated in shadow mode alongside the existing process. Promotion to production is earned against evidence, not scheduled in advance.