I have a suspicion most of these types of agent-targeted SaaS will die out once the human equivalents implement their agent layers / MCPs.

Agents having no way to pay for their use is one thing; lack of deep integration within the business domain is another (e.g. if you're a Git provider, you'd probably want to offer CI/CD, PR workflows, release management, publicly discoverable repos etc., and boom - you just copied GitHub)

We're actually meant to be less of a consumer product than i think you mean by this (but i may have misunderstood).

We're more targeting enterprise as storage infrastructure provider – selling directly to platforms who generate a bunch of code and need a place to put it.

end users wont really know we exist.

There's probably still going to be a box of hard drives in a datacenter somewhere, it does make sense to have a layer to manage the agent interface, rather than letting agents completely loose on all your storage.

Agreed, but I'm making a distinction between the platform (whether it be Cloudflare Moltworker or a Mac Mini), which a human chooses for the agent to run on (for now), and tools designed to be discovered and consumed by the agents themselves (e.g. code.storage, AgentMail).

As the psychiatrist Iain McGilchrist says, "Attention is a moral act: it creates, brings aspects of things into being"

I'm so sorry for you and your wife's loss. At the same time, I'm struck by how strong your wife and you are navigating this tough situation. From an Internet stranger to another, may the loving memories of your daughter live on.

I feel like this needs a (1997) on the title.

OP might be thinking about something like this paper "Rig My Ride: Automatic Rigging of Physics-based Vehicles for Games" by Katz et al.

[0] https://melissa2661.github.io/RigMyRide/

Why the condescending tone, OP has a point. Techniques like RigAnything[0] exist - whether this is within the scope of this project is another topic, but this seems like a reasonable request to me (especially considering how many x_2_y-named projects are ML related)

[0] https://www.liuisabella.com/RigAnything/

This kind of work is way more difficult and involved than it appears to be. Sure, you can auto-rig stuff, but it won't be perfect and will require tweaking. Rigging alone is also very far from a complete result

And they even use Nix, to add to the craziness.

[0] https://flox.dev/nixinthewild/nix-in-the-wild-bellroy/

Nix isn't so exotic anymore. Every company for which I interviewed about a year ago used Nix

And every person I met today had a parrot on their shoulder. Doesn't really mean it applies to the general public (here meaning most developers out there).

I'd say <1% of all developers world wide have even heard of Nix.

It is used in production much, much more widely than Haskell is, though it remains far from the most common way to do builds or deployments.

I call it my "homeprod" - but then, what happens if your infra spans multiple sites, and the cloud? Then it's just "prod" at that point. Probably best to just call it your "personal infra / servers", or if you have a family, "family servers".

This is big. Hopefully no more relying on macFUSE which is unmaintained and a pain to install and work with.

MacFUSE is well maintained and has regular releases. Apple silicon support is good, and I just installed an update a few days ago.

It does require a KEXT which requires lowering boot signing strength, which is annoying

This is similar to how a (cheap) DisplayPort-to-HDMI adapter worked, the adapter itself is completely passive.

Many devices with DisplayPort output support multimode, which allows the device to switch from outputting DP packets to outputting TMDS-based HDMI or DVI signals. You'll sometimes see a ++DP logo on these ports.

This is also why you don't see a cheap HDMI(source)-to-DisplayPort(sink) adapter, the smarts just aren't built into the source device.

> the adapter itself is completely passive

I think it was not completely passive, but simple level conversion; DisplayPort is AC-coupled signal, HDMI is DC-coupled.

There is a difference between DP+ and DP++. DP+ uses external level shifter, DP++ uses passive adapter and the card switches different transmitter into the path internally.

> I think it was not completely passive, but simple level conversion; DisplayPort is AC-coupled signal, HDMI is DC-coupled.

Wait, I don't think that's accurate. I've worked with HDMI/DVI and both are AC-coupled, that is, you put a 10 or 20 nF cap in series on the TMDS lines if you're driving directly from an FPGA's digital IO pins.

Signal level and coupling are separate things.

> Signal level and coupling are separate things.

sure, but the part is called a level shifter. MAX9406 DisplayPort to DVI™/HDMI Level Shifter

https://www.analog.com/en/products/max9406.html

Cheap-ish, luckily. I was quite relieved to find a reasonable ($50ish) active HDMI-DP converter. I have an old Dell monitor that only does HDMI 1.3 so to drive its full resolution you need to use its Displayport (or dual link DVI) input. And modern devices generally don't have either. The gadget solves the problem and gets me my 2560x1440 resolution.

if it uses 'power' (aside wire resistance) is not passive, e.g. I'd consider resistors, capacitors, coils - passive, even I'd agree about diodes, even though they'd add latency. DP->HDMI requires some electronics (a level shifter) as bare min.