← All insights

Insights

Guided screens or AI agents? Knowing when to use each

We have been adding LLM-powered features to OPAL for some time—from improving job descriptions and scoring CVs to giving recruiters quick answers on mobile.

One question keeps coming up: shouldn’t all of this just be an AI agent?

Sometimes, yes. But not always.

The mistake is to treat an agent as the natural upgrade from forms and buttons, as though every product should eventually become a chat box. In reality, guided workflows and agents solve different problems. The right choice depends on how predictable the task is, how much freedom the user needs and how much control the business must retain.

First, a useful distinction

A guided workflow puts the path on the screen. The user moves through a known sequence: review a rough job description, clarify the requirements, approve the final JD and generate a scoring rubric. The product makes the process visible and guides the user through it.

An AI agent is given more discretion. The user states a goal, and the system decides which tools to use, what order to use them in and whether it needs more information before continuing.

These are not complete opposites. A guided screen can use agentic orchestration behind the scenes, and an agent can present buttons, forms and approval steps. LangGraph itself supports both predetermined workflows and dynamic agents, including combinations of deterministic and model-driven steps.

So the real decision is not simply buttons or chat. It is: how much freedom should the system have, and how much structure does the user need?

The user’s confidence with the task matters

People often say agents are for advanced users and guided screens are for beginners. There is some truth in that, but it is not the whole story.

A recruiter who understands the role, the client and the hiring process may be comfortable asking an agent to compare candidates or investigate why a role is taking too long to fill. Someone handling an unfamiliar role may not yet know which questions to ask—or what a good answer should contain.

That is why OPAL’s Job Clarity process remains guided. A recruiter starts with the client’s rough JD, reviews the requirements, resolves ambiguity, approves the final job description and then creates the scoring rubric. The system helps at every stage, but a person remains responsible for what is finally approved.

A blank chat box would offer more freedom, but it could also hide important decisions. A polished-looking JD is not necessarily an accurate one.

There is another point that is easy to miss: experienced users also value guided workflows when the task is repetitive. They do not necessarily want to prompt an agent every time they create a role or review a candidate. Sometimes the fastest experience is simply a well-designed screen with the right defaults.

The better rule is this: use guidance when consistency matters; use flexibility when the path genuinely varies.

A little like SQL—although not exactly

There was a time when being able to write SQL separated people who could retrieve their own answers from those who depended on reports, spreadsheets or an IT team.

Agents create a similar advantage for people who are comfortable expressing a goal, checking the response and adjusting their request. But most business users should not have to learn “prompt craft” just to complete a routine process correctly.

That is why we do not see this as a choice between one type of user and another. We prefer a guided experience by default, with agent-style access available when exploration and flexibility add real value.

Speed and cost

Agents are often assumed to be faster because they appear more intelligent. That is not automatically true.

A guided action can trigger one focused model call or a carefully controlled sequence. An agent may need to plan, call several tools, inspect the results, retry and ask a follow-up question. Every additional step can add latency and cost.

However, the opposite can also be true. If a person would otherwise move between several systems, gather information manually and interpret it, an agent may complete the overall task much faster—even if the agent makes more model calls.

The comparison should therefore be based on the whole task, not just the number of LLM calls.

For high-volume recruitment activities, such as processing many JDs or CVs, we favour structured pipelines with validated outputs, evidence and clear review points. Agentic exploration is better reserved for lower-frequency questions where the route is less predictable, such as:

  • Why are several roles for this client still open?
  • Which candidates in our database may fit this new requirement?
  • What has changed across this week’s hiring pipeline?

In short, use agents where their flexibility is worth the additional variability.

Operations, control and trust

A failed “Save JD” action is usually easy to understand and reproduce. A failed agent run can be harder to diagnose. Which tool was called? What information did it receive? Why did it retry? Was it waiting for approval? Did it attempt to write to another system?

This does not make agents unsuitable for business use. It means they need stronger operational controls:

  • Clear tool permissions and allowlists
  • Full tracing of decisions and tool calls
  • Structured and validated outputs
  • Limits on retries, time and cost
  • Human approval before consequential actions
  • Safe recovery when a run is interrupted or fails

This is where an orchestration framework such as LangGraph can help. Its strengths include persistent state, pause-and-resume execution and human-in-the-loop approvals. But choosing LangGraph is an architecture decision; it does not mean the product must become a chatbot.

We also prefer to begin with read-only access. An agent that can explain what is happening across jobs and candidates is useful. An agent that can reject a candidate, change a job requirement or submit a CV needs a much higher level of control and human approval.

Agents also expose the quality of the systems behind them. Poorly defined APIs and overly broad tools become even riskier when an agent can call them autonomously. Narrow, well-designed tools are usually safer and easier to test than one powerful “do everything” function.

When an agent genuinely helps

An agent is a good fit when:

  • The goal is clear, but the route to reach it may change
  • The task requires information from several systems
  • The user may need to investigate, refine and compare
  • The work must pause for input or approval and resume later
  • The value of flexibility is greater than the need for completely predictable execution

A guided workflow is usually better when:

  • The process is known and repeated frequently
  • Every user must follow the same critical steps
  • New team members need to succeed quickly
  • Cost, latency and output format must remain predictable
  • The action has significant consequences and requires explicit review

A useful rule of thumb: if the normal path can be drawn clearly in a few boxes, start with the boxes. If the next step regularly depends on context, investigation or judgment, an agent may add value.

How we apply this in OPAL

Our direction for OPAL is deliberately hybrid:

  • Guided workflows for everyday recruitment operations. This includes clarifying job requirements, finalising JDs, creating scoring rubrics, managing open roles and reviewing scored candidates.
  • Structured AI pipelines for high-volume processing. CV scoring should produce validated results, evidence for each score and clear recruiter review—not an unpredictable conversation.
  • Short mobile answers with tappable actions. On a phone, users should not have to invent the perfect prompt just to find a job, check a candidate or review an alert.
  • Read-first agent access for investigation and exploration. Experienced users can ask questions across jobs, candidates and hiring activity, while tools remain carefully scoped.
  • Human approval for consequential decisions. Shortlisting, rejection and submission should remain controlled actions, regardless of whether the recommendation comes through a screen or an agent.

The same trusted data and capabilities can support both experiences. What changes is the amount of freedom given to the system and the amount of guidance provided to the user.

Before adding an agent

Ask five questions:

  1. Is the normal path already known? If yes, begin with a guided workflow.
  2. Can someone complete the task successfully without knowing how to prompt? If not, add more guidance.
  3. Does the route genuinely change based on what the system discovers? If yes, an agent may help.
  4. Will the process need to pause for review or approval and resume later? If yes, agent orchestration may fit.
  5. Can the underlying capability first be exposed as a safe, well-defined tool? If yes, build that foundation before adding open-ended chat.

Agentic AI is not a maturity badge, and guided screens are not old-fashioned. A good guided workflow captures expertise and makes the right process easier to follow. A good agent provides flexibility when the work cannot be reduced to a fixed path.

The strongest products will use both. They will guide users through routine, high-stakes work and provide agentic support where investigation, judgment and cross-system action genuinely help.

The aim is not to make every task feel like a conversation. It is to give each user the right amount of structure, freedom and control for the job in front of them.