Someone please explain what’s awesome about MCP Apps - it feels like 2026 iFrame. What’s the point of generating the artifact if Claude can no longer interact with or manipulate the results? Consider:
1. I ask Claude to make a Figjam, awesome
2. Figjam needs tweaking
3. I either go into Figjam and lose Claude’s intelligence, or
4. I tell Claude to make another Figjam, and now I’m creating file hell
Rinse and repeat for Amplitude charts, and other tools with dynamic assets. I mean I can see some value with just retrieving context for viewing like Box, but aren’t we just in Glean territory then? Why render that as HTML and risk data corruption or rendering problems?
MCP Apps seem like a solution looking for a problem - the whole point of MCP is to have the actual data and actions at your agent’s fingertips so it can create (and iterate on) the asset better than downstream tools ever could
@ryancarson So if the machine writes your code, and your specs, and your tests - whis actually the creator?
Might as well use Lovable if you’re going to reduce your contribution to a prompt
One more thought for tonight: I’m coming to the realization that we are on the cusp of collapsing all of the “work about the work”. Sprint planning rituals, slide deck roadmaps, weeks of scoping/estimation, etc just feel crushingly slow/inefficient because of LLMs.
The future of building is simply a clear plan - everything else is work that agents can do better than humans can.
Jan 24 update:
Turns out that a simple Google Drive read permission could steal my whole day prepping for CASA Tier 2. Learned how to implement SQL-Cipher, hardened a bunch of security things and already passed my scan and self assessment. Gemini 3 Flash was the star today
Yes, Zapier has the connectors but that’s just one part of the story.
Problem 1: Zapier is built for APIs - JIT fetch of information with no graph, no history.
Problem 2: Zapier is built for the org, not user - bot tokens galore - so it’s really expensive and complicated to build a personalized graph RAG in the cloud (lots of RBAC/sync issues)
Problem 3: Cloud latency. Even if they did all that, context retrieval would be dog slow (multiple seconds) and grind agent workflows to a halt (not to mention a security nightmare).
Problem 4 (biggest one of all): incentive. Agents kill all of the automation logic of a good IaaS like Zapier. If they build this, all of the work they have done to expose no-code actions to the user are useless. But what if they just build an agent platform to replace? Okay, but between the context graph and agent building you’re basically creating a brand new company that doesn’t leverage Zapier’s existing strengths at all
Realization: the “AI copilot” era (2022-2025) was built for 80/20 human involvement, because early models just weren’t good enough to handle the bulk of the work.
2026 is the “Human Supervisor”era - the best builders are steering 80/20 agent first work and getting 4x return
Building a local context engine with Rust was cool. Then I realized: don’t be a dum ingestion pipe, make a graph. But then: graphs are dumb if they don’t have relevance. So I did that too. With Claude Code on my phone. While eating ramen with my wife https://t.co/DFtl7XcGqv
Jan 20 update:
-it’s alive! https://t.co/t7MQSSbupH or brew install getminna/tap/minna-core
-spent a ton of time today on tweaking TUI and dreaming up a better way to do graph-based priority for delta syncs. I call it gravity well and of course it uses context in the algo
jan 19 update:
-realized that i'm overindexing on end user apps. if i'm going to build and validate this idea in public as OSS, the best place to start is a CLI
-refactoring my OSS project today and getting ready to unveil tomorrow for many smart people to critique (i hope)
Someone needs to build a company around Customer Context Graph.
Collect all the threads – emails, meeting transcripts, slack messages, contracts, deliverables, detail, info, and config – from your customers into context that can be explored and queried by agents.
This info is scattered between CRMs, ticketing systems, note takers, product, landing pages – it's inherently cross platform information. You need a new solution. Kind of how Segment did it trad SaaS apps.
With this context, you can fire up Claude Cowork or similar for ad-hoc work or build extremely powerful agent automation flows. Expose the context as skills, MCP, and file system.
Even better if you build it as open-source with a hosted option so people can take it on-prem as needed. Create a connector ecosystem around it. This will power every single next-gen AI-native full-stack business.
Sort of like the context graph (@ashugarg@JayaGup10 ) that has been discussed recently but I'm thinking something very concrete: "Get me all the context about this particular customer."
A customer-level, cross-system context substrate that agents can explore and act on
Jan 18 update:
-learned way too much about public oauth apps and CASA and public declarations of privacy
-redesigned FTUX to deliver value in 5 mins or less
-cleaned 8ish GB of legacy code (man the early stuff was bad)
-burned through every AG model for the week (god bless CC)
jan 16 update:
-made a claude skill to generate "source" cover art with nano banana pro following my brand guidelines
-planned out how to make an integrations factory to cover the top 50 sources that matter
-finally got my rust backend and swift UI to be friends
all of it to solve one major question:
why do my AI agents have amnesia?
every new conversation is a reboot and "JIT RAG" by uploading files directly or through integrations are spotty
there should be a super fast, super simple way to suck in all the data from your work apps
Since Christmas:
-Generated 50k lines of code and dove deep into Rust, Swift, Typescript
-Create a MacOS app, Vercel auth bridge, Typescript/React marketing page, and in progress on an integrations catalog and iOS app
-Wrote 103 docs with about 10 versions each