What Is an Agentic Workflow? How to Build One That Plans, Acts, and Evaluates

An agentic workflow is a multi-step system where a language model does more than answer once: it plans, chooses tools, executes actions, checks the result, and decides what to do next until the task is complete. In practice, that means combining an LLM reasoning layer with tool calling, a real execution environment, and an evaluation loop. If you are building coding agents, research agents, or internal automation that must adapt mid-task, this is usually the architecture you are actually building.

What is an agentic workflow?

An agentic workflow is the pattern behind AI systems that can move through a task instead of stopping at text generation. Rather than asking a model for one response and returning it to the user, you let the model operate inside a controlled loop:

1. Read the goal and current state.
2. Plan the next step.
3. Call a tool or run code.
4. Observe the result.
5. Evaluate whether the task is complete.
6. Repeat if needed.

This is different from a fixed workflow, where each step is pre-written in code. In a fixed workflow, you decide the path in advance. In an agentic workflow, the model decides which action to take next within the boundaries you provide.

That distinction matters because many real developer tasks are not linear. A coding agent may need to inspect files before it knows which test to run. A research agent may need to search twice because the first source was incomplete. A browser agent may need to recover from a login failure or a changed page layout. Those are workflow problems, but they require adaptation.

How is an agentic workflow different from an AI agent?

People often use the two terms interchangeably, but it is more useful to separate them:

• An agentic workflow is the execution pattern.
• An AI agent is the product or system built on top of that pattern.

You can have a tightly scoped agentic workflow that only triages support tickets, or a broader AI agent that coordinates planning, tool use, memory, and approval checkpoints across many tasks.

If you want a practical rule, use workflow when you are talking about architecture and control flow, and use agent when you are talking about the user-facing system.

What are the core parts of an agentic workflow?

Most production systems end up with the same five parts.

1. Planner

The planner turns a broad instruction into the next concrete action. Sometimes this is an explicit planning step that outputs a task list. Sometimes it is implicit and happens inside each tool-calling turn. Either way, the model needs enough context to decide whether it should read, write, search, execute, or stop.

Good planning does not mean generating a long outline for every request. It means keeping the next move legible. For short tasks, one-step planning is enough. For longer tasks such as repo refactors, browser automation, or document review, an explicit plan reduces thrashing.

2. Tool layer

Tools are the workflow’s interface to the world. A strong tool layer is usually narrow and predictable. For example:

• read_file(path)
• write_file(path, content)
• search_files(query)
• run_command(cmd)
• fetch_url(url)

Small tools are easier for the model to call correctly, easier to log, and easier to secure. Large “do everything” tools look convenient at first but become hard to debug because you cannot tell whether failures came from the model decision, the tool implementation, or the external system behind it.

3. Execution runtime

Once the model decides to act, something has to execute the action. For any workflow that writes files, installs packages, runs code, or opens browser sessions, this runtime needs isolation.

That is where a sandbox comes in. Novita Agent Sandbox is designed for this execution layer: a separate environment where agent actions can run without touching the host system directly. This is the difference between “the model suggested a command” and “the workflow safely executed that command.”

4. State and memory

An agentic workflow needs working memory across steps. That usually includes:

• conversation state
• tool outputs
• intermediate files
• execution logs
• a scratchpad or short plan

Without state, each step becomes stateless prompt engineering, and the system falls apart as soon as the task spans more than one action.

5. Evaluation loop

This is the part many teams add too late. The workflow needs a way to judge whether a step succeeded and whether the task is done. In a coding workflow, that might mean tests pass. In a research workflow, it might mean the answer cites enough reliable sources. In a browser workflow, it might mean the expected UI state is visible.

Without evaluation, “agentic” often turns into “keeps calling tools until timeout.”

Why planning matters in building agentic workflows

The biggest mistake in building agentic workflows is assuming the model should improvise everything from scratch on every turn.

That usually creates three problems:

• the model revisits the same files or URLs repeatedly
• tool usage becomes noisy and expensive
• the workflow loses a clear stopping condition

A better pattern is lightweight planning plus grounded execution. Let the model decide the next action, but make it do so against an explicit task, a visible current state, and a small set of allowed tools. That keeps flexibility where it helps and removes it where it does not.

In coding workflows, planning often looks like this:

1. Identify the files involved.
2. Read the current implementation.
3. Decide the minimal change.
4. Make the edit.
5. Run verification.
6. Either stop or repair.

This is still agentic, because the model can branch when the repo surprises it. But it is not wandering.

How should tool use work in an agentic workflow?

Tool use should be explicit, typed, and observable.

If your model supports function calling, use it. Novita’s LLM API exposes an OpenAI-compatible endpoint and documents function calling directly, which is the cleanest way to let the model choose among tools without relying on brittle string parsing.

A few rules make tool use much more reliable:

• Keep tool names concrete.
• Use schemas with required fields.
• Return complete results, including errors.
• Log every call, argument, and output.
• Make destructive actions rare and easy to gate.

The tool layer should also reflect real boundaries. For example, do not give a coding agent one mega-tool called edit_repo_and_run_tests. Split the read, write, and execution steps so the model can recover when something fails.

Why does code execution need a sandbox?

An agentic workflow that never executes anything can often stay inside an ordinary app server. The moment it starts running shell commands, installing dependencies, handling downloaded files, or browsing the open web, you need isolation.

Sandboxing solves two different problems:

• Safety: generated code and tool outputs can be wrong, hostile, or simply unpredictable.
• Statefulness: multi-step tasks need a persistent workspace where files, packages, and execution history survive across turns.

For many teams, the second point is just as important as the first. A workflow that edits code, runs tests, fixes the failure, and reruns verification is not possible if every step starts from a clean machine.

