Imagine you order a pizza through an online food delivery application.
You might think:
“I ordered a pizza, the restaurant prepares it, and the delivery person brings it to me. What’s so complicated about that?”
From an AI architecture perspective, this simple example can help us understand some of the most important concepts in Agentic AI:
- Workflow
- Agent
- Tool use
- Agentic loops
- Orchestration
- Task decomposition
- Reliability guardrails
- Human-in-the-loop
Let’s start with the simplest version.
Step 1: A Simple Workflow
Suppose our pizza application follows a fixed process:
Customer places order
↓
Check restaurant
↓
Confirm order
↓
Prepare pizza
↓
Assign delivery person
↓
Deliver pizza
↓
Order completed
The sequence is already known.
The application doesn’t need AI to decide what the next step should be.
The developer has written the logic:
if order_created:
confirm_order()
if order_confirmed:
prepare_order()
if order_ready:
assign_delivery()
if delivered:
close_order()
This is a workflow.
The important idea
The developer controls the sequence.
The workflow may still use an LLM.
For example, the customer might type:
“I want a large vegetarian pizza without onions.”
Claude could understand the request and convert it into structured data:
{
"size": "large",
"type": "vegetarian",
"remove": ["onions"]
}
But after that, the application still controls the workflow.
So:
LLM ≠ Agent
An application can use an LLM and still be a normal workflow.
Step 2: Now Let’s Make It Agentic
Let’s change the requirement.
Suppose the customer says:
“Find me the best pizza available within 30 minutes and under ₹500.”
Now things become interesting.
The application doesn’t know exactly what it should do.
The AI might need to:
Understand request
↓
Search restaurants
↓
Check delivery time
↓
Check prices
↓
Compare options
↓
Choose the best option
↓
Place order
But what if the first restaurant doesn’t meet the requirements?
The AI might decide:
Restaurant A
↓
₹650 → Too expensive
↓
Search Restaurant B
↓
₹450 → Good
↓
Delivery = 25 minutes
↓
Choose Restaurant B
Here the AI is deciding what to do based on what it observes.
That’s an agent.
The key difference
In the workflow:
Developer decides what happens next.
In the agent:
The AI can decide what action to take next.
Step 3: The Agent Uses Tools
An agent usually doesn’t operate in isolation.
It can use tools.
For our pizza example, the agent might have access to:
Search Restaurants
Check Menu
Check Price
Check Delivery Time
Place Order
Cancel Order
The interaction could look like:
Customer
↓
Agent
↓
Search Restaurants
↓
Results
↓
Agent evaluates results
↓
Check Restaurant A
↓
Agent evaluates
↓
Check Restaurant B
↓
Agent evaluates
↓
Place Order
This is where tool use becomes important.
The model isn’t directly accessing your database or external service by magic.
Your application provides tools that the model can request.
Step 4: What Is an Agentic Loop?
Now imagine the agent keeps evaluating results.
┌───────────────┐
│ Agent │
└───────┬───────┘
↓
Use Tool
↓
Result
↓
Evaluate Result
↓
Is goal achieved?
↙ ↘
YES NO
↓ ↓
Done Use another tool
↓
Result
↓
Agent
This is an agentic loop.
The agent:
- Reasons
- Chooses an action
- Uses a tool
- Observes the result
- Reasons again
- Chooses the next action
- Continues until the goal is achieved
Step 5: What Happens If the Agent Gets Stuck?
Imagine the customer asks:
“Find the cheapest pizza under ₹300.”
The agent searches.
Restaurant A → ₹350
Restaurant B → ₹400
Restaurant C → ₹320
Nothing meets the requirement.
A badly designed agent might continue searching forever:
Search
↓
Search again
↓
Search again
↓
Search again
↓
Search again
↓
...
That’s dangerous.
It can create:
- High API costs
- Long response times
- Excessive tool calls
- Potential infinite loops
Therefore, the application needs guardrails.
For example:
Maximum searches = 5
After five attempts:
No suitable restaurant found
↓
Inform customer
Or:
No suitable restaurant found
↓
Ask customer:
"Would you like to increase your budget?"
This is an important principle:
Agent autonomy must have controlled boundaries.
Step 6: What If We Have a Huge Task?
Now imagine the application isn’t just finding a pizza.
It has to plan a complete party:
“I’m hosting a party for 50 people. Find food, drinks, decorations, music and transportation.”
That’s a much larger task.
Instead of asking one agent to do everything, we could have an orchestrator.
Orchestrator
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Food Agent Decoration Agent Transport Agent
│ │ │
└──────────────┼──────────────┘
↓
Final Plan
The orchestrator coordinates the work.
Each worker focuses on a specific problem.
This is the orchestrator-worker pattern.
Step 7: Task Decomposition
We have now broken one large problem into smaller tasks:
Party Planning
│
├── Food
├── Decorations
├── Transportation
└── Music
This is task decomposition.
But decomposition has to be done carefully.
If we split the work too much:
Find pizza size
Find pizza price
Find pizza toppings
Find restaurant name
Find delivery time
...
we create unnecessary calls and overhead.
If we don’t split enough:
One giant agent
↓
Do everything
the task becomes difficult to control and debug.
The ideal approach is to split work at natural failure boundaries.
For example:
Food planning can fail independently from transportation planning.
Therefore, those are good candidates for separate workers.
Step 8: Reliability Guardrails
Now let’s introduce another important concept.
Suppose the AI says:
“Restaurant B has a 25-minute delivery time.”
But the restaurant API actually returned:
{
"deliveryTime": null
}
The AI should not invent a value.
A reliable system should preserve uncertainty:
{
"deliveryTime": null
}
rather than:
{
"deliveryTime": 25
}
The principle is:
If the information isn’t available, don’t make it up.
Step 9: Human-in-the-Loop
Suppose the AI is about to place a ₹25,000 catering order.
You probably don’t want the AI to make that decision without confirmation.
The architecture could be:
AI selects catering option
↓
Price = ₹25,000
↓
Human approval required
↓
User approves
↓
Place order
This is Human-in-the-Loop (HITL).
The important point is that human review should be an explicit part of the system, not:
“Someone will check it later.”
Step 10: Now Apply the Same Thinking to a DRHP Application
The same concepts apply to a financial document extraction application.
A simple DRHP application could be:
DRHP
↓
Claude
↓
Structured JSON
↓
Validate
↓
Database
↓
Admin Review
↓
Publish
This is a workflow.
Claude is being used for extraction, but the application controls the sequence.
If we change the requirement to:
Extract peer data
↓
Is information complete?
↓
NO
↓
Search web
↓
Is source reliable?
↙ ↘
YES NO
↓ ↓
Continue Try another source
↓
Still uncertain?
↓
Human Review
we have introduced agentic behavior.
And if the DRHP is 500 pages, we might use:
Orchestrator
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Financials Peer Comparison Risks
Worker Worker Worker
│ │ │
└──────────────┼──────────────┘
↓
Final Result
Now we have orchestrator-worker architecture.
The One Mental Model to Remember
If you remember only one thing from this article, remember this:
KNOWN PATH
↓
WORKFLOW
UNKNOWN / DYNAMIC PATH
↓
AGENT
LARGE INDEPENDENT TASKS
↓
ORCHESTRATOR + WORKERS
POSSIBLE FAILURE
↓
VALIDATION + GUARDRAILS
UNCERTAIN INFORMATION
↓
DON'T GUESS
AGENTIC LOOP
↓
MUST HAVE STOPPING CONDITIONS
This mental model is much more useful than memorizing definitions.
Final Takeaway
Agentic AI is not about making every application autonomous.
In fact, one of the most important architectural skills is knowing when not to use an agent.
If your process is predictable, a workflow is often the best solution.
If the AI needs to dynamically decide what action to take next, an agent may be appropriate.
If the problem is large and naturally separable, an orchestrator-worker architecture may be useful.
And regardless of which architecture you choose, production AI systems need reliability mechanisms such as validation, controlled retries, human approval, uncertainty handling, and stopping conditions.
The golden rule is:
Use the simplest architecture that reliably solves the problem.
That is the mindset an AI architect — and someone preparing for an agentic AI certification — should develop.
AI Disclaimer
This article was generated with the help of AI and is intended for educational and informational purposes. Concepts and examples should be validated against the latest official Claude/Anthropic documentation and applicable certification requirements before being used for production architecture or examination preparation.