End-to-end agentic workflow, answered in full.

Everything we have delivered runs on Microsoft Azure, including Azure OpenAI. On a live insurance engagement the document pipeline was built from a blank repository on Azure in two weeks, 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 maps and interrogates the whole corpus for gaps and contradictions before any code exists, and the build then runs against the full requirement set with a model at maximum reasoning, pair-programmed with your engineers. Delivery runs through GitHub, and on that engagement we led the migration to it from Azure DevOps boards. Amazon Bedrock, Amazon SageMaker and Google Vertex AI are clouds we have not shipped agentic work on, and Kubernetes, Terraform and Apache Airflow are platform choices we would take with your own platform engineers rather than lead. Everything we have built agentically is a working proof of concept, built inside a live regulated estate, with productionisation now in progress.

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 and that is the cheap answer. If you do not, standing one up to host your first agentic workflow puts a platform programme in front of the thing you were trying to prove, and a managed runtime reaches production sooner. Terraform, or Bicep, or whatever your platform team already uses, matters for a narrower and more important reason than hosting: an agent's identity, its scoped permissions and its tool list should live in version control and be reviewed as code, because a permission granted through a console is the one nobody can account for later. Airflow, or any scheduler, is worth keeping in the picture because most end-to-end agentic workflows are mostly deterministic pipeline with an agent trajectory inside them, and modelling the deterministic parts as agent decisions buys non-determinism you then have to evaluate and explain. Tenhaw has not delivered on any of the three and that is a position rather than a track record.

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.

Deep before broad, and generalise on the way through. Take one complete process, with an accountable owner and a measurable outcome, all the way to production, because a narrow slice that genuinely runs end to end teaches you more than twenty steps automated to 80%. Then take the parts that will be needed every time and make them shared rather than rebuilt: agent identity and scoped permissions, permission-aware retrieval, an evaluation harness and regression suite, observability, a deployment path, and a standing agreement with your second line about which decision classes need human approval. That shared substrate is what makes the fifth agent cheaper than the first, and its absence is the usual reason an agent portfolio stops at three. Our own basis for this: we run the pattern on our own operations and have delivered components of it on client engagements; we have not yet taken a complete enterprise process fully agentic end to end for a client.

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.