That is why the practical architecture is usually:

• LLM API for planning and tool selection
• Sandbox runtime for execution and persistence

Novita fits that split naturally: the LLM API acts as the planner and tool-calling layer, while Agent Sandbox handles the actual execution environment.

How do you evaluate an agentic workflow?

Evaluation has to happen at two levels.

Step-level evaluation

Did the last action work?

Examples:

• Did the command exit successfully?
• Did the API return valid JSON?
• Did the expected file get created?
• Did the browser page contain the target element?

Task-level evaluation

Did the workflow solve the user’s problem?

Examples:

• Do the tests pass after the code change?
• Does the summary answer the research question with evidence?
• Did the automation complete the transaction without manual cleanup?

Strong workflows use both. If you only evaluate the final output, you miss obvious failure signals during execution. If you only evaluate steps, the workflow can complete a long series of locally valid actions and still fail the real task.

A practical architecture for building agentic workflows

Here is the architecture most teams should start with:

1. A user request enters your app.
2. Your controller sends the goal, state, and available tools to an LLM.
3. The LLM returns either a direct answer or a tool call.
4. Your controller executes the tool inside a sandbox or other controlled runtime.
5. The tool result is appended to the conversation state.
6. An evaluator checks for completion, failure, or approval gates.
7. The loop continues until the workflow is done or blocked.

This controller loop can be simple. In many cases, a single orchestrator process is enough. You do not need a multi-agent system on day one. Start with one planner, a few well-defined tools, one sandboxed runtime, and a clear evaluator.

Example: an agentic workflow controller in Python

The example below shows the control loop shape. It uses Novita’s OpenAI-compatible API for tool calling. The execution functions are yours to implement against your own runtime or sandbox.

import json
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.novita.ai/openai",
    api_key=os.environ["NOVITA_API_KEY"],
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Read a file from the workspace",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": "Run a shell command in the sandbox",
            "parameters": {
                "type": "object",
                "properties": {"cmd": {"type": "string"}},
                "required": ["cmd"],
            },
        },
    },
]


def read_file(path: str) -> str:
    # Implement this against your own workspace or sandbox filesystem.
    raise NotImplementedError


def run_command(cmd: str) -> str:
    # Implement this against your sandbox runtime.
    raise NotImplementedError


dispatch = {
    "read_file": read_file,
    "run_command": run_command,
}


def run_workflow(task: str, model: str) -> str:
    messages = [
        {
            "role": "system",
            "content": (
                "You are a workflow controller. Use tools when needed, "
                "check results after each action, and stop when the task is complete."
            ),
        },
        {"role": "user", "content": task},
    ]

    while True:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            tools=tools,
            tool_choice="auto",
        )

        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content

        for call in message.tool_calls:
            fn = dispatch[call.function.name]
            args = json.loads(call.function.arguments)
            result = fn(**args)
            messages.append(
                {
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": result,
                }
            )

This is intentionally minimal. In production, you would also add:

• retry policy for transient errors
• timeouts and budget limits
• human approval for sensitive actions
• structured step logs
• a task-level evaluator before final completion

Which model should you use as the planner?

For an agentic workflow, the planner model does not just need raw intelligence. It needs the right shape:

• reliable tool calling
• stable long-context behavior
• strong instruction following
• predictable latency at multi-turn depth

If you want an open-weight starting point on Novita, Qwen3 Coder 30B A3B Instruct is a practical option for workflow planning and coding-oriented tool use. Novita’s current model page lists OpenAI-compatible access, function calling support, structured output support, and a 160K hosted context window. For many internal automation and coding tasks, that is enough to build a serious first version before you move to a larger or more specialized planner.

The right model still depends on the job. For broad reasoning-heavy workflows, choose for planning quality first. For high-volume automation, latency and cost can matter just as much as benchmark strength.

Common failure modes in agentic workflows

Most failures are not dramatic. They are repetitive and expensive.

Over-tooling

If every capability becomes its own remote dependency, the workflow spends more time coordinating than doing useful work.

Weak stopping rules

If the system never knows when “done” is true, it keeps generating one more step.

Poor error handling

If tools return vague messages like “failed” instead of actionable output, the model cannot recover.

No sandbox boundary

The workflow may work in development, then become unsafe the moment it touches real files, credentials, or external systems.

No evaluator

The agent appears busy but never proves the task was completed correctly.

When should you not use an agentic workflow?

Do not build one just because the term is popular.

You probably do not need an agentic workflow if:

• the task is one-shot generation
• the path is fixed and rarely changes
• a traditional program can decide every step cheaply
• there is no need for tool use or execution

For example, if your app always takes a form input, calls one prompt, and returns a formatted email, an ordinary LLM workflow is simpler and better.

Agentic workflows pay off when the environment can surprise the system and the system still needs to keep going.

FAQ

Is an agentic workflow the same as function calling?

No. Function calling is one mechanism inside the workflow. The full workflow also needs control flow, state, execution, and evaluation.

Do I need multiple agents to build agentic workflows?

No. Most teams should start with one controller loop and a few tools. Multi-agent designs are useful later, but they are not the default starting point.

What is the most important safety control?

For workflows that run code or touch external systems, the most important control is an isolated execution environment combined with narrow tool permissions.

What is the simplest production-ready stack?

A good first stack is: an OpenAI-compatible LLM API, a small tool registry, a sandboxed runtime, and an evaluator that can decide when the task is actually done.

Recommended Articles

• What Are Coding Agents? How They Work and How to Build One
• What Is an AI Agent Sandbox?
• Agent vs Workflow: Key Differences and Practical Trade-Offs