Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive.

I put a few more thoughts about this here:

https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

Security is a major concern but I don't see why we aren't already "good enough" with a sandbox VM, separate gateway for secrets and remote service access, and a single tenant using frontier models that have safety checks built in plus not trying to hack themselves.

I put up more thoughts on architecture and security here and would love to learn if I'm missing anything.

https://housecat.com/blog/agent-computer-101

I've been doing this architecture on single tenant VMs for like 6+ years now and it has so many advantages for deployments, security and scaling.

Pretty much every new tool and agent computer I set up uses this pattern. I've blogged about it and created a template repo.

https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-... https://github.com/housecat-inc/scratch

AI lets you LARP.

Want to be the head of a game studio? "Hire" a bunch of game dev agents, put them to work in the software factory, get pretty progress updates and an actual game of sorts along the way.

Want to be the CEO of a startup? Hire a bunch of biz ops agents, and fire them when they make mistakes. Ship an actual website and MVP and make some numbers go up along the way.

If you know you're playing a game its fun and weird. But I worry for the people that don't know they're LARPing...

I recently wrote how we set all this up for our agent computers that help people with their email:

https://housecat.com/blog/agent-computer-101

I do agree even more rules help keep things on track, but I do these as linters, specifically as Golang `go vet` and `go fix` commands. That works 100x better than any SKILL.md or team of agents in my experience.

Is there a good resource indexing all the coding agent tools / harnesses? Every awesome list I've found so far seems very incomplete, but I'm sure its impossible to keep up.

My daily drivers are still:

- exe.dev + Shelley + terminal multiplexer (https://zmx.sh/ or tmux) + `codex` CLI - Conductor.build

I would love an open source solution with nice desktop / web / mobile / remote options and notifications, but seems like it could be a while before things settle down and the "winners" emerge?

Maybe it's my fault, or maybe a model training, or something to improve in docs and SDKs?

Pretty much every web app I build has this pattern in it from day 1, as they all quickly expand to have a realtime inbox and notifications subsystem to support workflows and agents.

I have a number of these pieces in a binary I drop first thing on every agent computer: https://github.com/housecat-inc/scratch

Chat to code with an inspector to point at specific DOM sections, review diffs on the box, hand off to mobile, etc.

Makes me wonder where all this will end up. Or DIY win with hyper-personalized tools? Will one vendor become the center of gravity similar to VSCode in previous generation? Will there be a cottage industry of more opinionated tools?

If they're so concerned about cost, why not do what you'd do with any other vandal with a spray paint can...

Immediately paint over it with grey paint to neutralize the "blight", then efficiently do a deeper clean / removal / repair the facade.

Seems like they gave the Banksy very special treatment of fence, guards, etc. and now are paying for the side effects of that.

https://github.com/nzoschke/sgtm

Hi I'm Noah, founder and CTO at Housecat.com

Housecat is an email inbox that gets real work done by connecting it to tools like your CRM, Slack, GitHub, and Claude. It is used by individuals and small teams that want to eliminate busywork and get through email incredibly fast.

The team is founded by veterans in building tools people love including early builders of Heroku and Monzo. We value collaboration, working efficiently, and having fun.

Stack: HTML, JS, Go, SQLite, Postgres; Templ, HTMX, DBOS; Deployed to GCP and exe.dev

Skills: Coding agents, GitHub, API/CLI/UI design and implementation, Gmail/GCal/CRM APIs

Duties: full lifecycle across production, engineering, support, sales

Benefits: Health care, Office downtown SF with hybrid days, flexible PTO, generous equity, awesome team mates

Apply directly to the email address in my HN profile.

Building a cloud like Fly is very difficult. Staying nimble through technology shifts is hard.

I’m right there with you on the agent computer shift. It’s forever changed how I code and deploy and architect systems.

Thanks for all the hard work, hosting, blogging and open source. Looking forward to what the next chapter brings us all.

And why does this depend on node / npx? Something to do with the JSX syntax and parsing?

I wish go std templates were more ergonomic for components.

Past that I wish projects like templ or GSX have a simple go generate pipeline, and support html and text/markdown output including whitespace.

Until then I have a Frankenstein of a bunch of templating.

Once you start down the "durable workflows" path, you start seeing them everywhere.

My latest experiments are treating individual emails as durable workflows, where you, the people you're communicating with, agents and tools like GitHub or Attio all take turns in the flow.

https://housecat.com/blog/gmail-durable-workflows-sandbox-vm

I wouldn't trust a agent chat or SKILL.md for numbers just yet.

But I would trust having a coding agent code the workflow, then have real people review the code, operate the tool, and double check the numbers.

We started as a hosted claw of sorts. But the less technical folks wanted something more than chats and markdown to do their work.

We then added a modern todo list interface. Having the agent create and update action items from email and Slack turns out to be genuinely useful, but having another TODO list to check wasn't as useful.

So we landed back on an email inbox. Having your actual email to work on, plus the "inbox" to also home other tasks and chats from the agent, is feeling very productive.

First its a question of the shape of a product. There are a few paradigms:

1. Keep AI far away from my email

2. Side bar chat in email app

3. Chat app that can interact with email

4. Fully autonomous email agents

I don't like 4. At its core, real email is person to person communications, and we want to keep humans in the loop and actually writing thoughtful messages back and forth.

3 is here to stay, but I don't think most people actually want to free form chat or vibe code their day to day communications long term.

We can expect 2 in pretty much every SaaS but so far I'm underwhelmed by many experiences. An agent only truly works when it has great tools, and not many email providers or apps have great APIs or higher level tools and primitives other than "draft" and "send".

So first we're working on great tools for the human. Common templates, dynamic folders and labels, context from your CRM, integrated tools for your other workspace tools, easy ways to code customizations and workflows.

Next we're equipping the agent with the same tools to help you, only when you want it to.