Siddhartha Jagadesh

About

Backend engineering for enterprise AI

I work on agentic-AI platforms, LLM gateways and multi-agent orchestration at Salesforce/MuleSoft. My work sits underneath the applications, in the layer that decides who an agent is, what it can reach, which model answers it and what that costs.

Summary

I have spent about eight years building backend platforms, enterprise workflows and, most recently, the infrastructure behind production AI. Right now I am on the MuleSoft AI team at Salesforce, working on agent orchestration, agent-to-tool policy and the gateway in front of the model providers.

Almost none of this was built alone. The case studies note which parts were mine and which belonged to the team. What I like most is getting something to the point where a colleague can pick it up and use it safely without asking me first.

The problems I keep returning to are distributed systems, AI governance and what a platform should actually promise the people building on it.

Career narrative

Four phases

Each one changed what I thought the hard part of the job was.

  1. 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.

    • Backend product engineering
    • File and data workflows
    • Performance optimisation
    • User-facing reliability

  2. 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

  3. 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

  4. 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. Governance only works when it is built into the request path; written down as a policy elsewhere, 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, earlier domains last.

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
  • Streaming LLM responses

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
  • Delegated access
  • 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
  • Reliability engineering
  • Performance optimisation
  • System design

Earlier work

Domains from before the move into agentic-AI infrastructure: data pipelines, search systems and enterprise workflow products. Kept for context, not current focus.

  • Data pipelines
  • Privacy-oriented processing
  • Search infrastructure
  • MongoDB
  • Apache Solr
  • Enterprise workflow systems
  • Accessibility (WCAG)

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 to 2018

Engineering philosophy

What I have come to believe

  • Governance belongs in the request path

    A control bolted on afterwards is really just advice; built into the path every request travels, it becomes something the system does.

    Case study: Governed LLM gateway

  • Failures should be explicit and recoverable

    Collapsing several distinct failures into one generic error is quick to build and miserable to debug at three in the morning.

    Case study: Multi-agent orchestration

  • Abstractions should not hide operational reality

    A provider abstraction still owes you the answer to which model served a request, which one failed, and what it cost.

    Case study: Governed LLM gateway

  • Enterprise AI is mostly an infrastructure problem

    The distance between a working model endpoint and something a large organisation will adopt is identity, observability, cost control and policy.

    Case study: Multi-dimensional usage and cost governance

  • Good platform work makes the sharp edges unreachable

    Exposing everything a system can do is easy; the craft is making the useful part reusable while keeping the dangerous part out of reach.

  • Boring decisions age well

    Correctness and performance outlast whatever the architecture of the year happens to be.

    Post: Boring decisions age well
Read the case studiesGet in touch