Launched this week
Weavz.io
Let AI agents safely act in 1,000+ customer apps
66 followers
Let AI agents safely act in 1,000+ customer apps
66 followers
Let your AI agents safely act in the apps your customers already use, like Slack, Gmail, CRMs, and billing. Give an agent a Weavz MCP in Claude, ChatGPT, or Cursor, or a CLI workspace in your own runtime. It reaches 1,000+ integrations and 12,000+ agent tools through Code Mode's 3 calls, with Human Gates, scoped credentials, state, files, and audit. Embedding it yourself? Provision workspaces, connect users, and mint scoped tokens via the API and TypeScript/Python SDKs.
Hey Product Hunt. I am Ahmad, founder of Weavz.
The demo version of an AI agent is easy. The version that touches a customer's real tools is where it gets hard.
The moment an agent has to use Slack, Gmail, a CRM, billing, or an internal API, you inherit the messy part. Who owns the credential. What the agent is allowed to change. Which action needs a human first. What receipt survives after it acts. That is product work, not a prompt.
Weavz is that layer. Let your agents safely act in the apps your customers already use, inside Claude, ChatGPT, or Cursor, or wired into your own agent.
- 1,000+ integrations and 12,000+ agent tools, scoped per workspace and end user
- Code Mode: the agent searches, reads only the API it needs, then executes. No 12,000-tool context dump.
- Human Gates pause sensitive actions until someone approves
- State, files, sandbox, and an audit trail per run
- Agents reach it over MCP or the CLI. Builders embed with the REST API and TypeScript/Python SDKs
Fastest way to see it:
1. Add the connector at platform.weavz.io/mcp/weavz to Claude or ChatGPT
2. Sign in and get a starter workspace
3. Ask the agent what is available, then have it do real work across an app
I would genuinely like your feedback more than your upvote:
- Where do your agents hit app-access pain today
- Which actions should never run without a human approval
- MCP, your own API, or both in your stack
I am here all day. Ask me anything technical.
Huge congrats for launching @blah_mad👏 addressing the absolute mess of managing client OAuth states for multi-app agents, qq Is there a hard stop button in the UI to instantly kill a running agent workspace?
@priya_kushwaha1 Great question. There isn’t a single workspace-wide kill switch, yet.
Today Weavz controls the blast radius at the action layer: workspace-scoped access, enabled actions per app, Human Gates that can be rejected/canceled, and cutting off connections/API access so future tool calls stop.
If the agent runs in your own runtime, killing that process stays there. Weavz governs what it can do inside customer apps.
As someone building AI agents that need to touch user data across multiple SaaS tools, the OAuth scope management is always the scariest part. How does Weavz handle token refresh when an agent runs long-running workflows? And is there a way to audit exactly which actions an agent took across all connected apps?
@jimmy_benhsu the agent never holds the OAuth token. It calls a scoped action and Weavz resolves + refreshes the credential server-side at execution time, so tokens refresh per action, not at run start. That is why a run can pause at a Human Gate and resume hours later without breaking. On audit: every action is logged with the workspace, the end user it acted as, the action, result, approval, and timestamp, so you get a full per-run trail across every connected app. Happy to dig into revoked-token / re-consent edge cases.
@blah_mad Great breakdown — the per-action refresh model makes a lot of sense for long-running workflows.
On the revoked-token / re-consent edge cases you mentioned: if an end user revokes the OAuth grant while a run is paused at a Human Gate, does the run fail immediately on resume, or does it surface a re-consent prompt back to the user inside the gate UI?
And for multi-workplace scenarios — can an admin force-revoke all active tokens for a connected app, and if so, how do paused runs behave when they try to resume?
@jimmy_benhsu good edge cases, and this is where the per-action model actually pays off.
Revoke while paused: because the credential is resolved at execution, not pinned when the run started, a revoked grant gets caught the moment the run resumes and tries the action. It fails closed instead of acting on a dead token. The connection surfaces a "needs reauthorization" state, the end user reconnects through the hosted connect flow, and once they do the action can be retried and the run continues from where it paused. Today that re-consent is a reconnect link rather than a prompt rendered inline in the gate UI. The inline version is on the list.
Admin force-revoke across a workspace: yes, an admin can revoke a connection or all credentials for a connected app, and the same mechanic keeps it clean. Since nothing caches a token between actions, the revoke takes effect immediately for everything, including paused runs. When those resume they re-resolve, find no valid credential, and fail closed rather than execute. No "it kept running on a token I thought I killed" surprises.
@blah_mad "Fail closed" is exactly the right mental model — especially the "no cached token between actions" part. That eliminates a whole class of security surprises most teams don't think about until it's too late. Appreciate the detailed breakdown.
The "who owns the credential" question is one of those things that sounds boring until you actually try to ship. I spent way too long on auth flows for MotionFy because every external API had a different opinion on what "scoped access" means.
Human Gates is the part most teams skip and then learn the hard way. The audit trail per run is the real differentiator though without that, you can't debug what the agent actually did, you can only debug what you think it did.
@elias_motionfy This is the right read, and the MotionFy auth pain is painfully familiar. Every provider has its own idea of scopes, refresh, and what a connection even is, and you only feel how bad it is once you're doing it per customer.
Strong agree on the audit trail. Your line nails it, without it you're debugging what you think the agent did, not what it actually did. We log every action with the workspace, the end user it acted as, the inputs, the result, and the approval if it passed a gate, so a run is reconstructable instead of a black box.
And Human Gates is the one everyone skips until an agent does something irreversible in prod exactly once. Cheaper to learn it from a comment than an incident.
Appreciate the thoughtful take. Curious what you ended up doing for auth on MotionFy.
@blah_mad For MotionFy auth I ended up biting the bullet, built a thin wrapper layer that normalizes scopes/refresh/connection state into our own model, then mapped each provider into it. Hated doing it because it felt like reinventing what Weavz now sells, but at the time there was no clean off-the-shelf option that handled per-customer credentials at the scope I needed.
Honestly if you'd existed 6 months ago I'd probably have skipped half the work. The "reconstructable run" framing is exactly the language I needed when explaining to early users why audit logging matters more than logs. Stealing that.
@elias_motionfy haah, that wrapper layer is exactly the thing I want nobody to have to build again. And honestly, normalizing scopes, refresh, and connection state into your own model is the right call when there's nothing off the shelf. The fact that everyone independently lands on the same shape is the whole argument for this being infrastructure, not a per-project chore.
Please steal "reconstructable run," it's yours. The split between what the agent actually did and your logs of what you think it did is the thing I wish more people led with.
And the six-months-ago line genuinely means a lot. If you ever get the itch to rip out that wrapper and see how much you can delete, I'd love to help you try it, mostly because I want to know where it doesn't hold up against something you already built the hard way. No pitch.
@blah_mad Honest answer: the wrapper works fine because I only have 4-5 providers right now. The pain isn't visible yet. If I had to scale to 20+ I'd be re-evaluating in a heartbeat, the per-provider quirks compound non-linearly and that's where I'd hit the wall.
Genuinely appreciate the offer. Right now my bandwidth is locked into PH launch prep, but I'll keep that ripcord in my back pocket. The "no pitch" line is what makes me actually want to talk later.
@elias_motionfy Same pain here — I ended up building a similar normalization layer for our agents and the "different provider, different scope vocabulary" problem is absolutely the worst part. Out of curiosity, did you end up normalizing refresh behavior too (e.g., some providers send a new refresh_token on every access_token refresh, others don't), or did you just treat each provider's token lifecycle as opaque and handle it per-connector?
@elias_motionfy @jimmy_benhsu jumping in since this is squarely the thing we obsessed over, though I'd be curious to hear Elias's take too.
Refresh rotation is exactly the trap. Treating each provider's lifecycle as opaque per-connector is fine until one rotates the refresh_token on every refresh, you persist the old one, and the connection silently dies a few hours later.
We don't treat it as opaque. On refresh, if the provider returns a new refresh_token we persist it atomically and drop the old one, so the next refresh always uses the current token. Whether a provider rotates is part of its config, not something each connector reinvents. Same for the other landmines: refresh tokens with their own expiry, providers that only hand you a refresh_token on first consent, and the ones that invalidate the old access token mid-rotation.
That whole matrix is exactly the boring stuff we wanted to own once so nobody special-cases it per connector again.
What got you most, the rotation itself or the providers that don't even tell you they rotate until you hit it in prod?
@elias_motionfy @blah_mad The silent rotation in prod is definitely worse — at least if you know a provider rotates, you can plan for it. The ones that don't document it and you only find out when your integration tests pass but production connections start dropping 6 hours later... that's the nightmare.
@blah_mad Separate question on the race condition: when two actions close together both need a refresh and the provider invalidates the old access token on rotation, does Weavz deduplicate refresh requests server-side, or does the second action retry with the newly persisted token?
@jimmy_benhsu Honestly leaning toward the per-connector side, treat each provider's lifecycle as mostly opaque and only normalize the parts I have to (scopes, expiry windows, error states). Refresh behavior I handle inside the connector because the differences are so weird per provider.
Ahmad's point about silent rotation is exactly where my approach would break though. Haven't been bitten yet but it's only a matter of time.
@blah_mad This is really smart approach to AI integrations. Love how you’re focusing on secure access instead of just adding more connectors.
@dipanshu_kushwaha5 that’s exactly the bet. Agents don’t need bigger connector lists as much as they need scoped credentials, approvals, state, files, and audit around the action. That’s what we’re trying to make boring and reliable with Weavz, so teams building agents, copilots, and internal tools can safely connect them to real customer/business apps.