Comments URL: https://news.ycombinator.com/item?id=48047360

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48036746

Points: 43

# Comments: 10

Comments URL: https://news.ycombinator.com/item?id=48019634

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47972476

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47963693

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47931569

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47922823

Points: 1

# Comments: 0

This post says little about that, and suggests some improvements the _reviewer_ can make.

I think that's completely the wrong end of the stick to be tackling. As the burden is still on the reviewer and not the author.

Comments URL: https://news.ycombinator.com/item?id=47887234

Points: 1

# Comments: 0

[1]: https://news.ycombinator.com/item?id=47832720

Comments URL: https://news.ycombinator.com/item?id=47874589

Points: 1

# Comments: 1

> The OAuth consent screen will give you a choice of three levels of access: read-only (see emails, contacts, calendars), write (update emails, save drafts, edit contacts and events), and send (send emails).

If you look at the gifs of the Claude UI in this post[1], you can see how the HTTP response is broken on page refresh, but some time later the full response is available again because it's now being served 'in full' from the database.

[1]: https://zknill.io/posts/chatbots-worst-enemy-is-page-refresh...

This is absolutely the hardest bit.

I guess the short-cut is to include all the chat conversation history, and then if the history contains "do X" followed by "no actually do Y instead", then the LLM can figure that out. But isn't it fairly tricky for the agent harness to figure that out, to work out relevancy, and to work out what context to keep? Perhaps this is why the industry defaults to concatenating messages into a conversation stream?

Obviously polling works, it's used in lots of systems. But I guess I am arguing that we can do better than polling, both in terms of user experience, and the complexity of what you have to build to make it work.

If your long running operations just have a single simple output, then polling for them might be a great solution. But streaming LLM responses (by nature of being made up of lots of individual tokens) makes the polling design a bit more gross than it really needs to be. Which is where the idea of 'sessions' comes in.

The pattern I describe in the article of 'channels' works really well for one of the hardest bits of using a durable execution tool like Temporal. If your workflow step is long running, or async, it's often hard to 'signal' the result of the step out to some frontend client. But using channels or sessions like in the article it becomes super easy because you can write the result to the channel and it's sent in realtime to the subscribed client. No HTTP polling for results, or anything like that.

Of course the hard bit then is; how does the client know there's new information from the agent, or a new session?

Generally we'd recommend having a separate kind of 'notification' or 'control' pub/sub channel that clients always subscribe to to be notified of new 'sessions'. Then they can subscribe to the new session based purely on knowing the session name.

The article is about how agents are getting more and more async features, because that's what makes them useful and interesting. And how the standard HTTP based SSE streaming of response tokens is hard to make work when agents are async.

Comments URL: https://news.ycombinator.com/item?id=47860949

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47845581

Points: 3

# Comments: 0