I recently picked up a refurbished Lenovo ThinkStation, and it's an absolute beast. I keep it next to my main work machine and offload all the heavy work to it like running multiple agents, jobs, etc. It's connected via Tailscale, and I’m usually just SSH'd into it.

What I'm missing is a clean, easy way to see what's actually going on on that machine at a glance. Looks like this might fit the bill?

But from a UX standpoint its a nonstarter

Youre asking users to

- leave the site/app

- open their email client

- compose a message or at least hit send

- wait for a reply

- then come back and continue

Thats a lot of steps compared to enter email -> click link. Each additional step is a dropoff point especially on mobile or for less technical users. Many people dont even have a traditional mail client set up anymore, they rely on webmail or app switching which adds even more friction

It also introduces ambiguity

- What exactly am I supposed to send

- did it work

- What if I dont get a reply

From the service side youre trading a simple well understood flow for a much more complex inbound email processing system with all the usual headaches (spoofing parsing delivery delays spam filtering)

In practice most systems optimize for minimizing user effort even if that means accepting some level of abuse and mitigating it elsewhere. A solution that significantly increases friction... no matter how principled...just wont get adopted widely

So while the idea is interesting from a protocol design perspective its hard to see it surviving contact with real users

What actually has to change at the systems level (data layout, memory, scheduling, storage, networking, etc.) for agents to become a first-class workload rather than just another application pattern on existing infrastructure?

The future of agents is dictated by the future state of LLMs, not the present state.

Both hobbyists and professionals are understandably frustrated that tokens are being consumed quickly without justification, or at least in ways that seem entirely avoidable.

Yeah, totally... a full touchscreen computer in your pocket with no physical keyboard, pinch-to-zoom magic people thought was CGI, a browser that wasn't a joke, visual voicemail, and an OS so smooth it made every other phone look like it ran on car batteries. Truly underwhelming stuff.

It literally redefined an entire industry, vaporized half the product lines at Nokia/BlackBerry/Palm/Microsoft, and set the blueprint for every smartphone that exists today.

But sure..."unimpressive."

This is the weirdest revisionist history I've ever heard.

If you mean that the iPhone has come a long way and that it was unimpressive relative to the phones we have 18 years later, sure. But unimpressive it was not.

What this startup did isn't that, AFAICT. It wasn't manual work in service of learning...it was just fraud as a business model, no? Like, they were pretending the technology existed before it actually did. There's a bright line between unscalable hustle and misleading customers about what your product actually is.

Doing unscalable things is about being scrappy and close to the problem. Pretending humans are AI is just straight up deceiving people.

Sure, they phrased it as "they will reach AGI," but that's clearly tongue-in-cheek...the underlying idea is "they better reach AGI, because that's the only way they could make money." So my comment ("necessary, not sufficient") was just pointing out that even if AGI is required for profitability, it doesn't mean they'll actually get there or succeed once they do, and that the original comment was perfectly compatible with the idea that not every business reaches profitability.

SQL is a formal language, not a natural one. It's precise, rigid, and requires a specialized understanding of schema, joins, and logic. text-to-sql systems don't exist because people are too lazy to type; they exist because most people can't fluently express analytical intent in sql syntax. They can describe what they want in natural language ("show me all active users who registerd this year"), but translating that into correct, optimized sql requires at least familiarity, and sometimes expertise

So the governance challenges discussed in the article aren't about "oh SQL is too hard to type"...they're about trust, validation, and control when you introduce an AI intermediary that converts natural lang into a query that might affect sensitive data