2X Founder | Building @scalekitinc, simplifying Auth for AI Apps | Led product at @FreshworksInc's Neo Platform | Co-founded Pipemonk (acqd by Freshworks)
San Francisco, CA
Joined May 2008
- Tweets641
- Following329
- Followers272
- Likes219
Pinned Tweet
Connecting an agent to an app is just the beginning. Here's what we've been building for the last six months 📷
AgentKit by @scalekitinc is the MCP gateway for agents that act on behalf of your customers, connecting 600+ apps and 30,000+ tools. It brings together:
→ User-delegated auth
→ Virtual MCP servers
→ Custom connectors for internal APIs
→ Event-driven triggers
→ Per-action audit logs
The infrastructure agents need to work across real applications, for real users.
We've spent six months going deeper on the infrastructure developers need after their first agent demo.
Now we'd love to see what you build with it.
Free tier: 10,000 tool calls/month. Try for free: scalekit.com
Absolute must read on how to think from first principles when and how you want to change your existing processes to accommodate agentic transformation effectively. Once again - great post by @addyosmani
Looks like our Hermes plugin has taken off a bit, and the chatter under it is mostly "why Scalekit over the others?"
Thought I'd take a moment to share how we think about this.
Getting an agent to call thousands of tools is table stakes now. Every platform in this space does it, us included.
The hard part starts after that. Your agent is acting for a real person, inside systems your customer owns.
→ Your customers' systems don't all use OAuth. Some use key pairs, service accounts, admin-level access. We handle those out of the box.
→ Every customer has that one internal API or MCP server nobody has a connector for. You can plug it in, and it gets the same auth and logging as a native connector.
→ An agent with 500 tools in context is slow and hard to trust. You give each agent a bundle of exactly the tools it needs, behind its own URL.
→ Every call is streamed and audited. And if your customer needs it to run in their own cloud, it can.
We're building for depth: the stuff that decides whether an agent makes it to production.
Happy to go deeper on any of this.
Ravi Madabhushi retweeted
Our map of 70+ companies building healthcare agents at @scalekitinc got a lot more attention than we expected.
The rabbit hole was even more interesting:
- AI spending on prior auth grew 10x last year. Patient engagement? 20x.
- Scribes are a $600M category, but they're already moving beyond taking notes to placing orders and triggering workflows.
- EHR giants are shipping their own agents, while startups are trying to build across the systems they don't control.
Our map of 70+ companies building healthcare agents at @scalekitinc got a lot more attention than we expected.
The rabbit hole was even more interesting:
- AI spending on prior auth grew 10x last year. Patient engagement? 20x.
- Scribes are a $600M category, but they're already moving beyond taking notes to placing orders and triggering workflows.
- EHR giants are shipping their own agents, while startups are trying to build across the systems they don't control.
And here's the fun part: health insurance companies are building agents too.
We're heading towards a world where a hospital's AI agent submits a prior authorization request and an insurance company's AI agent reviews it.
Healthcare's next big workflow might just be two agents arguing over whether a patient needs an MRI.
Full map here: lnkd.in/p/gCKbVsGi. Who did we miss?
Ravi Madabhushi retweeted
back in may when we did our first edition of agents & bagels, i ate the leftovers alone. fast forward to october our 16th edition, we ran out of bagels 😄
SF @Techweek_ edition of @scalekitinc's signature agents & bagels with @nebiusai @tavilyai @tenki 🥯
Ravi Madabhushi retweeted
this was @scalekitinc's 5th hackathon for the year, and i think we're getting better at figuring out how much people can actually build in less than 4 hours!
a little late, but here's a recap from our SF @Techweek_ hackathon with @cognee_ and @RespanAI!
the challenge: build a company brain that could pull context from different tools, remember things, and actually take action with the right access.
we had 8 solid submissions by the end of the evening, and some really fun demos. thanks to everyone who showed up and built with us. and to @tricalt and @HendrixLiu29208 for putting this together with us!
A customer-facing agent can work perfectly in a demo and still be nowhere near ready for production. We had a good conversation about this at our SF Tech Week session on building and deploying customer-facing agents, with @simonrohrbach, @hey_amandam, and @Homer_Wang.
A few things stuck with me.
1. Calling your agent once and seeing it work isn't testing: Amanda made this point well. You need evals around specific decisions, simulated conversations with different customer personas, and monitoring once agents are live. You can't manually call every agent every time something changes.
2. Your agent is only as good as the context it has: Simon Plain shared something interesting about knowledge freshness. Human support teams can give inconsistent answers. Documentation can go stale. The codebase often gets you closer to how the product actually behaves. And even if your knowledge is accurate today, your agent can drift as the product, models and human behaviour change. Getting the right answer is more than just retrieval. It's about knowing when your source of truth has changed.
3. Making the web accessible to agents shouldn’t come at the expense of the web itself: The web needs to be accessible to agents, but access can't come at the cost of overwhelming websites or ignoring their boundaries. There's a balance to get right.
A few good conversations with people building this stuff for real. Thanks to everyone who joined us!
🤖 Made with AI
Ravi Madabhushi retweeted
Had such a great time with @simonrohrbach , Homer Wang, and @ravibits talking about all the ways we approach getting agents to production.
Thanks to @scalekitinc , @plainsupport , and @Tiny_Fish for having me and to a truly engaged audience with challenging and interesting questions
We use LLMs for a surprising number of problems that aren't generation problems.
Been experimenting with Jev from TypeSafe for tool search and ranking. Wrote about what we tried, what worked, why I think this pattern goes beyond search reranking 👇🏽
Ravi Madabhushi retweeted
MCP sessions are gone, so where should state live when the application still needs it?
The latest MCP release removes transport-level sessions, but application state still needs a home. A new guide explores when state should become a request parameter, durable handle, or task, and what the shift means for scaling, routing, and long-running workflows.
Read the guide by Ravi Madabhushi from member company, @scalekitinc: bit.ly/4bXUxon
Folks in SF, come join us: luma.com/n5ozj6uv
Come chat about agent context, retrieval tradeoffs, and what breaks in production. Over a slice of pizza.
We're putting together a small room of engineers in SF on August 27. If you're shipping agents, wrestling with latency at the edge, or just tired of theory, this one's for you.
@ravibits, CTO at @scalekitinc and Yisui Hu, CTO at Crafting will join us to give talks.
Hosted by @ActianCorp, @theaievangelist, and @iChuloo . Limited spots. Register here 👇
luma.com/n5ozj6uv
You connect Gmail to an agent and it quietly gets all ~30 tools that server exposes. Most agents need one or two.
So it walks around holding access it never touches. Every unused tool is one more way to pick wrong, one more thing you trust on every run.
Scoped MCP servers close that gap. You define which exact tools an agent can touch, a calendar agent gets read, not write. Then a short-lived session token, scoped to one user, so credentials never enter the agent's context or your logs.
The agent only ever sees the tools its role needs, acting as the person who triggered it, not the admin who set it up.
1/
@xmcp_dev
is one of the fastest ways I've found to stand up an MCP server. Define your tools, your resources, your prompts and you're basically done. It nails the MCP layer and leaves auth open on purpose. Good call. But the day your team connects, auth becomes the whole job.
2/ On a prototype, opaque API keys in a config file are fine. Once a team connects, anyone with that file has the keys.
So I'm glad this shipped: xmcp +@scalekitinc
It's now a native OAuth 2.1 integration. Official plugin and starter template, built by the people who own each side.
3/ The design is clean. A client connects, signs in, and the token comes back locked to your server. No raw token in your config. Shoutout to
@0xKoller and @Saif_Shines🙌
Start here:
$ npx create-xmcp-app@latest my-mcp-app --example
4/ Get started - scalekit.com/blog/xmcp-scale…
Read more - xmcp.dev/docs/guides/roll-ou…