seekgb.com · LinkedIn · mcpindex.ai · ORCID
Product Manager blending strategy with execution · Developer Platforms · Public APIs · Agentic AI & MCP
Developer platforms and the trust layer under agentic AI. The thesis in one line: a tool's contract can change after you approved it — no version bump, no republish event, nothing the consumer sees — so verification has to be continuous, not a one-time review at onboarding.
contract.pinned_at = approval_time // the snapshot, not the docs
served.contract ≠ pinned.contract // drift, with no republish event
verification = continuous // advisory evidence, not a gate
I measure this at registry scale and publish the data openly. 3,500+ MCP servers observed daily; four datasets on Zenodo under CC-BY.
| Work | Status | Scope |
|---|---|---|
| OWASP GenAI Data Security Best Practices v2 |  |
Authored Ch9 Pattern 8, "Tool-Contract Capture & Drift Verification"; amended the P7 Tier 1 contract-capture control |
| OWASP FIASSE |  |
Dependency stewardship for agentic dependencies — contracts that change with no version bump (Discussion #20) |
| MITRE ATLAS |  |
Mitigation submitted for AML.T0104 (Publish Poisoned AI Agent Tool), covering post-approval contract mutation |
| OWASP AISVS C9 | |
Real-data conformance fixtures for action-class and reversibility controls (reference repo) |
| Adversarial ML for IoMT Security |  |
Elsevier, Internet of Multimedia Things Security — third author (DOI) |
All published under Bharti, Gautam (ORCID 0009-0001-4448-1438), CC-BY-4.0. DOIs below are concept DOIs — they always resolve to the latest version.
| Record | Type | DOI |
|---|---|---|
| mcpindex Drift Report — Edition v1 (contract-drift corpus) | Dataset | 10.5281/zenodo.21449149 |
| mcpindex Source Liveness — Baseline v1 (reachability census) | Dataset | 10.5281/zenodo.21501867 |
| MCP Registry Drift Panel v1 (longitudinal observation panel) | Dataset | 10.5281/zenodo.21709945 |
| MCP Declared-Effect Coverage and Contract Binding v1 | Dataset | 10.5281/zenodo.21778281 |
| Registry Descriptions Go Stale Unevenly: An 89-Day Measurement | Preprint | arXiv:2608.00997 · 10.5281/zenodo.21728369 |
Every tool here started as a proof-of-concept to solve friction I hit while shipping enterprise AI infrastructure. I prototype before I spec.
|
The agent-native index of MCP servers. Recommendation API + drop-in MCP server ( |
Enterprise-grade agent builder factory. A composable framework for building governed AI agents with structured tool access, memory, and orchestration patterns. Paste an OpenAPI spec, get a production-ready MCP server. Built to eliminate the boilerplate that slows agentic adoption — the same friction I kept hitting when onboarding teams to MCP at scale. |
|
Classifies user queries by complexity and routes them to the right LLM — fast model for simple questions, heavy model for complex reasoning. Cuts inference costs without sacrificing quality. Exposes latency, model, and cost telemetry per request. A privacy-preserving proxy between your application and your LLM. A fast model replaces PII with placeholders, the heavy model processes only clean text, and the response is unmasked before returning. Enterprise compliance without crippling AI capability. |
Extracts structured behavioral personas from writing samples — communication style, decision-making patterns, values, expertise markers, and 15 behavioral dimensions. Feed it emails, docs, or feedback; get a portable PERSONA.md that evolves over time. The cognitive fingerprint that demographics miss. Agentic workflows cost 10-50x more than the pricing page implies. Models what no other tool does: context accumulation across multi-step agent loops, tool call overhead, orchestration pattern multipliers, and prompt caching savings. |
All deployed and live at seekgb.com
- Start with the problem, not the technology. Every tool I've built exists because I hit a real friction point — not because the tech was interesting. If nobody needs it, it's shelfware.
- Prototype before you spec. I build working POCs to pressure-test ideas before committing engineering resources. The best specs come from building, not theorizing.
- Stay close to the users. I run discovery calls, read support tickets, and use my own products. You can't build for developers if you've never felt their friction firsthand.
- Ship small, learn fast, iterate faster. I'd rather validate with a rough working version this week than debate a polished spec for a month. Assumptions are cheap to hold and expensive to ship.
I've spent 12+ years building platforms at Microsoft (Power BI/Synapse, Windows Shell), T-Mobile, Trend Micro, and Qualtrics. The recurring problem: powerful infrastructure exists, but the people who need it can't reach it. These tools are my way of closing that gap — building the missing pieces I couldn't find when I needed them.
📍 Seattle, WA · ⏱ GMT-07:00