@tferriss@kevinrose I see MCP integrations as complementary to UIs.
MCP integrations for visual applications like video editors are much better if you can take over, make some tweaks yourself, then keep collaborating with the AI.
Yep, it's OSS, but not nicely packaged up a a generic spec+verification environment. Rather, it is pretty tied into the Meadow project I'm using the environment to develop.
The code's here:
https://t.co/qHwJmL5TY4
One specific peculiarity of the Meadow project is that it uses files for state, not a DB. I suspect that probably made the time travel a little easier to implement, but i'm sure you could do something similar with small database dumps, or some kind of checkpointing/copy-on-write (not sure what the various database engines one might want to use would offer)
I'd love a pointer to your project if it's open source so I could take a look at your approach.
Simple prompt to actually see the environment in action:
"""
Clone https://t.co/qHwJmL5TY4 into a temporary directory, then run the quickcheck (installing required dependencies) then use its E2E agent skill to run the full E2E suite (resolve any problems that come up).
Once you have a run that fully passes, open the end to end report in the browser.
"""
Thanks for the enthusiasm! :)
I've got a video from 4 months ago that shows off what it did back then.
It shows the time-traveling within scenarios, but doesn't show the connection to specs or the "fork dev tooling" since that didn't exist back then.
https://t.co/11DAJUzdrK
I'll make another video with all the new stuff soon.
I really appreciate a couple things about @NotionHQ's recent pivot to being the "Github of context":
* it's necessary. We need third-party context hosting that's not lab-aligned
* they recognize that embedded agents are not the way and are positioning themselves as a context runtime, instead
The challenge I see is that they are only partially embracing the "context is just code" ethos. The "Github of context" should really be something very similar to git and Github, but with a better UI to allow non-technical users to directly collaborate with engineers and agents who are modifying the context at scale.
A full embrace of the "context is just code" idea skips monolithic large documents and instead uses a graph of smaller, well-factored docs (similar to a well-factored codebase). Instead of a meeting causing updates to one note, the changes would be right-homed into a variety of appropriate docs (and, separately, various actions could be kicked off because of those changes, but that's a secondary layer). So instead of being a single doc, the "meeting notes" instead becomes a reified transaction. A commit of the changes, basically.
This should sound like business as usual to any experienced software engineer. The reason software engineering has been able to embrace agents so effectively is that the field already had world-class tooling for change management. It had a history of large groups of people who have worked together on the same artifacts effectively. Revision control, and specifically git, was the key enabler.
It's not surprising Notion has decided to use Github in this way for their skills sharing. After all, skills seem more like code than other context, especially because they can have associated code. But I view skills as just one subtype of context, and honestly not too meaningfully different from other types. Skills can provide your agent with context and tell it what to do. But other things (a context graph) can supply your agent with context, too. With formats like OKF (or by carefully doing it yourself... it's just YAML frontmatter and markdown) you can even do progressive disclosure.
I look forward to other companies deciding to specifically target being hosted context, and to see what ideas they bring to the mix. I also see a big opportunity for Github itself to be the next "Github for context" by providing in-browser affordances that let people easily collaborate on context.
I'm excited to see what happens.
@mikeg0 Yeah, vibe coded apps really have a cost.
Easy to create. But when anything's possible, you feel like any/all rough edges need to be filed down. Hard to stay on the right side of 80/20.
Great to view as experiments, then it's not so bad. Some work, some fail. No problems!
For years, maybe a decade, I've wanted to build a writing tool that just did a few things I couldn't find anywhere else.
A system that mimicked how I think when I write. A system that provided clear affordances, features, and places to do the things I wanted to do. A way to play with my writing as I'm writing it. A way to settle into just the right way to say something.
It never made sense to make it a 37signals product because it's not commercially viable, nor would it be worth pulling people off their other work to hack on this. Plus, it would have taken months the old way.
So this weekend I just made it myself, with Claude's help.
It's called Write_On and the short video walks you through it.
Essentially it's "alternative control" at the word, sentence, and paragraph level, plus a way to dim stuff back, and stash stuff near by. Not version control, but alternative control. You'll see what I mean when you watch the video below.
So here it is. Write_On.
Nice!
I just asked the embedded agent: "Can you pull in https://t.co/pN6T71wGy3 as a discover repo?"
In the transcript it looked like it worked, but didn't show up in the "Discover listing" in the file-tree projection.
"Can you refresh the file-tree projection?"
No love.
"Can you restart the host?"
That did the trick, but mucked around with my agent session a little bit.
I know the host's alpha, so I'm just giving a little play-by-play. I really love the direct agent integration and so many of your design choices. You guys are building something special here!
@arscontexta@arsumbrisai Sounds good. Yeah, I didn't pay much attention to where it put it, but I'll make sure it goes to the right place. I suspect that guidance could be encoded into the au-mcp stuff (which I'm sure you're doing as part of the updates)
> but in the end its all just typed views on your substrate.
Yep, makes sense. Yeah, with the built-in agent it's very easy to add custom projections, which is great because they have a lot of flexibility. It took my agent about two minutes to create a "just list the pages" projection.
No specific use case I'm chasing quite yet, just want to make sure I understand how things should fit together.
Unfortunately this sounds right.
Sure, some people will buy linux boxes and put them on a shelf in their house. But those people are an ideologically motivated minority.
I understand them, because I am one of them, but I'm under no illusions that they represent anything but a small fraction of people on the Internet.
two weeks ago most people would've called you crazy for handing Meta more data. Me included. Now Muse is #1 on the App Store and the setup flow is like "cool, can I have your inbox, calendar, location, and bank?" And people are just... saying yes. Ad gold.
Lesson? workflows beat trust. Make the value obvious and immediate and people will hand over whatever unlocks it.
Privacy is a preference. Getting your Tuesday back is a need.
I really appreciate a couple things about @NotionHQ's recent pivot to being the "Github of context":
* it's necessary. We need third-party context hosting that's not lab-aligned
* they recognize that embedded agents are not the way and are positioning themselves as a context runtime, instead
The challenge I see is that they are only partially embracing the "context is just code" ethos. The "Github of context" should really be something very similar to git and Github, but with a better UI to allow non-technical users to directly collaborate with engineers and agents who are modifying the context at scale.
A full embrace of the "context is just code" idea skips monolithic large documents and instead uses a graph of smaller, well-factored docs (similar to a well-factored codebase). Instead of a meeting causing updates to one note, the changes would be right-homed into a variety of appropriate docs (and, separately, various actions could be kicked off because of those changes, but that's a secondary layer). So instead of being a single doc, the "meeting notes" instead becomes a reified transaction. A commit of the changes, basically.
This should sound like business as usual to any experienced software engineer. The reason software engineering has been able to embrace agents so effectively is that the field already had world-class tooling for change management. It had a history of large groups of people who have worked together on the same artifacts effectively. Revision control, and specifically git, was the key enabler.
It's not surprising Notion has decided to use Github in this way for their skills sharing. After all, skills seem more like code than other context, especially because they can have associated code. But I view skills as just one subtype of context, and honestly not too meaningfully different from other types. Skills can provide your agent with context and tell it what to do. But other things (a context graph) can supply your agent with context, too. With formats like OKF (or by carefully doing it yourself... it's just YAML frontmatter and markdown) you can even do progressive disclosure.
I look forward to other companies deciding to specifically target being hosted context, and to see what ideas they bring to the mix. I also see a big opportunity for Github itself to be the next "Github for context" by providing in-browser affordances that let people easily collaborate on context.
I'm excited to see what happens.
@noelsequeira Nice! Also check out https://t.co/WDSHoNYHVv where they talk about @inkandswitch's malleable software "Patchwork" project where the app's functionality is shared as well as the content. Raises some interesting collaborate challenges!
Outstanding new work on a composable and collaborative malleable computing environment from @inkandswitch https://t.co/alITDw7JV1
* Same data, collaboratively edited in different tools!
* Same tools, themselves collaboratively edited!
* Same data, bidirectionally editable in different representations via lenses! (!!!)
* All in a composable hierarchy which itself can be molded!
* Demos of a hierarchical composable behavior system that I don't yet understand!
* Some very wild demos of UI composition that I definitely don't understand!
* All versioned, branchable, local-first, import/exportable, offline syncable, etc
Watching this feels like watching a lot of dreams (Smalltalk, Webstratesโฆ) playing out live. Just beautiful stuff.
knowledge bases should be atomic and composable repos
[[wikilink::cross-repo]] lets you reference notes where they live
so you can compose small, focused knowledge bases into larger systems (e.g. your company brain)
Super interesting ideas, Heinrich!
We've been working on https://t.co/NKzz0uifi2 which does automatic constrained graph traversal as part of sourcing, then hands off to the user to curate and share.
What you call repos, I've been calling "context modules", I think. Your name is more punchy, but also makes me think you're talking about git repos.
I have found that a single source root can have many context modules under it, and when you create a context bundle, it can often pull from many of those context modules (like I show in the image below).
This has actually changed how I structure things. Often I will start with things being unstructured (everything does into a misc folder), then only once a cohesive topic area becomes apparent will I start moving things into a context module, increasing the structure a bit). Once that's done, I try to treat those modules like the "deep modules" from coding (described in "A Philosophy of Software Design"). Basically, trying to think carefully about limiting direct module-to-module linking. However there are _some_ pieces of context that are clearly general ideas that can be broadly shared. They go into a "general" context module. They can only link themselves and be linked to, but cannot link to other context modules. This allows them to be easily recontextualized and shared in context bundles.
Anyhow, I like your idea of having explicit names for the "repos" and using them in the links. Meadow supports all the preexisting flavors of markdown linking, but this feels like an interesting addition.
Cool stuff, man! Looking forward to digging into your approach to typing as well.
At https://t.co/NKzz0uifi2 we're working on addressing the sharing gap to help make local markdown even more compelling.
Modern context is more like a wiki: smaller pages. More densely linked. Not large monolithic documents.
This poses some real challenges, but with careful sourcing, curation, and excellent review tooling, you can share very useful bundles with confidence.