4 ms·

> There are agent frameworks that are not rebranded workflow tools too. To me "workflow" is just what agent means: the rules under which an automated action oc

> There are agent frameworks that are not rebranded workflow tools too. To me "workflow" is just what agent means: the rules under which an automated action occurs. Without some central concept "agent" just a magic wand that does stuff that may or may not be what you want it to do. If we can't use state machines at all I'm just going to go out and say LLMs are a dead end. State machines are the bread and butter of reliable software. > Forget about boxes and deterministic control and start thinking of error tolerance and recovery. First you'd have to define what an error even is. Then you're just writing deterministic software again (a workflow), just with less confidence. Nice for stuff with low risk and confidence to begin with (eg semantic analysis etc whose error tends to wash out in aggregate), but not for stuff acting on my behalf. LLMs are cool bits of software, but I can't say I see much use for "agents" whose behavior is not well-defined and whose non-determinism is formally bounded.

infecto 2y ago
It’s getting pedantic, but the key idea is that Agents can solve problems traditional state machine-based workflows couldn't. Your point is moot since many of these modern workflows already use LLMs as gating functions to determine the next steps. It’s a different way of approaching problems, and while the future is uncertain, LLMs have moved beyond being just "cool software" to becoming genuinely useful in specific domains.
- ForTheKidz 2y ago
  Hmm, maybe you are referring to something specific with "workflow". I'm envision a visual graph with a ui for each node and connection, or maybe a makefile on the other end of the spectrum. What are you envisioning? Anyway, LLMs will remain at "cool software" like other niche-specific patterns until I see something general emerge. You'd have to pitch LLMs pretty savvily to show it as a clear value-add. Engineers are extremely expensive, so LLMs need to have a very low error rate to be integrated into the revenue-path of a product to not incur higher costs or a lower-quality service. I still see text- and code-generation for immediate consumption by a human (or possible classification to be reviewed by a human) as the only viable uses cases today. It's just way too easy to manipulate them with standard english.
  - infecto 2y ago
    > Hmm, maybe you are referring to something specific with "workflow". I'm envisioning a visual graph with a UI for each node and connection, or maybe a makefile on the other end of the spectrum. What are you envisioning? In job orchestration systems, workflows are structured sequences of tasks that define how data moves and transforms over time. Workflows are typically defined as Directed Acyclic Graphs (DAGs) but they don't have to be. I don't believe I am referring to anything more specific than how orchestration systems generally use them. LLM-based agents shift the focus from rigidly defined transitions to adaptable problem-solving mechanisms. They don’t replace state machines entirely but introduce a layer where strict determinism isn’t always necessary or even desirable. > Anyway, LLMs will remain at "cool software" like other niche-specific patterns until I see something general emerge. You'd have to pitch LLMs pretty savvily to show it as a clear value-add. Engineers are extremely expensive, so LLMs need to have a very low error rate to be integrated into the revenue-path of a product to not incur higher costs or a lower-quality service. I still see text- and code-generation for immediate consumption by a human (or possible classification to be reviewed by a human) as the only viable uses cases today. It's just way too easy to manipulate them with standard English. I get the skepticism, especially about error rates and reliability. But the “cool software” label underestimates where this is heading. There’s already evidence of LLMs being useful beyond text/code-gen (e.g., structured reasoning in research, RAG-enhanced search, or dynamically adapting workflows based on complex input). The real shift isn’t just about automation but about adaptive automation, where LLMs reduce the need for brittle, predefined paths. Of course, the general-use case is still evolving, and I agree that direct, high-stakes automation remains a challenge. But dismissing LLM-driven agents as just niche tools ignores their growing role in augmenting traditional software paradigms.

infecto 2y ago

It’s getting pedantic, but the key idea is that Agents can solve problems traditional state machine-based workflows couldn't. Your point is moot since many of these modern workflows already use LLMs as gating functions to determine the next steps. It’s a different way of approaching problems, and while the future is uncertain, LLMs have moved beyond being just "cool software" to becoming genuinely useful in specific domains.

ForTheKidz 2y ago
Hmm, maybe you are referring to something specific with "workflow". I'm envision a visual graph with a ui for each node and connection, or maybe a makefile on the other end of the spectrum. What are you envisioning? Anyway, LLMs will remain at "cool software" like other niche-specific patterns until I see something general emerge. You'd have to pitch LLMs pretty savvily to show it as a clear value-add. Engineers are extremely expensive, so LLMs need to have a very low error rate to be integrated into the revenue-path of a product to not incur higher costs or a lower-quality service. I still see text- and code-generation for immediate consumption by a human (or possible classification to be reviewed by a human) as the only viable uses cases today. It's just way too easy to manipulate them with standard english.
- infecto 2y ago
  > Hmm, maybe you are referring to something specific with "workflow". I'm envisioning a visual graph with a UI for each node and connection, or maybe a makefile on the other end of the spectrum. What are you envisioning? In job orchestration systems, workflows are structured sequences of tasks that define how data moves and transforms over time. Workflows are typically defined as Directed Acyclic Graphs (DAGs) but they don't have to be. I don't believe I am referring to anything more specific than how orchestration systems generally use them. LLM-based agents shift the focus from rigidly defined transitions to adaptable problem-solving mechanisms. They don’t replace state machines entirely but introduce a layer where strict determinism isn’t always necessary or even desirable. > Anyway, LLMs will remain at "cool software" like other niche-specific patterns until I see something general emerge. You'd have to pitch LLMs pretty savvily to show it as a clear value-add. Engineers are extremely expensive, so LLMs need to have a very low error rate to be integrated into the revenue-path of a product to not incur higher costs or a lower-quality service. I still see text- and code-generation for immediate consumption by a human (or possible classification to be reviewed by a human) as the only viable uses cases today. It's just way too easy to manipulate them with standard English. I get the skepticism, especially about error rates and reliability. But the “cool software” label underestimates where this is heading. There’s already evidence of LLMs being useful beyond text/code-gen (e.g., structured reasoning in research, RAG-enhanced search, or dynamically adapting workflows based on complex input). The real shift isn’t just about automation but about adaptive automation, where LLMs reduce the need for brittle, predefined paths. Of course, the general-use case is still evolving, and I agree that direct, high-stakes automation remains a challenge. But dismissing LLM-driven agents as just niche tools ignores their growing role in augmenting traditional software paradigms.