Engagement Types
Seven ways organisations engage us. Each is described by what it is for, who it is for, what the work involves and what you get. We publish no prices, durations or return figures — not as a courtesy, but because we cannot know them honestly before we know your data, your constraints and your decision rights.
Pick the shape that matches where you are
Most engagements start with the first and move into the second or third. Some organisations need the fourth. A few need all of them, in sequence.
Enterprise AI Readiness Assessment
A CIO or CTO who needs to know what is actually feasible before committing budget or making an announcement.
Typical work
- Constraint mapping: identity, network, data residency, isolation, procurement and regulatory position
- Data and systems reality check across the candidate process areas
- Feasibility of each candidate use case, scored against data readiness and consequence
- Platform and deployment options, with what each excludes
Enterprise AI Deployment
An organisation that has chosen a platform and needs it installed, governed and reachable inside its own environment.
Typical work
- Deployment topology selection: cloud, dedicated, private or isolated
- Identity, group and access integration with the existing directory
- Network paths, data boundary and outbound/inbound control
- Quotas, cost ceilings, upgrade path and support model
Agent Engineering Engagement
A data or AI engineering team that needs an agent to do real work against real records, under constraints.
Typical work
- Business ontology, definitions and rule set, versioned
- Context and retrieval design per task and per source
- Reconciled data access layer with data-quality findings reported to the owner
- Tool and API contracts with least-privilege permissions
Business Application Build
An operations or finance team carrying a process on spreadsheets and email because the systems do not talk to each other.
Typical work
- Process capture, including the workarounds people have invented
- Data model, reconciled views and the single agreed definition
- Application build: exception queue, drill-through, audit trail, roles and access
- AI-assisted features where they help, with evaluation and fallback
Data & Context Foundation
An organisation whose agents cannot be trusted because the records disagree, and whose data team is stretched.
Typical work
- Definition and ownership programme for the entities in scope
- Reconciled views and a data-quality rule set with owners
- Reference data, identifiers and cross-system mapping
- Access layer with identity, permissions and an audit path
Organizational Transformation Programme
A transformation executive who knows the technology works and is failing to make it stick.
Typical work
- As-is process map including the informal workarounds
- Target process and human–AI workflow design with explicit handoff points
- Role redesign, capability impact and the training that follows from it
- Governance, decision rights, escalation and accountability
Engineering Portfolio Support
A delivery organisation running several agent projects that need consistent standards, reusable components and senior review.
Typical work
- Reference architecture and engineering standards for the portfolio
- Reusable context, ontology, tool and evaluation components
- Senior review of design and code, with a consistent bar
- Shared evaluation and governance patterns across projects
Each engagement, in full
Enterprise AI Readiness Assessment
There is interest, a budget line, and a list of vendor options. There is no shared understanding of what the enterprise could realistically run, where the data would come from, or which decisions could safely be delegated to an agent.
For whom: A CIO or CTO who needs to know what is actually feasible before committing budget or making an announcement.
What the work involves
- Constraint mapping: identity, network, data residency, isolation, procurement and regulatory position
- Data and systems reality check across the candidate process areas
- Feasibility of each candidate use case, scored against data readiness and consequence
- Platform and deployment options, with what each excludes
- A sequenced roadmap with the first project sized
What you get
A written assessment your technical, security and finance functions can each use, and a decision about whether to proceed.
Boundary
We do not turn an assessment into a paid phase one by designing it so. If the honest recommendation is not to proceed, that is the deliverable.
Enterprise AI Deployment
A pilot exists. It runs on someone's laptop, with a personal account, outside the identity system, with no data boundary and nobody accountable when it goes down.
For whom: An organisation that has chosen a platform and needs it installed, governed and reachable inside its own environment.
What the work involves
- Deployment topology selection: cloud, dedicated, private or isolated
- Identity, group and access integration with the existing directory
- Network paths, data boundary and outbound/inbound control
- Quotas, cost ceilings, upgrade path and support model
- Operational handover: runbook, monitoring, training, named owner
What you get
A running platform inside your environment, governed to your standard, with your team able to run and change it.
Boundary
We will not claim vendor authorisation, certification or regional availability we cannot evidence, and we will not work around a licensing restriction to deliver a deployment.
Agent Engineering Engagement
The prototype answers well on curated data. In production it reads eleven systems, three of which disagree, and produces a confident answer with no provenance.
For whom: A data or AI engineering team that needs an agent to do real work against real records, under constraints.
What the work involves
- Business ontology, definitions and rule set, versioned
- Context and retrieval design per task and per source
- Reconciled data access layer with data-quality findings reported to the owner
- Tool and API contracts with least-privilege permissions
- Validation, evaluation harness, approval gates and run-level traceability
What you get
An agent that does a bounded, valuable piece of work, with evidence attached to every output and a control on every consequential action.
Boundary
We do not deliver a system whose behaviour cannot be explained. If a result cannot be traced to the records and rules that produced it, it is not finished.
Business Application Build
A backlog nobody clears, a reconciliation done by hand every month, and a definition of the problem that changes depending on who you ask.
For whom: An operations or finance team carrying a process on spreadsheets and email because the systems do not talk to each other.
What the work involves
- Process capture, including the workarounds people have invented
- Data model, reconciled views and the single agreed definition
- Application build: exception queue, drill-through, audit trail, roles and access
- AI-assisted features where they help, with evaluation and fallback
- Hardening, runbooks, documentation and team training
What you get
An application in production use, with the business running the process through it and the team able to change it.
Boundary
We state in writing whether a build is a demonstration, a prototype or production-ready, and what would have to change for it to move up a level.
Data & Context Foundation
Every agent project rediscovers the same problems: unclear definitions, unreconciled sources, and no agreed view of what the business data means.
For whom: An organisation whose agents cannot be trusted because the records disagree, and whose data team is stretched.
What the work involves
- Definition and ownership programme for the entities in scope
- Reconciled views and a data-quality rule set with owners
- Reference data, identifiers and cross-system mapping
- Access layer with identity, permissions and an audit path
- Monitoring of freshness, completeness and reconciliation status
What you get
A data foundation that agents can be built on, and that keeps telling you when it has drifted.
Boundary
This is not a data-warehouse programme. We build the foundation the agent work needs, and we say if that is the smaller or larger thing.
Organizational Transformation Programme
The system is technically sound, deployed correctly, and used by nine people out of four hundred. The organisation has no reason to change how it works.
For whom: A transformation executive who knows the technology works and is failing to make it stick.
What the work involves
- As-is process map including the informal workarounds
- Target process and human–AI workflow design with explicit handoff points
- Role redesign, capability impact and the training that follows from it
- Governance, decision rights, escalation and accountability
- Measurement framework agreed before launch, and reviewed after
What you get
An organisation operating differently, with the change measured rather than assumed.
Boundary
We do not deliver a roadmap and leave, and we do not claim a cultural outcome we cannot influence — we design the conditions and measure the result.
Engineering Portfolio Support
Each project reinvents its own ontology, its own rule framework and its own approval pattern, and quality depends entirely on which team picked it up.
For whom: A delivery organisation running several agent projects that need consistent standards, reusable components and senior review.
What the work involves
- Reference architecture and engineering standards for the portfolio
- Reusable context, ontology, tool and evaluation components
- Senior review of design and code, with a consistent bar
- Shared evaluation and governance patterns across projects
- Capability building, so the portfolio stops depending on us
What you get
A portfolio that delivers consistently because the standards are in the codebase rather than in a document.
Boundary
The intent is to make you independent of us. If we are still indispensable in two years, we have done this engagement badly.
The ones we are asked most
Answered directly, including the parts where the answer is "we do not know yet, and here is how we would find out".
Q1How much does a project cost?
We do not publish prices, and we will not quote a fixed number before we understand the scope. Cost depends on the data, the constraints, the number of systems involved and how much of the organisation has to change. What we will do in a first conversation is give you the shape of the work, what it depends on, and the variables that move the number.
Q2How long does it take?
Similarly, we do not publish durations. A deployment of an existing platform in an existing environment is a different order of work from engineering an agent against reconciled data, and organisational change has its own clock, which is usually the longest one. We will give you a range and explain what drives it.
Q3What return should we expect?
We will not put a number on it, because we cannot know it honestly before we know your baseline and your baseline may not be measured. What we can do is agree what will be measured, when it will be judged, and who owns that judgement — before the work starts, not afterwards.
Q4Do you work fixed-price or time-and-materials?
It depends on the shape of the work. Where the scope is genuinely bounded — an assessment, a deployment into a known environment — a fixed scope is reasonable. Where the work is discovery, data reconciliation or organisational change, an open model is more honest. We agree the commercial model after the assessment, not before it.
Q5Can you work alongside our internal team?
Yes, and we prefer it. The handover is part of the deliverable: your engineers should be able to change what we build without us. If that means we are less useful afterwards, that is the point.
Q6What if we already have a vendor or integrator?
That is common and usually the right arrangement. We work with existing partners, take the parts that need deep engineering, and leave the parts they are better at. Responsibilities are agreed explicitly so nothing falls between us.
Q7Do you sign NDAs and work under them?
Yes. Where we are asked to work with your data, we work under NDA, and the demonstration of the method against your records can be done entirely within that agreement.
Q8What do you need from us to start?
A named sponsor, a named technical owner, access to the systems in scope, and agreement on the decision the work is meant to improve. If any of those is missing, we will say so at the start rather than discover it in month two.
Tell us which one this is
Or describe the problem and let us tell you. Either way, the first conversation should end with you knowing whether this is worth doing.