Retail, industry and energy, answered in full.

In engineering knowledge work rather than operational decisioning: retrieval across decades of technical documentation, simulation and scenario modelling that amplifies scarce specialist time, capital project reporting across distributed programmes, and compliance evidence gathering. Operational decisions in industrial settings are usually too consequential and too hard to reverse for early agentic autonomy.

Not comfortably, and it is the wrong place to start. A safety case argues, with evidence, that risks are reduced so far as is reasonably practicable, and that argument depends on the behaviour of the system being characterised. A system whose output is not reproducible is difficult to argue for, and a model your supplier updates on their release schedule breaks the argument silently. The realistic pattern is to keep agents on the analysis side of the boundary, make the boundary explicit so that crossing it is somebody's decision rather than a drift, require a management-of-change gate before a pilot touches anything safety-relevant, and pin model versions under change control your safety function owns. Tenhaw employs no safety engineers and does not write or assess safety cases.

NIS2 does not regulate AI as such. It regulates the security and resilience of entities in scope, and since October 2024 has covered more sectors, put accountability on management bodies and added supply chain security and fast incident reporting. An agent in an operator's estate is in scope like any other system. In OT the question is segmentation, and the boundary between corporate IT and the control domain exists to stop things reaching across it. An agent is a new actor asking to cross. UK operators of essential services face the same questions through the NIS Regulations and the NCSC's Cyber Assessment Framework, with IEC 62443 the engineering standard underneath. Design answers first: what identity does the agent hold, what can it read, and can it write anything at all.

ISO/IEC 42001 is a certifiable management system for AI: policy, roles, risk assessment, controls and evidence that they operate. The NIST AI Risk Management Framework is voluntary and organised around four functions, govern, map, measure and manage, with a generative AI profile alongside it. Neither is law, and both are increasingly what procurement and insurers ask about. The failure mode is adopting either as a document rather than as controls, so the register and the running system drift apart. Building the inventory, the evaluation records and the ownership trail during delivery costs a fraction of reconstructing them in a remediation programme. Tenhaw is not certified to ISO/IEC 42001. It is under assessment, and the security page says where that stands.

By designing for asynchronous operation from the start. Tenhaw ran exactly this at Anglo American across the UK, Australia and the USA, building an agile blueprint lightweight enough that specialists onboarded fast, throughput data feeding simulation, and outcome-based milestones rather than project plans, so progress remained legible without synchronous coordination.

Yes. Tenhaw set up and ran the Data, Simulation and DevOps teams behind Anglo American's hydrogen-powered mining programme, work that underpinned a £40bn business case and spun out as First Mode. Tenhaw also made global delivery predictable at Yondr across data centre operations in the UK, US and Singapore.

Usually yes, provided it is scoped as an integration across the IT and OT boundary rather than as an analytics project. The failure we see is a pilot pulling historian data to a cloud model endpoint by a route the security function never approved, because nobody treated the agent as a new actor crossing a boundary built to stop exactly that. Our defaults are read-only access, a dedicated non-human identity with a tested revocation path rather than a shared service account, and no write path into the control domain unless your OT security function designs it. Early work runs against mocked services or synthetic data, so the hardest approval is not blocking the fastest-moving phase.

That is the first place we look in this sector. Deep domain expertise sits with a small number of highly qualified people whose time is the actual constraint on the business, so an agent that amplifies scarce expertise is worth far more than one automating work you have plenty of. In practice that means simulation and scenario modelling, so a specialist can explore ten scenarios rather than two, and analysis prepared to the point where their judgement is the only thing still required. Expect scepticism from those same people, and expect it to be well-founded. You earn it with evidence on their own problems.

Yes, and it is usually where we would start here. Engineering knowledge retrieval across decades of technical documentation is the first place we look, because that material holds hard-won judgement that is otherwise locked in a filing system. Unstructured is normal and manageable. Tenhaw deploys on client infrastructure under your policies, with UK data residency by default, so on-premise is not a blocker either, and the documents never need to leave your estate to become retrievable. What the constraint really changes is sequencing. Expect early effort to go into access and structure before the impressive demos appear, and plan for it.

