Launching today
Weavable
Give every AI agent persistent work context
230 followers
Give every AI agent persistent work context
230 followers
Weavable gives AI agents persistent, live work context from the tools your business already runs on. Through a single MCP endpoint, it turns scattered updates, relationships, and system changes into a usable context layer so agents can reason more accurately without constantly re-ingesting data. The result is lower token usage, better outputs, and more reliable agent behavior across real business workflows.
Hey Product Hunt 👋 I'm Abesh, co-founder of That Works, and today we are launching Weavable.
The Problem
Teams building agentic workflows are sitting on a goldmine of work context: decisions, relationships, pipeline data and support history that is spread across every tool they use. Getting that context into agents reliably is still harder than it should be.
Most approaches follow one of two flawed paths:
❌ Direct app connections - raw API and MCP responses flood the model, token costs balloon, and the agent burns its context window figuring out what matters instead of acting on it.
❌ Static knowledge bases or RAG - context goes stale the moment it's captured. Agents work from the last snapshot and confidently get things wrong.
So we built Weavable.
The difference is measurable: one-tenth the tokens compared to direct app connections, with outputs preferred 85% of the time in LLM-as-a-judge evals.
How Weavable is Different 🔌
Weavable is context infrastructure for AI agents. Instead of dumping raw data at the model or freezing a snapshot, Weavable maintains a continuous updating changelog across your actual work tools, so the knowledge graph your agents reason from is always mapped, reconciled, and up to date.
🔷 Connect your tools: one OAuth flow covers HubSpot, Slack, Zendesk, Jira, GitHub, email. Scoped access, no broad permissions.
🔷 Define shared contexts: customer health might live across your HubSpot pipeline, Zendesk queue, and a Slack channel. Weavable pulls that together into a single context your whole team's agents reason from. No per-agent app connections, no duplicated permissions, no visibility gaps.
🔷 Plug it in: one MCP endpoint into Claude, Cursor, n8n, or any client you're running. Live in a few minutes.
Who is this for?
If you're building or operating agentic workflows on top of real work data, and you're tired of silent failures, token blowout, and context that's always slightly wrong - Weavable is built for you.
🚀 Get started today
Start free for 30 days, full access, no card required at weavable.ai
— Abesh & Varun
Nice! I especially like the activity graph/changelog approach because it treats context as something dynamic.
Curious: how do you actually reduce token usage by 90%?
@grantmac_ Thanks! Indeed, nothing about data is every static!
On the tokens: pulling raw data into the context window costs you twice. Once on ingestion, then again on reasoning, while the LLM connects records, sorts by recency, and figures out what matters. Weavable's graph already knows the relationships and what changed when. The agent queries for the specific signals it needs, and the model only reasons over those.
The 90% is what we see on realistic workflows like pre-meeting briefs, renewal analysis, pipeline summaries, compared to the same thing built on raw MCP calls.
@varunn very cool guys!
@grantmac_ thank you for taking a look, and for the encouragement!
This is a really interesting point of view here. The activity-graph approach makes sense — context should reflect what's happening, not just what was recorded.
One question from our experience building Faindo: we connect to multiple AI models (ChatGPT, Perplexity, Gemini) and one challenge we keep hitting is that each model interprets the same context differently depending on how it was trained. Does Weavable normalize context before it hits the MCP endpoint, or does it stay model-agnostic and let the agent handle interpretation?
Congrats on the launch, following the progress closely.
@nerijusrimdzius Thanks, and a great question!
Weavable structures context before it hits the MCP endpoint. We rank it, denoise it, and resolve the connections that carry the most signal, so the downstream model gets a high-quality, ready-to-reason-over view rather than raw records to make sense of.
One thing we've noticed: because of how we construct the context, models in the same class tend to reason about it in similar ways. The structure is unambiguous enough that interpretation converges. Different classes of model still unlock different capabilities on top of that, but the floor moves up everywhere, and the variance within a class drops noticeably.
Curious where you've seen the biggest gaps across the three you're running at Faindo. That's exactly the kind of cross-model signal we want to be informed by.
@nerijusrimdzius Thanks for sharing your build journey here. Since you brought up such an interesting (and real) issue with multiple models interpreting context differently, how have you been handling it so far at your end? Any good results/hacks that you swear by?
DayOne
Yes! I've been trying to solve this problem for months with various (often questionable) hacks. Love it.
One thing I’ve been thinking about a lot with agentic systems is context governance.
Most team have hugely different sensitivity levels across data, customer conversations, board discussions, HR issues, commercial terms, etc. How does Weavable handle permissions and context boundaries so agents only reason from the information that specific users or teams should actually be able to see?
@iamtherealcmk Thanks Conor! Context governance is the right question to be asking as more sensitive work moves through agentic systems.
Two layers to how we handle it.
First, all connections to source apps are OAuth and read-only, tightly scoped. Weavable only sees what your OAuth scope permits.
Second, agents don't connect to your data sources directly. They connect to contexts you've defined in Weavable: curated views with explicit data scopes. This set of HubSpot pipelines, those Slack channels, this Notion space, scoped to the user or team that should see it. Board discussions, HR, commercial terms each live in their own context with their own access rules. The governance boundary sits at the context layer, where you can model the actual sensitivity structure of your team, not at the data source where it's brittle and easy to overshare.
Every query against a context is logged too: which agent, which user, which signals were retrieved. So you get an audit trail that matches the governance model.
What's the shape of the hacks you've been running? 😅
@iamtherealcmk to add to this - you are absolutely thinking about the right things. There are some pretty good strides being made to tackle governance overall, but not at the pace at which it needs to keep up - and it's not a matter of just shipping more dashboards.
If you do have any working "hacks" that you are happy with - do share!
This is very cool guys, congratulations. How does Weavable do in terms of speed at a practical level compared to connecting say claude code into all the individual data sources?
We've found connecting to the data sources directly is slow as well as being token heavy, claude has to pull some data, build a context, then pull more data, from that figure out what else it needs, it goes on for a while, especially if some are through MCP, does this help with that as well?
@seyed_danesh Thanks Seyed! Yes, this is one of the (many) things that Weavable is designed to fix.
You're describing the iterative-retrieval loop: pull, reason, pull more, reason again. Each round trip costs latency and tokens, and with direct MCPs across multiple sources it compounds fast.
Weavable does that work upstream and continuously. By the time the agent queries, the connections are resolved, the signals are ranked, and the change history is already in the graph. The agent typically gets what it needs in one query against a context, not four against four data sources. Fewer round trips, lower latency, and roughly a tenth of the tokens.
In our testing we've not only found the responses to be of better quality but also found that the downstream model/agent becomes better at adhering to instructions too!
Congrats on the launch. The activity graph / changelog framing is strong.
How do you decide which context should become a reusable workflow signal versus just being retrieved for one agent query?
@fabian_exner Thanks Fabian! That decision sits with you, not us. A context in Weavable is something you define and curate, so you decide whether a slice of your work data is worth standing up as a reusable view or just queried against a broader context.
In practice, two patterns: workflow-shaped (recurring jobs like renewal analysis or pipeline review, where the same signals get queried on a cadence) and exploratory (you query a broader context, find what matters, then decide if it's worth crystallizing into its own).
Because the graph underneath is always live, contexts are easy to create, modify, and clone as you learn what the agent actually needs.
@fabian_exner Thanks for the support!
Persistent context across agents is the exact problem most multi-agent systems hit. Workspace isolation makes context sharing safer — without it, cross-tenant leakage is a real risk. How are you handling tenant boundaries?
@pengspirit666 Excellent question, and something we see quite often when working with larger companies.
The control itself is defined when you curate a context. That's where you set which data scopes are in, which are out, and who the context is available to. Cross-tenant boundaries can be enforced both there and at the OAuth layer, depending on which connections each side of the boundary should be able to reach. Additionally, every query against a context is logged too: which agent, which user, which signals were retrieved so the entire flow becomes auditable.
@pengspirit666 thanks for the great question and support!