Vamsi Krishna — Hyderabad, India

Enterprise AI systems,designed like productsand governed like infrastructure.

CurrentlyEnterprise Agentic AI Platformin productionEnterprise MCP Gatewayin productionSelf-Service Support Assistantin productionClaude administrationorganization-wide

I architect agentic platforms for organizations that need AI to be dependable, auditable, and actually shipped.


Work

Selected work

Built · In production
Role

Architect and lead developer. Led the team, reviewed and shipped alongside them

Next.jsTypeScriptAzure OpenAILangGraphPostgreSQLPrismaRedis

Enterprise Agentic AI Platform

A production platform that placed an organization's siloed systems behind one governed conversational surface. It carried a marketplace of versioned agents, a connector fabric grounded in the organization's own sources, a set of inline visualization tools, branded document export, a separate mesh for work a single agent could not finish, and a governance plane spanning all of it.

RuntimeStreaming orchestrator, versioned agents, parallel tool calls
MeshSeparate engine: checkpointed graphs, plan approval, resume from interrupt
GroundingRetrieval over the company's own document and record sources, with citations
ExperienceInline visualization tools, prompt library, branded document export
GovernanceRole-based access, directory-group provisioning, publish-time safety audits

Architecture schematic: two separate entry surfaces — agent chat and mesh chat — each with its own orchestration engine. The chat orchestrator handles versions, memory, and quota for single-agent turns; the mesh engine runs a LangGraph state machine with checkpoints and human-in-the-loop interrupts for multi-agent work. Both converge on a shared runtime of payload building, stream event handling, and the tool loop, then the streaming model runtime. Every tool call passes through a full-width governance gate — RBAC, tool policy, approvals, audit — before reaching MCP tools, retrieval packs, document stores, NL-to-SQL, connectors, and memory, all reporting into a telemetry rail.

Fig. 1 — Agentic platform control plane
Built · In production
Role

Sole architect and developer

ReactTypeScriptFastifyPostgreSQLundiciRedis

Enterprise MCP Gateway

A Fastify gateway that fronted internal MCP servers on the public internet. It presented an OAuth authorization-server facade over the corporate identity provider, so any compliant client onboarded from one pasted URL. Every proxied request then cleared a single ordered enforcement pipeline before an upstream saw it. Audit events fed the console. Role defaults were least-privilege.

PerimeterFastify 5 exposed directly to the internet; undici proxying to upstreams
OnboardingOne pasted URL; a 401 drives discovery and self-registration
EnforcementOne ordered pipeline every call clears before an upstream is reached
StandardsOAuth metadata self-discovery, protected-resource metadata, RFC 7591
ObservabilityAggregate team views over audit events; bodies never rendered

Request-path schematic. Along the top, discovery: an MCP client reads authorization-server metadata and protected-resource metadata, then registers itself under RFC 7591 against the corporate identity provider; a dashed line returns to the client carrying the 401 that starts the handshake. The client then makes a proxied call into the per-call pipeline, the only element marked in red, where the caller is established, eligibility is settled, and upstream targets and limits are checked before anything is forwarded. Past it sits the proxy executor, which reaches internal MCP servers and REST APIs wrapped through OpenAPI. An audit record falls out of the path into admin metrics and team metrics, the latter aggregate only.

Fig. 2 — MCP Gateway request path
Built · In production
Role

Architect and sole developer; owned the business-facing conversations

Next.jsTypeScriptAzure OpenAIAzure AI SearchPostgreSQLRedisPython

Self-Service Support Assistant

A customer-facing assistant embedded in the enterprise support experience. Sessions authenticated through the company's CRM, with retrieval scoped to the products each customer was entitled to. It answered from what it had retrieved, or said it had nothing. The customer decided whether the answer landed. Satisfied sessions ended with no case filed, and a large share of sessions ended that way.

OutcomeA large share of sessions closed without a case reaching engineers
GroundingEntitlement-scoped retrieval; answers confined to retrieved sources
AbstentionNo answer returned when retrieval came back thin
EscalationModel-drafted case, field-validated, customer-edited before submission
ScoringThree rubrics per written case: resolution notes, communication, hygiene

Flow schematic: a customer question in an entitlement-scoped session is rephrased and used to retrieve from knowledge-base articles and product documentation, producing a grounded answer that abstains when unsupported. A satisfaction checkpoint decides the outcome: satisfied ends the session with no case filed — the deflection path — while unsatisfied moves to a drafted case with validated fields, user edits, and case creation.

Fig. 3 — Deflection and escalation paths
Further work & explorations

Practice

What I do

A.

Enterprise Intelligence

Retrieval and knowledge platforms that give organizations dependable answers, grounded in trusted sources, evaluated continuously, observable end to end.

RAG / Knowledge systems / Observability

B.

Agent Ecosystems

Agent platforms that survive contact with the enterprise: explicit boundaries, approved tools, human checkpoints, and execution you can replay.

Orchestration / MCP / HITL design

C.

Product Architecture

Strategy and interfaces that make complex systems adoptable: developer platforms, design systems, and APIs people actually build on.

Strategy / Platforms / Enterprise UX

D.

Platform Infrastructure

The layer the rest depends on: gateways, identity, policy at runtime, and the telemetry that makes any of it operable.

Gateways / Identity / Observability

How I think about the stack

Read from the foundation up

Principles

Working principles

1. Start from the user’s actual job.

2. Treat permissions as part of product design.

3. Give agents explicit boundaries.

4. Make observability a platform capability.

5. Build ambitious systems through practical phases.


About

LocationHyderabad, India
FocusAgentic systems, enterprise AI
ClaudeOrganization administrator: access, usage and spend, policy, enablement
Open toArchitecture leadership, founding teams, select consulting
ElsewhereLinkedIn ↗

I’m Vamsi Krishna, an enterprise AI architect and product builder. My work runs the full path from a model call to something an organization actually trusts: AI platforms, agent systems, enterprise integration, governance, and the product surfaces that make them adoptable.

What I optimize for is governed autonomy that ships: systems with explicit boundaries, phased delivery, and interfaces people want to use. The projects I enjoy most start as ideas that feel too large or too ambiguous, and end as understandable systems.

The same instinct shows up outside work. I build small systems of my own to think through problems properly, which is slower than reading about them and teaches more. Most stay private. A few turn into something I keep using.