By separating the asset business case from the workflow business case. Capital cycles mean the case for the asset itself is measured in years, and nothing about agentic AI changes that. The workflows around the asset move on much shorter cycles. Capital project reporting consolidated across distributed programmes, compliance evidence gathering where the audit trail is the deliverable, and engineering knowledge retrieval all return value on the cadence of the work rather than the asset lifecycle. Engagements here are retainer-shaped rather than milestone-shaped, and Tenhaw reports measurable value every month, counting a month that delivers none as a failed month. That keeps a long programme honest while the asset case takes its own time.

Not by default, and not unless your OT security function designs the path itself. Our default is read-only across the IT and OT boundary, with no write path into the control domain, because that segmentation exists precisely to stop things reaching across it. An agent is a new actor asking to cross, so it gets a dedicated non-human identity with a tested revocation path rather than a shared service account, and its activity can be told apart from a person's afterwards. It is also where the value is not. In this sector the return sits in the analysis that informs decisions rather than in the decisions themselves, and anything informing a safety-relevant judgement needs a management-of-change gate before the pilot.

Treat it as a change, because that is what it is. A supplier updating a model is a change whether or not anyone in your organisation initiated it, and any change to a safety-related system triggers management of change and reassessment. The awkward part is that the update lands on the supplier's release schedule rather than yours, so our default is pinned model versions with change control your safety function owns. An update then becomes a decision you take on your own timetable rather than an event you discover. We also keep evaluation results as records alongside the runs that produced them, so moving version gives you a measured before and after rather than a difference of opinion.

Name the boundary, and make crossing it somebody's decision. A tool arrives as decision support, becomes the thing operators actually rely on, and no management-of-change assessment is ever triggered because nothing in the control system changed. That is how the line gets crossed, by drift rather than by decision. So we write down which human judgement the workflow informs, design the point where a person is required rather than leave it to a line in the training pack, and treat any use that starts informing a safety-relevant judgement as a management-of-change gate before it goes further. Our contribution is seeing that line coming and bringing your safety function in before it is crossed.

All three, at different moments, and the order matters. Engineering leads, because the value in this sector is engineering knowledge work: retrieval across technical documentation, simulation that amplifies scarce specialist time, capital project reporting across distributed programmes. OT security joins while the work is still a design, rather than after it has quietly become an integration that nobody scoped as one, since we ask what identity an agent holds and what it can reach before we ask what it can do. Your safety function is needed where a workflow informs a safety-relevant judgement, and that is the moment to stop and involve them, not the month after the pilot.

Yes, and it is a real source of value here. Engineering and delivery teams spread across three continents make asynchronous working a necessity rather than a preference, and the cost of that shows up as waiting when a question asked at five in London is answered tomorrow. Agentic workflows that assume a synchronous team in one time zone do not survive contact with that reality. So we design so that no step needs a particular person awake, and put agents on the assembly work in between, keeping the written record current so the next time zone starts from something. Tenhaw made global delivery predictable at Yondr across the UK, US and Singapore, though that was delivery discipline rather than agents.

Yes, and it is one of the first places we look in this sector. Consolidating capital project reporting across distributed programmes is knowledge work, where the inputs are trackers, documents and reports in different formats from teams in different time zones, and the effort goes into assembling a consistent picture rather than deciding anything. That makes it good agentic territory, because a person still reviews the output, and it is the same person who would otherwise have assembled it by hand. It also stays well clear of the control domain, so it can move at its own pace while the safety-adjacent conversation takes as long as it needs to take.

Yes, and it is often the soundest first workflow here, because the audit trail is the deliverable rather than a by-product. The work is finding, citing and assembling evidence that already exists across systems and sites, which is retrieval with a paper trail attached, and a person still signs. Two design points carry it. Every item cites the source it came from, so an assessor can follow it back rather than take the summary on trust. And the model version and the run that produced each answer are kept as records, so the same question can be reconstructed months later. It also never reaches across the boundary into the control domain.

Less than a project would take, and in short structured blocks rather than a standing commitment. We design around sessions to set the problem, judge outputs and correct them, with the long stretches of work happening without your specialists in the room. Early work runs against mocked services or synthetic data, so their time is not spent unblocking approvals during the fastest-moving phase. We pair with your permanent engineers as we build, with measured skill transfer, because the point is to leave capability behind rather than a dependency on us. The AI Readiness Audit works the same way: four weeks, £44,000 fixed, sitting with the people who do the work rather than issuing a survey.