Real operations, redesigned for AI
We diagnose how work is actually performed, design the future operating model, build or integrate the technology, and help people adopt it. Six capabilities, delivered as one practice.
First we listen. Then we build.
Discovery turns a broad ambition into a decision-ready portfolio of initiatives. Interviews are anchored in recent cases, real documents and system walkthroughs, not in opinions alone.
When it is needed
- Leadership wants AI in operations but has no evidence-based view of where it pays.
- Written procedures, observed practice and system records disagree.
- An implementation quote is needed while the unknowns behind it are still open.
What you receive
- A current-state map of processes, systems, documents, controls and exceptions.
- An opportunity register, with a shortlist prioritised by value, feasibility, risk and adoption.
- A conceptual target architecture with its data and integration requirements.
- Security and governance constraints, preliminary metrics and a phased roadmap.
- A plain statement of what is not yet known, and the evidence that would close it.
How it is governed
- Findings are separated into confirmed facts, participant reports, interpretations and hypotheses.
- Agent-led interviews are opt-in and study the work. They are never an automated performance score.
- Participant estimates stay labelled as estimates. A discovery does not imply production software.
When it is needed
- Leadership wants AI in operations but has no evidence-based view of where it pays.
- Written procedures, observed practice and system records disagree.
- An implementation quote is needed while the unknowns behind it are still open.
What you receive
- A current-state map of processes, systems, documents, controls and exceptions.
- An opportunity register, with a shortlist prioritised by value, feasibility, risk and adoption.
- A conceptual target architecture with its data and integration requirements.
- Security and governance constraints, preliminary metrics and a phased roadmap.
- A plain statement of what is not yet known, and the evidence that would close it.
How it is governed
- Findings are separated into confirmed facts, participant reports, interpretations and hypotheses.
- Agent-led interviews are opt-in and study the work. They are never an automated performance score.
- Participant estimates stay labelled as estimates. A discovery does not imply production software.
From scattered records to governed context
We design the information base that people, reports and agents share. The aim is not to centralise everything, but to make definitions, permissions and evidence trustworthy enough to work from.
When it is needed
- Data exists but is fragmented, inconsistently defined or out of reach at the moment of decision.
- Leaders wait for manually compiled reports to see the state of the operation.
- Knowledge sits in documents and in individuals, where no assistant or agent can use it.
What you receive
- Source inventory, data lineage and canonical schemas for the processes in scope.
- A read-and-infer layer over existing systems: dashboards and analytics without new peripheral tools.
- Document pipelines: preprocessing, extraction to structured data and taxonomy normalisation.
- Retrieval and semantic layers that cite the page, field or record behind each answer.
- Integration flows, an event model and an observability specification.
How it is governed
- Sensitive sources stay read-only where possible. Generated outputs are separate and versioned.
- Role-scoped permissions and data minimisation are designed in from the first diagram.
- Users can see where a field came from, correct it, and keep a record of that decision.
When it is needed
- Data exists but is fragmented, inconsistently defined or out of reach at the moment of decision.
- Leaders wait for manually compiled reports to see the state of the operation.
- Knowledge sits in documents and in individuals, where no assistant or agent can use it.
What you receive
- Source inventory, data lineage and canonical schemas for the processes in scope.
- A read-and-infer layer over existing systems: dashboards and analytics without new peripheral tools.
- Document pipelines: preprocessing, extraction to structured data and taxonomy normalisation.
- Retrieval and semantic layers that cite the page, field or record behind each answer.
- Integration flows, an event model and an observability specification.
How it is governed
- Sensitive sources stay read-only where possible. Generated outputs are separate and versioned.
- Role-scoped permissions and data minimisation are designed in from the first diagram.
- Users can see where a field came from, correct it, and keep a record of that decision.
Agents inside a controlled workflow
We split each process into deterministic and probabilistic parts. Rules, thresholds and state transitions stay explicit and testable. Language models work where interpretation or synthesis adds value.
When it is needed
- Specialists spend their days reading, reconciling, copying and reporting between systems.
- The same document families recur: applications, contracts, statements, reports.
- Volume peaks overload the team and raise the risk of error.
What you receive
- Document agents that classify, extract, compare, summarise and draft.
- Knowledge agents that answer from approved sources and route what they cannot resolve.
- Operational agents that assemble reports, monitor events and prepare the next action for approval.
- Developer agents that inspect repositories, classify technical debt and generate tests.
- Evaluation sets built from representative cases, with explicit failure criteria.
How it is governed
- High-risk outputs carry their evidence, a confidence or exception state and an escalation path.
- Where judgement and consequence are high, no case advances without the named reviewer's approval.
- We do not begin with adverse decisions, payments or direct writes to a core system.
When it is needed
- Specialists spend their days reading, reconciling, copying and reporting between systems.
- The same document families recur: applications, contracts, statements, reports.
- Volume peaks overload the team and raise the risk of error.
What you receive
- Document agents that classify, extract, compare, summarise and draft.
- Knowledge agents that answer from approved sources and route what they cannot resolve.
- Operational agents that assemble reports, monitor events and prepare the next action for approval.
- Developer agents that inspect repositories, classify technical debt and generate tests.
- Evaluation sets built from representative cases, with explicit failure criteria.
How it is governed
- High-risk outputs carry their evidence, a confidence or exception state and an escalation path.
- Where judgement and consequence are high, no case advances without the named reviewer's approval.
- We do not begin with adverse decisions, payments or direct writes to a core system.
From prototype to something people use
Our engineers work close to the client operation, in the forward-deployed model. They learn the constraints first-hand and adapt the system until it supports the real workflow.
When it is needed
- A workflow needs durable state, a specialised review screen or policy enforcement beyond office tools.
- A promising demonstration has never become a trusted daily workflow.
- Legacy code, thin tests and documentation, and knowledge concentrated in a few people.
What you receive
- Web applications, administrative consoles, dashboards and guided workflows.
- Integrations with APIs, file pipelines, email, cloud drives, HR and business systems.
- A minimum viable workflow: data, rules, AI, interface, human review and logging, joined end to end.
- Source code, documentation and technical handover, under the ownership terms of each agreement.
How it is governed
- Success criteria are agreed before any demonstration. A visually impressive output is not sufficient.
- Beta and production are separate gates, each approved by the client.
- Standard engineering practice, so the client's own technology team can test, modify and take over.
When it is needed
- A workflow needs durable state, a specialised review screen or policy enforcement beyond office tools.
- A promising demonstration has never become a trusted daily workflow.
- Legacy code, thin tests and documentation, and knowledge concentrated in a few people.
What you receive
- Web applications, administrative consoles, dashboards and guided workflows.
- Integrations with APIs, file pipelines, email, cloud drives, HR and business systems.
- A minimum viable workflow: data, rules, AI, interface, human review and logging, joined end to end.
- Source code, documentation and technical handover, under the ownership terms of each agreement.
How it is governed
- Success criteria are agreed before any demonstration. A visually impressive output is not sufficient.
- Beta and production are separate gates, each approved by the client.
- Standard engineering practice, so the client's own technology team can test, modify and take over.
Security is architecture, not a disclaimer
Where data, model calls, logs and credentials live is designed explicitly. We align each solution with the client's security policies and applicable standards, subject to project-specific validation.
When it is needed
- Staff already use public AI tools without institutional guidance.
- The work is regulated or reputation-sensitive, and an incorrect result has a real cost.
- Security, risk, legal, audit or procurement must approve before anything proceeds.
What you receive
- Data classification, role-based permissions and environment separation.
- Criteria for model and vendor selection, retention, deletion, and exit or portability.
- Approval flows and segregation of duties mapped to internal policy.
- An audit trail design: actor, time, input, rule or model version, result, exception, approval.
- Incident handling, a fallback for unavailable models, and documentation fit for review.
How it is governed
- Start assistive, internal and bounded: read approved information, draft, cite, send exceptions to a person.
- Autonomy expands only after accuracy, controls, ownership, monitoring and a safe fallback are shown.
- Client data is not used to train public models without authorisation.
When it is needed
- Staff already use public AI tools without institutional guidance.
- The work is regulated or reputation-sensitive, and an incorrect result has a real cost.
- Security, risk, legal, audit or procurement must approve before anything proceeds.
What you receive
- Data classification, role-based permissions and environment separation.
- Criteria for model and vendor selection, retention, deletion, and exit or portability.
- Approval flows and segregation of duties mapped to internal policy.
- An audit trail design: actor, time, input, rule or model version, result, exception, approval.
- Incident handling, a fallback for unavailable models, and documentation fit for review.
How it is governed
- Start assistive, internal and bounded: read approved information, draft, cite, send exceptions to a person.
- Autonomy expands only after accuracy, controls, ownership, monitoring and a safe fallback are shown.
- Client data is not used to train public models without authorisation.
Adoption is part of delivery
People learn on their own cases, not on generic courses. Programmes start from an assessment of each person's work, then run tracks by level of responsibility, tied to concrete use cases.
When it is needed
- AI licences are paid for and barely used, because nobody has shown how they apply to each role.
- Adoption is informal and uneven: a few enthusiasts and many bystanders.
- New workflows are arriving, and teams must be able to direct and review them.
What you receive
- An assessment and structured interviews that reveal responsibilities, tools and learning needs.
- Tracks for executives, process owners, managers and practitioners.
- Live workshops on participants' own materials, with recordings, guides and reusable agents.
- Office hours, communities of practice and safe practice environments with synthetic data.
- Progress and adoption measurement, reported by area and by level.
How it is governed
- Simple automations stay with trained users. Complex, cross-area processes go to specialised engineering.
- Training covers what AI cannot do, and which data must never reach public tools.
- Capability transfer is a stated outcome. The aim is internal agency, not dependency.
When it is needed
- AI licences are paid for and barely used, because nobody has shown how they apply to each role.
- Adoption is informal and uneven: a few enthusiasts and many bystanders.
- New workflows are arriving, and teams must be able to direct and review them.
What you receive
- An assessment and structured interviews that reveal responsibilities, tools and learning needs.
- Tracks for executives, process owners, managers and practitioners.
- Live workshops on participants' own materials, with recordings, guides and reusable agents.
- Office hours, communities of practice and safe practice environments with synthetic data.
- Progress and adoption measurement, reported by area and by level.
How it is governed
- Simple automations stay with trained users. Complex, cross-area processes go to specialised engineering.
- Training covers what AI cannot do, and which data must never reach public tools.
- Capability transfer is a stated outcome. The aim is internal agency, not dependency.
Technology follows the process
We do not lead with a predetermined model, application or cloud. Technology selection follows the process, data, risk and ownership requirements, inside the environment the client has approved.
Google Workspace and Gemini
When the organisation already runs on Sheets, Docs, Drive, Gmail and Apps Script, and a bounded workflow can be owned there.
Microsoft 365, Copilot, Azure OpenAI
For Microsoft-centric regulated environments that rely on enterprise identity and tenant controls.
Custom applications
When the workflow needs durable state, specialised review screens, integration, policy enforcement or scale.
Private or hybrid infrastructure
When data residency, model control, latency or security requirements demand it.
Options that depend on the engagement. They are not vendor partnerships or certifications.
Phased, with a decision at every gate
Work is bought in phases. Each one reduces a specific uncertainty and ends in a decision, so nobody commits to a large build before feasibility, controls and value are understood.
- 01
Discovery and master plan
A bounded, paid diagnosis. It produces a shared evidence base and a prioritised plan with dependencies, controls, owners and decision gates.
GateWhat to build first - 02
Bounded spike or proof of concept
Only where a critical technical unknown remains. It answers one question against success criteria set in advance.
GateIs it feasible - 03
Minimum viable workflow
Data, rules, AI, interface and human review joined into something practitioners can use on real cases.
GateDoes it hold on real cases - 04
Beta
Real work is introduced gradually while failures, overrides, cost and adoption are observed.
GateIs it safe to go live - 05
Production and evolution
Live once the client approves data path, environment, permissions, ownership, support and continuity. Expansion follows evidence.
GateWhere to expand next
Every phase is specified
Inputs, client obligations, assumptions, exclusions, acceptance criteria, ownership and progression gates are written into each phase.
Running costs stay separate
Ongoing operation, support, model usage, licences and further modules are priced and governed separately from the build.
Ownership is contractual
Intellectual property, licences, support levels, change governance and exit terms are defined in each agreement, never assumed.
Control functions join early
For regulated clients, technology, security, risk, compliance, legal, audit and procurement take part from qualification onwards.
The structure protects both sides. The client does not pre-commit to a large build, and we do not absorb unlimited uncertainty into a fixed fee.
We also build our own products
An applied R&D and venture-building practice runs beside client work. Building products exposes real problems in data modelling, evaluation, deployment, cost and security, and those lessons return to client engagements.
Every product grew out of real client work. Some are now independent companies; others we build and run ourselves.
Venture StudioSee how the work is delivered
The delivery model, the principles behind it, and anonymised accounts of past engagements.