71–80 of 95 posts
There 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.
Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra? eg. I already run Kubernetes
At least on K8s you can control the network policy. That's the harder problem to solve. I suspect we'll see a lot of exfiltration via prompt injection in the next few years.
Really 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?
Earlier quoted context omitted.
Holy emdash, you real?
Ha, real human here! I'm a Chinese developer. I composed the question myself in Chinese and had AI translate it to English, hence the em dashes. The underlying curiosity about inter-agent auditability is genuinely mine though.
The English that English speakers post on Hacker News is often grammatically incorrect, clumsy, misspelled, and that's okay, good, even. We want to hear from you!
(My preference is for translators to include both the original Chinese words, and the English translation because it means your fellow Chinese speakers get to read your exact words, but of course that is personal preference :)).
The 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 f…
> for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger
Yes, we support manually migrating tasks using "tu tasks migrate".
> 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
In this case the better pattern is to create new tasks against those old workspaces on the fixed version. You could do this on behalf of your users.
Earlier quoted context omitted.
[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,…
One thing we've run into: the filesystem abstraction works well for code artifacts, but when agents interact with external services (APIs, databases), you need a separate "action journal" that logs intended mutations before executing them. This gives you rollback even for side effects that aren't file-based.
The harder unsolved problem is multi-agent state coordination. When Agent A writes to a shared workspace and Agent B reads it, the filesystem gives you structural persistence but not semantic ordering. Have you thought about adding lightweight event ordering (like a simple monotonic sequence) to the filesystem layer? Without it, agents can read stale state even when files are fresh.
Congrats on the launch — the decoupled storage model is the right primitive.
Really 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…
We're experimenting with multi-agent systems to figure out what the right API would be for agent to agent communication. We've found Claude Code's Team feature is a good starting point for the abstraction, but we think there's better abstractions and are creating the primitives to allow people do create custom definitions to explore.
Re: audit perspective. We have something we've been working on that we're excited to share soon which I think you'll like:)
I started by managing the claude agent sdk myself in a daytona container, and it was a lot more challenging than I thought. The agent kept crashing in streaming mode and there was no thread crash, so it was hard to debug, esp in a cloud container like Daytona. I also realized that I needed to implement my own session management system + my own database if I wanna save the chat and on top of that streaming so the messages come out in real time. AND I need to manage my own container janitor/heart beat system so that un-used containers don't just sit there, but I also don't want them to go cold immediately after each message since cold start takes a bit.. They all seem simple but at each step there are some edge cases. I ended up vibe coding most all of that, but it was just quite fragile. For those who hasn't tried the agent sdks, it feels like it's clearly designed to be ran on a client computers with permanent storage + lots of ram than microVMs. Which was not what I expected.
After that, I tried to find some managed option. Starting with blackbox ai because I saw a vercel tweet about them, and for some reason I just couldn't get their agent API stuff to work AT ALL?... I'm curious as to if it's actually working for anyone. Then I tried sandbox dev, which doesn't store container/sessions/storage stuff out of the box for you, so it wasn't much better than doing the daytona container myself. And then I tried terminaluse, and it worked better than I expected given all of the other stuff that I tried.
So at the end of the day, it's kind of like a managed cloud services that does agent chat history, session recovery, streaming + a CLI that makes it easy for my own codex to debug/deploy + file system sync. From what I can tell, there isn't anyone else that can do all that and I'm pretty pleased with using them.