Shashank PandeyShashankPandey

1. 01

   Agents for business workflows

   At Auxiliobits I take business processes that people run by hand and build agents that work through the steps themselves, in the same systems a person would use. Earlier, at Vtopia, I built multi agent pipelines on LangChain for content generation and user onboarding.

   Auxiliobits, 2025 to now · Vtopia, 2023 to 2024

2. 02

   Tools and MCP servers

   I build the MCP servers and tool integrations that connect agents to company systems and APIs. A model takes a tool's description at face value, so I write tools the way I'd write a public API, and I decide early what an agent must never touch.

   Auxiliobits, 2025 to now

3. 03

   Evals, tracing and guardrails

   Nobody demos this part, and it's what decides whether people can rely on an agent. Before an agent goes near users, evals tell me how it behaves. Once it's live, tracing lets me follow a bad result back to the step that caused it, and guardrails limit what reaches the user.

   Auxiliobits, 2025 to now

4. 04

   LLM features in products

   Not every AI feature needs to be an agent. At Jewelnme I built product recommendations and customer engagement flows on LangChain and the OpenAI API, inside a jewellery ecommerce platform. Most of the work was ordinary engineering: getting the right data in, and the answer back where the product needed it.

   Jewelnme, 2024 to 2025

5. 05

   The backend underneath

   Agents and LLM features end up as calls inside ordinary services, so those services had better stay up. At Jewelnme I architected the NestJS backend and built its REST and GraphQL APIs. At Chaincode I designed and deployed microservices in Docker on AWS EC2, with Nginx in front and Redis caching to keep reads fast.

   Jewelnme, 2024 to 2025 · Chaincode, 2022 to 2023

1. I

   Does it need AI?

   It's the first thing I ask about any feature. A rule or a database query is often cheaper and easier to test. I use a model where the input is messy or open ended, and plain code for the rest. Sometimes that means less AI than anyone planned, which suits me fine.

2. II

   Models are dependencies

   A model is a dependency I don't control, and the least predictable one in the system. It gets what I'd give any flaky service. Slow calls go on a queue, runs get traced, and nothing it says reaches a user unchecked. Most of that is ordinary backend work, the same I'd do for any service I don't control.

3. III

   Own the whole feature

   I like owning a feature from the first design note to production, prompt and screen included. LLM features tend to break at handovers, so when a team shares one, I write the handovers down: what goes in, what comes back, and what happens when the model is wrong.

32 specimensGroups A to F