End-to-end agentic workflow implementation

Microsoft Azure, including Azure OpenAI. On a live insurance engagement the document pipeline was built from a blank repository on Azure in two weeks as a working proof of concept, now being productionised against the client's security standards, and a separate proof of concept on Azure OpenAI scored and validated entity-resolution output. The build method is Git and markdown rather than a framework. Every requirement becomes structured markdown, a model interrogates the corpus for gaps and contradictions before any code exists, then the build runs against the full requirement set at maximum reasoning, pair-programmed with your engineers. Delivery runs through GitHub, and we led that engagement's migration from Azure DevOps boards. Kubernetes, Terraform and Airflow we take with your platform engineers and price into scope.

Not for the first workflow, and the right ordering saves a quarter. If you already run a Kubernetes cluster, an agent is another workload on it. If you do not, standing one up puts a platform programme in front of what you were trying to prove, and a managed runtime reaches production sooner. Terraform, or whatever your platform team already uses, matters for a narrower reason than hosting. An agent's identity, its scoped permissions and its tool list belong in version control, reviewed as code, because a permission granted through a console is the one nobody can account for later. Airflow, or any scheduler, keeps the deterministic majority of a workflow deterministic. All three we take alongside your platform engineers and price into scope.

A complete business process (intake, decision, action and record) where agents perform the work and humans govern it, rather than each step being assisted while the overall shape stays the same. The distinction matters because assisting individual steps typically leaves end-to-end cycle time almost unchanged, since the waits between steps were always the majority of elapsed time.

Enterprise AI is artificial intelligence doing a real share of an organisation's work, inside its systems, its permissions and its audit trail, rather than a licence per employee alongside a process that has not changed. In practice the phrase describes four commitments rather than a technology: the agent acts under an identity of its own, so what it did can be reconstructed later; retrieval answers only from what the person asking is permitted to see; the evidence a governance function will want falls out of the run rather than being assembled afterwards; and the decisions agents may take are bounded by consequence and reversibility, agreed with your second line. Enterprise AI that scales adds a fifth: the identity model, the retrieval, the evaluation harness, the observability and the deployment path are shared between agents rather than rebuilt for each one.

Assistants change how a step is done, and enterprise AI changes what the process is. That difference shows up in the number the board is watching. Making every step faster compresses the minority of a cycle time that was ever work, because the majority of elapsed time in most consequential processes is waiting: for a handoff, an approval, a queue, someone's availability. It also shows up in what has to exist around the system. A tool used by a person inherits that person's access, judgement and accountability, and an agent doing the work inherits none of them, so identity, permission-aware retrieval, audit evidence and an agreed human-approval boundary stop being good practice and become the design. Licences are a procurement decision. Enterprise AI is an operating-model one.

Not for a client, and we would rather say so here than have you find it in month two. We are partway through doing it to our own operations: the development pipeline is AI-engineering-first, the social content pipeline is semi-automated, research agents run competitor monitoring and opportunity-gap analysis, and the go-to-market process is being rebuilt the same way. On client work we have delivered components of the pattern rather than the whole of it, including a two-week proof of concept taking PDFs through to business intelligence on Azure for a London specialty insurance business, now being productionised against their security standards, and confidence-scored validation of entity-resolution output with human routing. Everything we have built agentically runs on Microsoft Azure, including Azure OpenAI, and nothing has shipped on Amazon Bedrock, Amazon SageMaker or Google Vertex AI. Taking a complete enterprise process end to end is exactly what our build teams are scoped for, and on the call we will tell you which parts of yours we would be doing for the first time.

Deep before broad, generalising on the way through. Take one complete process, with an accountable owner and a measurable outcome, right through to production. A narrow slice that runs end to end teaches more than twenty steps at 80%. Then make the parts every agent needs shared, not rebuilt: identity and scoped permissions, permission-aware retrieval, an evaluation harness, observability, a deployment path, and an agreed boundary with your second line on which decisions need a human. Tenhaw's shared layer is an open-source engineering handbook of 72 rules with stable identifiers and RFC 2119 severities, enforced by an agent rather than remembered by a human. That substrate is why the fifth agent costs less than the first, and its absence is why portfolios stall at three.

Because the work was rarely the bottleneck. In most consequential processes the majority of elapsed time is waiting, for a handoff, an approval, a queue, someone's availability. Making each step faster compresses the minority of the timeline. Reducing cycle time requires removing the waits, which is process and operating-model change rather than tooling.

Five places. Nobody owns the process end to end, so it optimises by segment and stalls at the functional boundary. The exception path was not designed, so the automated portion finishes and the residue is harder than the original job. Governance designed for human decisions either bottlenecks the agents or gets bypassed. Programmes go broad rather than deep, automating every step to 80% and finishing nothing. And nothing is generalised between agents, so every one costs what the first one did and the programme stalls at the point where the next business case cannot be justified.

By consequence and reversibility rather than by complexity. Agents take decisions that are high-volume, observable and cheaply reversible; humans retain decisions that are consequential, contested or hard to undo. That boundary is written down per decision class, the escalation path across it is designed, and your second-line risk function co-authors it rather than reviewing it afterwards.

