About
Backend engineer, working on the platform layer beneath enterprise AI
Senior Software Engineer · Agentic AI Platforms · Distributed Systems
Summary
I have spent about eight years building backend platforms, enterprise workflow systems and, more recently, the infrastructure that production AI runs on.
Right now I am on the MuleSoft AI team at Salesforce. I work on multi-agent orchestration, the policies that govern how agents talk to tools and to each other, and the gateway that sits in front of the model providers, handling routing, quotas and cost.
Before that I was at Microsoft, ServiceNow and Zoho, working on data pipelines with privacy obligations attached, workflow products, search infrastructure and a fair amount of unglamorous performance and reliability work.
Almost none of this was built alone. The case studies say which parts were mine and which belonged to the team. What I have come to like most is the quiet part of the job: getting something to the point where a colleague can pick it up and use it safely without having to ask me first.
The problems I keep coming back to are distributed systems, AI governance and the question of what a platform should promise the people building on top of it.
Career narrative
Four phases
Each one changed what I thought the hard part of the job was.
Product foundations
Zoho
Uploads, migrations, downloads, a few prediction features. This is where reliability stopped being a word in a design doc for me. If an upload dies halfway through, the person on the other end knows immediately, and no amount of clever architecture makes up for it.
- Backend product engineering
- File and data workflows
- Performance optimisation
- User-facing reliability
Enterprise workflow platforms
ServiceNow
Workflow tooling for people who do not write code, which turned out to be a harder design problem than a technical one. I also spent a stretch fixing accessibility defects, and it changed how I build interfaces for good.
- Workflow automation
- Low-code experiences
- Accessibility
- Production-quality features
Large-scale data and services
Microsoft
Moving support data quickly while stripping out anything private, at a point where the privacy rules and the latency targets pulled in opposite directions. That tension was the whole job, and most of what I know about data pipelines came out of it.
- Distributed backend services
- Data pipelines
- GDPR-aligned processing
- Reliability at scale
Enterprise agentic-AI infrastructure
Salesforce / MuleSoft
How an agent proves who it is, what it is allowed to touch, which model answers it, and what the answer costs. The thread running through all of it is that governance only works when it is built into the request path. Written down somewhere as a policy, it is just a document.
- Agent orchestration
- MCP and A2A policies
- LLM gateways and routing
- Identity, quota and cost controls
Skills
Grouped by domain
Ordered by where my work sits today. No proficiency bars, because they suggest a precision nobody really has.
Agentic AI
The layer that lets agents actually do things: how they get composed, how they reach tools and each other, and how a request finds the right model.
- Multi-agent systems
- Agent orchestration
- Model Context Protocol
- Agent-to-agent protocols
- LLM gateways
- Model and provider routing
- Provider abstraction
- Tool-calling systems
- Multi-model orchestration
- Streaming LLM responses
- Semantic routing
- Semantic caching
AI governance
Making AI usage something you can attribute, cap and switch off. All of it enforced while the request is in flight, not reviewed after the invoice arrives.
- Policy enforcement
- Virtual and model proxy keys
- Request and token rate limiting
- Cost controls and attribution
- Usage governance
- Guardrails
- Delegated access
- Agent identity
- Centralised revocation
Backend and distributed systems
Everything above depends on this: services that stay up, fail in ways you can read, and still make sense when the load triples.
- Distributed systems
- API gateways
- Microservices
- Scalable web services
- Backend architecture
- Policy engines
- Configuration-driven systems
- Reliability engineering
- Performance optimisation
- Production troubleshooting
- System design
Data and search
Moving data fast while respecting fairly strict rules about what it can contain and who is allowed to see it.
- Data pipelines
- Near-real-time data movement
- Privacy-oriented processing
- Data scrubbing
- Search infrastructure
- Indexing and search optimisation
- MongoDB
- Apache Solr
- MySQL / SQL
Product engineering
Getting from a conversation with a customer to something running in production, including the parts of that journey that have nothing to do with code.
- Enterprise workflow systems
- Product architecture
- API design
- Accessibility (WCAG)
- Performance and stress testing
- Cross-functional execution
- Regulated-environment requirements
Languages
- Java
- Primary language for backend and platform work
- Python
- Services, data processing and tooling
- SQL
- Relational modelling and query performance
- JavaScript
- Product-facing interfaces when a job needs one
- C++ / C#
- Earlier work
Tools
- Git
- Android SDK
- ReactJS
- Django
Education
Bachelor of Technology
S.R.K.R. College of Engineering
2014 – 2018
Engineering philosophy
What I have come to believe
Governance belongs in the request path
A control bolted on afterwards is really just advice. Put it in the path every request travels and it becomes something the system does, not something a document asks people to remember.
Failures should be explicit and recoverable
Collapsing five different failures into one generic error is quick to build and miserable to debug at three in the morning. I have been on the wrong end of that more than once.
Abstractions should not hide operational reality
A provider abstraction still owes you the answer to which model served this, which one failed, and what it cost. Smoothing that away makes the diagram cleaner and the on-call shift worse.
Enterprise AI is mostly an infrastructure problem
The distance between a working model endpoint and something a large organisation will actually adopt is identity, observability, cost control and policy. Very little of it is the model.
Good platform work makes the sharp edges unreachable
Exposing everything a system can do is easy. The craft is in making the useful part reusable while quietly putting the dangerous part out of reach.
Boring decisions age well
Correctness and performance outlast whatever the architecture of the year happens to be. Most systems I have worked on were better off for a dull choice made carefully.