The Difference Between Traditional And Agentic Workflows.

In this blog we will explore the difference between traditional explicit workflows and Agentic Workflows and we will take Kubernetes debugging as an example to illustrate why agentic workflows are often more effective for complex tasks.

Single LLM Call Limitation

When I started working on CKAD-Agent, I was thinking that: "If I just call an LLM model to debug a Kubernetes issue, that should be enough", it felt intuitive. Why not just let an LLM parse the problem statement, look at the cluster context, and then tell me what's wrong? But very quickly, I realized that things were not that straightforward.

After exploring frameworks like Autogen and CrewAI, I realized that these tools don't rely on a single call to an LLM. Instead, they wrap the LLM with logic, loops, and orchestration, so that the model can perform tasks step by step, evaluating intermediate results before moving forward.

While the model could parse instructions and attempt to generate a solution, it was not capable of actually finding the root cause. I couldn't just ask the model: "Fix my deployment in the default namespace". The model wouldn't automatically know how to: List the deployments, pick the right pod, fetch the logs and interpret those logs. This is because, debugging Kubernetes issue is not a single step process. It's a workflow with multiple decisions and actions.

The Difference Between Traditional and Agentic Workflows

In this section, we will compare traditional and agentic workflows.

Traditional Workflows

If I would like to design a traditional workflow to debug a Kubernetes issues. I will define the list of steps that my workflow will follow. It will look something like this:

• Step 1: List the deployments.
• Step 2: Select the failed deployment.
• Step 3: Select one pod from that deployment.
• Step 4: Fetch the logs for that pod.
• Step 5. Analyze the logs for errors.

This sequence is deterministic and the steps are defined in advance. What if the issue isn't in the pod logs ? What if the deployment is fine, but the Service is misconfigured, or the Ingress is pointing to the wrong target?

Building explicit workflows for every possible issue would quickly become unmanageable.

Agentic Workflows

Instead of defining each step in advance, the agentic approach allows the system to explore the problem space, adapt to the signals it finds, and choose the best diagnostic path.

I could simply say: "I have an issue in the default namespace." In this case, the agent decides what to do next. Maybe it starts by listing deployments. If the deployments look fine, it might check the Services. If the Services look fine, it could probe the Ingress or check the events.

The agent chooses the commands and iterates based on results, instead of just following a hardcoded path. This second approach looks more like how a Kubernetes admin would debug: following the breadcrumbs until he find the root cause.

Conclusion

What I learned while building CKAD-Agent is that just calling an LLM isn't enough. Debugging Kubernetes or any complex system requires workflows that can adapt and reason.

Traditional workflows are good for repeatable tasks and Agentic workflows are better for exploratory problems, where the steps aren't always known upfront.

If you are thinking of building your own agent, don't just rely on one shot prompts. Instead, give your agent the tools and the ability to iterate.