Azure Integration & AI Platform Architect HI, I'M AKSHAY Kakoriya

I design API-first, event-driven integration on Azure — and lately, the AI systems that sit on top of it.

Gwalior, India · UTC+5:30 · Remote

AZ-305
AZ-204
CLAUDE ARCHITECT
7 YRS
AZURE

interfaces built two estates, 2022 — 25: 60+
integrations designed one estate of 200+, 2025 — 26: 50+
fewer recurring incidents one estate, 2022 — 24: ~30%
lower Azure spend one estate, 2022 — 24: ~15%

Introduction

About.

I design enterprise integration on Azure — API-first, event-driven systems that connect internal platforms to the outside world without breaking under load. Lately I've been doing the same for AI systems, and most of the hard parts turn out to be the same ones.

Seven years across Accenture, Cognizant and Capgemini took me from building interfaces to owning the architecture behind them: requirement analysis, design authority, solution design, and the production behaviour that decides whether a design was actually any good. Most recently that meant an ERP integration layer delivered against a fixed date, and the target architecture for moving a two-hundred-integration estate off its data centre.

The work I'm proudest of is rarely on the happy path. It's the retry policy, the dead-letter route and the idempotent handler that decide whether an integration survives a dependency failing — and the instrumentation that tells you which one fired. Most recently that same thinking carried into agentic AI on Azure AI Foundry, where what mattered was boundaries and evaluation, not model choice.

Integration Architecture

API contracts written and versioned before the implementation, policy-enforced at the boundary.

Case study

Event-Driven Systems

Asynchronous by default, synchronous by exception — and what that costs when it is wrong.

The decisions

Agentic AI on Azure

Agent boundaries, retrieval isolation and evaluation on AI Foundry — a build of my own.

The project

Reliability Engineering

Retry, dead-lettering and idempotency, written down as patterns rather than rediscovered.

The patterns

What I've built

Selected work.

Four engagements, newest first, then a project of my own and one practice page — each written around the decisions rather than the outcome: what was considered, what was chosen, and what that choice cost.

01 Case study

Two hundred integrations, counted before designed

A legacy integration estate with a data-centre exit date and no inventory — the count that had to come first, the four patterns it produced, and the design that was approved as the baseline for the build.

integrations inventoried: 200+
assigned a target pattern: 50+
low-level designs written: 20+

Read the case study

02 Case study

Thirty interfaces, one go-live date

Bespoke on-premises applications wired into a new ERP against a fixed date, with requirements still moving — the contract-first discipline that absorbed the churn, and what a batch of messages is worth.

Service Bus messages, peak day: 500K+
interfaces live at go-live: 30+
new-interface delivery: 3 wks → 1 wk

Read the case study

03 Case study

An estate nobody had documented

An integration estate taken over undocumented, deployed by hand and failing in ways nobody could explain — the order the team took it in, and the five decisions inside it that were mine.

fewer incidents, estate-wide: ~30%
lower Azure spend, estate-wide: ~15%
interfaces built or changed: 30+

Read the case study

04 Case study

The day the platform was built for

A utility's public customer platform meeting its first real storm — what gave way, what the team changed afterwards, and which of those changes were mine.

services and jobs shipped: 20+
API calls a day, normal load: 100K+
environments, released per service: 3+

Read the case study

Independent project

Retrieval that cannot leak, and an upgrade refused

My own build: a retrieval system over 1.5 million chunks where source isolation is a property of the topology rather than a prompt instruction, and where an 87-case evaluation set talked me out of a model upgrade.

chunks indexed: 1.5M
groundedness, 87 cases: 4.32/5
the upgrade refused: 19.7% vs 16%

Read the write-up

Practice

Reliability patterns for enterprise integration

The four patterns that decide whether an integration survives production — what each one costs, and when not to reach for it.

Retry with backoff
Dead-lettering
Circuit breaking
Idempotent processing

Read the patterns

Capabilities

What I work with.