News for hackers. Stuff that matters.
Re:LLM Workflows then Agents: Getting Started with Apache Ai... by ldjkfkdsjnv on Monday March 31, 2025 @08:45PM (#43541658)
Extremely bearish on existing tools solving agentic workflows well. If anyone, it will be temporal. Airflow and the like simply were not designed for high dynamic execution, and so have all sorts of annoyances that will make them lose.
Re:LLM Workflows then Agents: Getting Started with Apache Ai... by alittletooraph2 on Monday March 31, 2025 @09:13PM (#43541817)
Temporal’s great! That being said, there is something about being able to orchestrate LLMs and agents using what many already use to orchestrate their data workflows because there’s already proven out reliability, scalability, observability, etc. I’m sure there are boundary conditions for really advanced agentic workflows though…
Re:LLM Workflows then Agents: Getting Started with Apache Ai... by acchow on Tuesday April 01, 2025 @03:16AM (#43543774)
Temporal is for a static graph with idempotent nodes. Powerful LLM workflows don’t fit this model.
Re:LLM Workflows then Agents: Getting Started with Apache Ai... by ldjkfkdsjnv on Tuesday April 01, 2025 @09:46AM (#43546731)
Temporal is absolutely not for a static graph, idempotent nodes yes. Please explain your argument more
Re:LLM Workflows then Agents: Getting Started with Apache Ai... by tomwheeler on Wednesday April 02, 2025 @10:00PM (#43563896)
> Temporal is absolutely not for a static graph

I'd clarify this to say "Temporal is absolutely not limited to a static graph." It can certainly handle a static graph, but it can also handle a dynamic one. Here is an example in Go (https://github.com/temporalio/samples-go/tree/main/choice-mu...), there are similar ones for other languages.

I think the confusion might stem from the determinism requirement in Temporal (and other replay-based Durable Execution platforms). It's not the Workflow Definition (i.e., the code) that must be deterministic, it's the Workflow Execution (i.e., a specific running instance of that code) that must be deterministic. Each running instance is allowed to take a different path through that code, so long as it does so consistently when executed with the same input.

Re:LLM Workflows then Agents: Getting Started with Apache Ai... by jedberg on Monday March 31, 2025 @10:30PM (#43542238)
Have you checked out DBOS Transact[0]? DBOS is designed for high dynamic execution, and doesn't have the overhead or complexity of Temporal [1].

Disclosure, I'm the CEO of DBOS.

[0] https://github.com/dbos-inc/dbos-transact-py

[1] https://www.dbos.dev/blog/durable-execution-coding-compariso...

Re:LLM Workflows then Agents: Getting Started with Apache Ai... by ldjkfkdsjnv on Tuesday April 01, 2025 @09:46AM (#43546734)
I have seen it! And appreciate your response, just haven't had the time to dive in.

If you want a product hint from me, I think that adding integrations natively into the platform that would allow vibe coders to build asynchronous agents easier would really boost revenue. Like email, text, etc.

Probably not your vision, just a suggestion

Re:LLM Workflows then Agents: Getting Started with Apache Ai... by jedberg on Tuesday April 01, 2025 @12:03PM (#43548402)
> that would allow vibe coders

We've experimented with that actually! Six months ago it was terrible, but the new models are getting pretty good.

And it's definitely easier for an AI to generate DBOS code to make a fully formed distributed system than a fully formed distributed system somewhere else.

Re:LLM Workflows then Agents: Getting Started with Apache Ai... by ldjkfkdsjnv on Wednesday April 02, 2025 @07:50AM (#43555705)
Making an asynchronous ai agent is still hard, there is a disconnect between the agentic LLM code (langgraph, openai agents, etc) and asynchronous distributed systems/message passing. True AI agents will have a cohesive joining of the two.
Re:LLM Workflows then Agents: Getting Started with Apache Ai... by nikolayasdf123 on Monday March 31, 2025 @10:32PM (#43542245)
maybe it is not "highly dynamic execution" in the first place. daily/hourly schedule for batch processing is not too bad. and of course, rarely run jobs (e.g. github review, slack, etc. as author says in post) is definitely ok