Using the pattern guides: practical answers.

Thirteen guides to the agentic programmes enterprises are running now, grouped by subject. Whole programmes covers document intelligence, voice agents and conversation intelligence, end-to-end agentic workflows, the AI-native SDLC and the target operating model for an AI-native organisation. How it is built covers retrieval and RAG, MCP and tool calling, guardrails and accuracy control, and choosing between RAG, fine-tuning and prompting. Proving it and controlling it covers agent evaluation, governance and regulatory evidence, and agent identity and access. Paying for it is the business case: ROI, payback and what a finance function should refuse to accept. Every guide sets out why the pattern stalls, how Tenhaw would sequence it, and whether it is written from delivered work.

Start from the symptom rather than the title. Every card on Tenhaw's guides hub carries a line drawn from that guide's own failure modes: if the pilot was judged by demonstration and nobody will sign it off for production, that is agent evaluation and assurance; if you are drowning in PDFs the business will not act on, document intelligence; if the AI coding licences are bought and adoption has plateaued, the AI-native SDLC; if the benefit is stated in hours and finance has started asking which budget line moves, the business case. The hub also carries a question index, and an assistant you can describe the problem to.

Delivered means the guide is written from work Tenhaw has actually done on real engagements, and it says plainly where the delivery stopped, so a proof of concept is labelled a proof of concept, never production. Our approach means the guide is the method Tenhaw would bring, with what it draws on named at the top of the page rather than in a footnote. Five of the thirteen guides carry the first label and eight the second, and the split is the structure of the hub rather than small print in a card corner.

Five guides are written from delivered work: document intelligence, the AI-native SDLC, the target operating model, voice agents and conversation intelligence, and end-to-end agentic workflows. Each says where the delivery stopped. The document pipeline ran end to end on Azure on a specialty insurance engagement, as a working proof of concept rather than a production system. The build method produced a working proof of concept in two weeks, pair-programmed with the client's own engineer. The operating-model discipline was co-designed, piloted and proved at 500-team scope inside HSBC, and that work was not an AI programme. The other eight guides are the method Tenhaw would bring, and say so above the fold.

Three are marked on the hub as the ones UK insurers and banks ask about most: AI governance and regulatory evidence, document intelligence to business intelligence, and agent evaluation and assurance. Tenhaw's own document-intelligence work ran end to end on Azure on the PPL engagement, a working proof of concept in two weeks rather than a production system. Between them they cover the inventory and evidence a regulator will ask for, the document-heavy work where an organisation usually meets agentic AI first, and the release gate that decides whether a pilot ever reaches production. What each regime actually requires of an agent, SM&CR, SS1/23, Consumer Duty, Solvency II and operational resilience, is written up separately on Tenhaw's financial services sector page.

Yes. All thirteen of Tenhaw's guides carry a sources list you can open, and the rule applied throughout is that every source was opened and read before it was attached; where nothing survived that check, the claim was softened rather than propped up with a plausible-looking link. So survey figures cite the published survey, research claims cite the paper, and regulatory statements point at the regulator's or legislator's own text, each with a note saying what it supports. It is the same discipline Tenhaw's pricing page runs on, where every competitor day rate is quoted from the supplier's own published rate card and linked to it.

They name them, and each name carries the same honesty label the guides do. Where a guide takes a position on a named technology, the item is marked delivered where Tenhaw has shipped on it and our approach where it is a view, because naming a technology reads as a claim to have shipped on it. The MCP and tool calling guide goes further and tables six enterprise systems, Salesforce, ServiceNow, SharePoint and Microsoft 365, Snowflake, Databricks and Workday, with each one's authentication and permission model read from the vendor's own documentation on a stated date rather than recalled.

They sell by being useful rather than by withholding. Each of Tenhaw's thirteen guides publishes the failure modes, the method and the sources in full, and several end by saying the cheapest first step is work that does not need Tenhaw at all: writing your own engineering standard, running a prompting baseline before anyone builds anything, or spending a fortnight on your corpus and its permission model. Publishing the method is deliberate; The Tenhaw Way and the seventeen how-to guides under it are free to adopt without hiring anyone. Each guide does name the engagement it maps to, with the published price, for the reader who wants the work done rather than described.

Each guide points to relevant practical help. Learn develops a working method: the leadership day is £8,500 and the six-week team programme £24,000. Prove tests one workflow at £20k–£55k fixed or assesses the organisation through the £44,000 readiness audit. Deliver takes one agreed workflow into production and use in 90 days for £120,000 or £180,000 fixed. Standalone design is available on request, and the guides and Tenhaw Way remain free to read and use.

Bring the sentence to a call. The thirteen guides are the patterns Tenhaw keeps meeting, and the hub says plainly that describing a problem and being told there is not a guide for it yet is a real answer rather than a fudge. Thirty minutes with James Rooney gets you either the guide that covers it or that answer. Equally, if what you need is one of these stood up rather than reasoned about, say so, and Tenhaw will tell you whether it is the right firm for it.

When the pattern is new to your estate and the delivery method is not. Everything Tenhaw builds to is published, from the operating model to a 72-rule open-source engineering standard with RFC 2119 severities. The proof points are specific. A PPL insurance proof of concept took PDFs to business intelligence on Azure in two weeks, pair-programmed with the client's own engineer, who ended the fortnight 70% confident of running the process unaided. Velocity84, Tenhaw's build lab, has produced more than twenty agentic products across voice, video, document reading, mobile and go-to-market. It opens at an Agentic Proof of Concept, £20,000–£55,000 fixed over 2–4 weeks, a stage you can stop, and Tenhaw will say if it is the wrong firm for the work.

No. Tenhaw's guides hub carries an index of twenty questions, the ones technical and finance buyers actually type about RAG, MCP, hallucination, fine-tuning and payback, each linking straight to the guide that answers it, usually in the questions section at the foot of that guide. Every card also shows a read time counted from that guide's own text, so you know what you are committing to before you click. They run from eight minutes to twenty-two, and MCP and tool calling is the longest by some way. The hub and the guide page count that time the same way, so the two never disagree.

Yes, and it is a good use of them. Every one of Tenhaw's thirteen guides publishes its failure modes in full, so take the section on why that pattern stalls into the room and ask which of them the proposal has actually designed against. The ones that catch most plans are unglamorous: whose authority an agent's tool calls carry, whether retrieval can return a document the person asking is not allowed to open, and what the thing costs to run rather than to build. Then apply to your supplier the rule Tenhaw applies to itself. Ask which of these patterns they have shipped, and where the delivery stopped.

The guides carry source and review dates so you can see which statements depend on a changing platform or rule. The MCP provider references and the AI Act timeline were checked on 5 November 2026. Each provider row links its own documentation, and the governance guide links the Commission's current overview and final-text route. Confirm the relevant tenant, release and legal position before relying on those details for a design. The original publication date of a study is also kept visible, because an older experiment is evidence about its stated setup, not a current ranking of every model.

Some of them, and it is worth saying which. Most of Tenhaw's thirteen guides are written for an organisation already past a demonstration, where the pilot worked and scaling it now needs decision rights to move, or the coding licences are bought and adoption has plateaued. Two are useful before anything is built. The business case guide builds the case for approval rather than defending it afterwards, and RAG, fine-tuning or prompting settles the architecture argument, starting with a prompting baseline that costs a few days and needs nobody hired. The same holds for the engineering standard Tenhaw builds to, an open-source handbook of 72 rules with stable identifiers and RFC 2119 severities, published on GitHub and adoptable long before a pilot exists.