[campbel]

I follow Mr. Huang, read/watch his content and also plan to use PocketFlow in some cases. A preamble, because I don't agree with this assessment. I think agents as nodes in a DAG workflow is _an_ implementation of an agentic system, but is not the systems I most often interact with (e.g. Cursor, Claude + MCP).

Agentic systems can be simply the LLM + prompting + tools[1]. LLMs are more than capable (especially chain-of thought models) to breakdown problems into steps, analyze necessary tools to use and then executing the steps in sequence. All of this is done with the model in the driver seat.

I think the system described in the post need a different name. It's a traditional workflow system with an agent operating on individual tasks. Its more rigid in that the workflow is setup ahead of time. Typical agentic systems are largely undefined or defined via prompting. For some use cases this rigidity is a feature.

[1 https://docs.anthropic.com/en/docs/build-with-claude/tool-us...

[TeMPOraL]

> Agentic systems can be simply the LLM + prompting + tools[1]. LLMs are more than capable (especially chain-of thought models) to breakdown problems into steps, analyze necessary tools to use and then executing the steps in sequence. All of this is done with the model in the driver seat.

Sort of, kind of. It's still a directed graph. Dynamically generated graph, but still a graph. Your prompted LLM is the decision/dispatch block. When the model decides to call a tool, that's going from the decision node to another node. The tool usually isn't another LLM call, but nothing stops it from being one.

The "traditional workflow" exists because even with best prompting, LLMs don't always stick to the expected plan. It's gotten better than it used to, so people are more willing to put the model in the driving seat. A fixed "ahead of time" workflow is still important for businesses powering products with LLMs, as they put up a facade of simplicity in front of the LLM agentic graph, and strongly prefer for it to have bounded runtime and costs.

(The other thing is that, in general, it's trickier to reason about code flow generated at runtime.)

[infecto]

Kind of. This explanation feels pedantic—like calling my morning routine a dynamically generated graph (which it technically is). Others have pointed this out, but the industry seems split. Workflows like those described in the article resemble Airflow jobs, making them, well, workflows.

Corporate buzzwords have co-opted "Agent" to describe workflows with an LLM in the loop. While these can be represented as graphs, I'm not convinced "Agent" is the right term, even if they exhibit agentic behavior. The key distinction is that workflows define specific rules and processes, whereas a true agent wouldn’t rely on a predetermined graph—it would simply be given a task in natural language.

You're right that reasoning about runtime is difficult for true agents due to their non-deterministic nature, but different groups are chipping away at the problem.

[therealpygon]

In my opinion, the split is between the people who want their tools to be called Agents so they can make more on AI hype, and the people who know better than to call a simple pre-defined software workflow an “agent”. It is harder to get large investments for “my program just calls an LLM” these days.

[jwpapi]

I have to agree this is a bit too simple for being anything of substance. That is not what really agentic means. This is basically implementing ChatGPT into Zapier.

When you work with agentic LLMs you should worry about prompt chaining, parallel execution, deciding points, loops and more of these complex decisions.

People who didn’t know what’s in first article shouldn’t use Pocketflow and go with N8N or even Zapier.

[zh2408]

I do agree what you said except the first sentence. The design of the Graph is super important. Pocketflow is for those with technical background.

[zh2408]

Let me clarify: this tutorial focuses on the technical internal implementation of the agent (e.g., OpenAI agent, Pydantic AI, etc.), rather than the UI/UX of the agent-based products that end users interact with.

[yed]

The newest generation of agents[0] aren't implemented this way; the model itself is trained to make decisions and a plan of action rather than an explicitly programmed workflow tree.

[0] https://openai.com/index/computer-using-agent/

[zh2408]

I think you’re referring to function calling: https://platform.openai.com/docs/guides/function-calling

This still returns a string. You need to explicitly program the branch to the right function. For example, check out how OpenAI Agents, released a week ago, rely on a workflow: https://github.com/openai/openai-agents-python/blob/48ff99bb...

[yed]

No I'm referring to the newest generation of agentic models one of which I linked to. These are not fully released but it is where the newest generation of research is headed.

[zh2408]

It's hard for me to comment on something not open sourced

[nileshtrivedi]

That remains to be seen. Manus, a standard agent built with Claude 3.7, outperforms o3 agentic model on the GAIA benchmark.

[throwaway7783]

Operator/Computer Use is a bridge until we no longer need any tools at all

[achierius]

What gives you any confidence in that transition happening in the best future?

[campbel]

That's what I am talking about as well. The low-level implementation of an agent isn't necessarily a rigid graph, and I'd actually argue its explicitly not this.

[zh2408]

The current implementations of Agents, e.g., OpenAI agents released last week, are based on graph (workflow): https://github.com/openai/openai-agents-python/blob/48ff99bb...

Not sure about Cursor you mentioned as its agent is not open sourced.

[campbel]

This link is also referring to the nodes as agents. So its a system of agents interacting to product an outcome. I'm not saying this system is bad, just that I think it deserves another name rather than calling the whole system an "Agent". It's many agents working in a coordinated fashion.

[zh2408]

No. It's not many agents in the workflow. It's not an agent per node.

The whole workflow and the Runner class is for one agent.

Check out this line: https://github.com/openai/openai-agents-python/blob/48ff99bb...

A single `run_agent` is implemented based on the Runner class and workflow. So usually the workflow is for one agent (unless there is handoff).

[campbel]

They define it in the same file https://github.com/openai/openai-agents-python/blob/48ff99bb...

> An agent is an AI model configured with instructions, tools, guardrails, handoffs and more.

Agents can hand off to other agents, but even the hand-off is decided by the agent itself, not a pre-defined orchestration.