Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#31

Post by devonkelley »

alexchantavy wrote: post #12
verdverm wrote: post #2

Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra? eg. I already run Kubernetes

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]

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#32

Post by vivekraja »

rodchalski wrote: post #20

[dead]

This is what we see! We want to make it very easy to be able to granularly manage your agents (in terms of files they have access to, env var values, network policy, etc.) on a per-task basis.

With regards to permissions, mileage varies based on SDK. Some have very granular hooks and permission protocols (Claude Agent SDK stands out in particular) while for others, you need a layer above it since it doesn't come out of the box.

There are companies that solve the pain of authn/z for agents and we've been playing with them to see how we could complement them. In general, we do think it's valuable to be provide this at the infra level as well rather than just the application level since the infra layer is the source of truth of what calls were made / what were blocked, etc.

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#35

Post by vivekraja »

oliver236 wrote: post #18

is this a replacement to langgraph?

Depends on your agent. We haven't used langgraph, but I'd think it's probably the best solution to deploy langchain agents. We're SDK agnostic. We're like langgraph, but for agents that works in a sandbox and needs access to a filesystem to do work.

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#36

Post by vivekraja »

instalabsai wrote: post #7
verdverm wrote: post #2

Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra? eg. I already run Kubernetes

We have also built something custom ourselves (with modal.com serverless containers), running thousands of on-demand coding agents each day and already the assumptions that Terminal Use is making (about using the file system and coding agent support) would not work for our use case.

Curious to hear why we wouldn't work! I'd love to understand what assumptions we're making that won't work for your use case, and what we could work to improve on

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#38

Post by nr378 »

Based 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 back to object storage. The presigned URL support for upload/download is the giveaway that object storage is the source of truth.

This makes way more sense than FUSE for agent workloads. Agents do thousands of small reads (find, grep, git status) that would each be a network call with FUSE. With copy-on-mount it's all local disk speed after initial sync.

Cross-task sharing falls out naturally - two tasks mounting the same filesystem ID just means two containers syncing from the same S3 prefix. Probably last-write-wins rather than distributed locking, which is fine since agents rarely have concurrent writes to the same file.

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#39

Post by vivekraja »

devonkelley wrote: post #30
verdverm wrote: post #2

Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra? eg. I already run Kubernetes

[dead]

Yup! And this is a genuinely hard problem when you try to apply agents to domains other than coding. With coding, you can easily rollback. But in other domains, you take action in the real world and that's not easy to rollback.

We're thinking a lot about how we could provide a "Convex" like experience where we guide your coding agents to set up your agents in a way that maximizes the ability to rollback. For example, instead of continuously taking action, it's better that agents gather all required context, do the work needed to make a decision (research, synthesize, etc.), and then only take action in the real world at the end. If an agent did bad work, then this makes it easy to rollback to the point where the agent gathered all the context, correct it's instructions, and try again

Post reply on HN