Earlier quoted context omitted.
[flagged]
> You’re right to call this out. This is such a nightmare. Burning down the world so I can read this shit.
Kill me kill me kill me my profession is a joke
Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
61–70 of 95 posts
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#62We've been running filesystem-based agents internally at heyvid for about six months now, and the deployment story has honestly been the messiest part. You end up hand-rolling so much scaffolding that's not your core product. The 'Vercel for agents' framing clicks immediately — I remember when Vercel did the same thing for frontend and it just removed a whole category of yak-shaving. Curious how Terminal Use handles state persistence across runs; that's been our biggest headache when agents need to resume mid-task.
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#63Im curious if you guys are seeing rate limiting issues. Agents sharing api keys tend to be retry storm monsters. I wonder how agent companies will address
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#64Based on the docs and API surface, I think the filesystem abstraction is probably copy-on-mount backed by object storage. I suspect it works as follows: when a task starts, filesystem contents sync down from S3/R2/GCS to a local directory, which gets bind-mounted into the container. The agent reads and writes normally - no FUSE, no network round-trips per file op. On task completion or explicit sync, changes flush ba…
sprites.dev / fly.io has publicly said they are using a variant of JuiceFS for the object-storage-to-VM-filesystem stuff, it's cool tech.
* https://fly.io/blog/design-and-implementation/ * https://juicefs.com
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#65Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#66The version pinning approach for existing tasks is a pattern I've found really useful in practice. When you're building document processing workflows (transcripts, reports, etc.) the ability to iterate on your agent logic without retroactively breaking existing user sessions is underrated.
One question: for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger? E.g. if I fix a genuine bug in how I'm parsing a document, I might want to re-run the agent on specific old workspaces with the new version, rather than waiting for users to start new tasks.
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#67Really interesting platform — the decoupled filesystem model makes a lot of sense for long-running agents.
One area I'd love to understand better: inter-agent communication and auditability. When multiple agents share the same filesystem (e.g., a coordinator agent and several sub-agents), how is message passing or state handoff handled? Is it purely file-based (agents read/write to agreed-upon paths), or is there a more structured IPC mechanism?
More importantly, from an audit perspective: is there a way to replay or inspect the full sequence of reads/writes and agent messages across a multi-agent task? For production use cases (document processing, internal tooling), being able to trace why an agent made a decision — and which files it read at that moment — feels like a hard requirement. Curious whether this is on the roadmap or expected to be handled at the application layer.
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#68Earlier quoted context omitted.
I think there are some primitives for agents that need to be built out for better security and being able to reason about them. Agents run on infra, they have network connectivity, they have ACLs and permissions that let them read+write+execute on resources, they can interact with other agents. To manage them from both an infra and security perspective, we can use the existing underlying primitives, but it's also use…
[dead]
As a psychiatrist, this problem reminds me of something we studied for a long time.
Patients get worse in areas we are not measuring, but the numbers we record still look normal.
We learned that checking results catches things that checking process cannot catch.
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#69Really interesting platform — the decoupled filesystem model makes a lot of sense for long-running agents. One area I'd love to understand better: inter-agent communication and auditability. When multiple agents share the same filesystem (e.g., a coordinator agent and several sub-agents), how is message passing or state handoff handled? Is it purely file-based (agents read/write to agreed-upon paths), or is there a m…
Holy emdash, you real?
Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents
#70There clearly needs to be something in this space, but I can't imagine the world standardizing on a closed source system for this infra.
I know OSS business models are rough, but someone is going to solve this in open source and I think that is what will achieve traction.