Design the exception path in the first fortnight, because it decides whether the economics work. The happy path is typically 70% of volume and only 20% of effort, so an implementation that only handles the easy cases hits a wall once the automated portion is done and the remaining work is harder than before, because the routine cases that used to give staff context have gone. Route by confidence and consequence, specify the human path from the start, and resource it properly rather than treating it as overflow. Designing it late is the most expensive sequencing error in this kind of work.

Usually not as they stand, because they assume a human at every decision point. Run agents through approval thresholds and four-eyes checks designed for people and one of two things happens. Either the controls become a bottleneck that removes the benefit of automating, or they get quietly bypassed, which is worse. The fix is to redesign the controls for the new decision profile, with your second-line risk function as co-authors rather than after-the-fact reviewers, based on which decisions are consequential and which are cheaply reversible, instead of inheriting a control set built for a process that no longer exists.

No, and building it first is its own way of never shipping. A platform stood up before any real process runs on it can absorb a year of engineering with nothing a board can see, and its requirements are guesses until real agents exist. Tenhaw's two-week proof of concept for a London specialty insurance business took PDFs through to business intelligence with no platform built first. The opposite failure is as common. With nothing shared between agents, the tenth costs what the first did, every security approval is repeated, and nobody can justify the twentieth business case. So ship the first process end to end, then pull the shared pieces out while delivering the second, once there are two real examples to generalise from.

Pick a complete process rather than a use case, one with a measurable business outcome, an accountable owner, and enough size that improving it moves a number leadership already watches. Map the elapsed time before committing. In most consequential processes the majority of that time is handoffs, approvals and queues rather than the steps themselves, and the analysis regularly redirects a programme away from the step everyone assumed was the bottleneck. Choose from that picture rather than from a use-case list, and one you can take all the way through intake, decision, action and record rather than four steps out of six. Tenhaw's Globelynx engagement cut lead time by 60% inside six months, the kind of number a first process should move.

Yes, but establishing that ownership is the first piece of work, and Tenhaw says so before contracting rather than halfway through a build. Most consequential processes cross three or four functions, each owning a segment, so taking one agentic needs somebody with authority over the whole. Without that the programme optimises segments, stalls at the first functional boundary, and leaves faster steps inside an unchanged cycle time. Sometimes the answer is a sponsor with real decision rights across those functions, sometimes it is genuine operating model work. Tenhaw's founder co-designed one of those at HSBC Global Payment Solutions, covering 500 teams and a $450M portfolio, piloted rather than rolled out. Either way it is cheaper to settle at the start than once agents are live.

Their work changes shape rather than disappearing. In an agentic process people govern the work rather than perform it, taking the cases that need judgement, owning the controls the agents run inside, and deciding what happens when something falls outside them. On a London specialty insurance proof of concept Tenhaw paired throughout with one of the client's engineers, who finished 70% confident they could run the process unaided. Plan for a harder job than the old one, because the routine cases that used to build context and judgement are the ones agents take first. So staff the exception path deliberately rather than as overflow, and keep the people who work exceptions today inside the design, since they know which edge cases genuinely occur.

Yes, with one honest change in who leads the platform work. Everything Tenhaw has delivered agentically runs on Microsoft Azure, including Azure OpenAI, and nothing has shipped on Amazon Bedrock, Amazon SageMaker or Google Vertex AI. The shape of the pattern holds across clouds. What genuinely changes is the document-understanding service, how identity federates from your source systems, and where the index and the embeddings physically sit. On an AWS estate Tenhaw would work alongside your own platform engineers instead of leading the platform work, bringing a method it publishes in full and free for anyone to adopt rather than a cloud it is learning on your budget.

Only part, in most cases. Most end-to-end agentic workflows are mostly a deterministic pipeline (ingest, extraction, enrichment, load) with an agent trajectory inside it, and the agent belongs where the next step is genuinely chosen at run time rather than known in advance. Modelling the deterministic parts as agent decisions buys non-determinism you never needed, and you pay for it twice, once in evaluation because every trajectory has to be tested, and again when somebody asks why a particular case went the way it did. A scheduled graph is dull, cheap to explain and easy to audit. Keep the judgement in the agent and leave the plumbing to the pipeline.

Baseline the elapsed time before anything is built, end to end rather than step by step, using the map that shows where the handoffs, approvals and queues sit. The map is the measurement instrument as well as the design input, because once you know how long a case waited at each boundary before, you can show what the rebuilt process does to the same boundaries rather than argue about how much faster individual steps feel. Then report against it every month. Tenhaw holds itself to that on its own engagements, where a month that delivers no measurable value is reported as a failed month rather than smoothed into the next one.

Only for what is genuinely new about it, provided the parts every agent needs are shared rather than rebuilt. Agent identity and scoped permissions, permission-aware retrieval, an evaluation harness, observability and the deployment path are properties of the platform, approved once and then inherited, and they are best pulled out of your first two processes rather than built up front. Hold a standing agreement with your second line about which classes of decision need a human, so that boundary is not renegotiated each time either. What is left to assess for any new agent is the decisions it takes, the data it touches and the tools it can call.