Agentic Reliability Modeling

Agentic Flows

In an early tutorial on agents, we designed a simple agent that could classify resumes into “selected” or “rejected.” That worked well for a single decision, but real-world business processes rarely end with one step — they flow.

Let’s take that same resume-classification agent and embed it in a larger, automated workflow: when a candidate’s resume is selected, the system should automatically check for available interview slots and schedule one.

Conceptually, the process might look like this:

resumeReview --> "selected" checkCurrentInterviewSchedule
checkCurrentInterviewSchedule --> scheduleInterview

At a glance, this looks like a high-level flowchart — and that’s exactly what it is. But the beauty of Agentlang is that this isn’t just a diagram — it’s executable logic. Agentlang understands this syntax, orchestrates the agents accordingly, and maintains context across each step.

Visualizing the Flow

To make this even clearer, here’s a textual representation of how the flow works:

┌───────────────┐
│ resumeReview  │
└───────┬───────┘
        │ "selected"
        ▼
┌────────────────────────┐
│ checkCurrentInterview  │
└────────┬───────────────┘
         ▼
┌──────────────────┐
│ scheduleInterview │
└──────────────────┘

This simple diagram illustrates the sequential logic: only resumes marked "selected" by resumeReview move on to checking the interview schedule, and then onward to scheduling.

Defining the Flow in Agentlang

Here’s how the updated hr module might look in practice:

module hr.core
  
entity InterviewSchedule {
    id UUID @id @default(uuid()),
    assignedTo String,
    candidate String,
    interviewDateTime String
}
  
agent resumeReview {
    instruction "Review the resume passed to you, return `selected` if the candidate is a software engineer
with more than 10 years experience, otherwise return `rejected`",
    directives [{"if": "experienced in C++", "then": "selected"},
                {"if": "not hands-on in programming", "then": "rejected"}],
    scenarios  [{"user": "Software engineering manager with 25 years experience", "ai": "rejected"},
                {"user": "C++ programmer with 2 years experience", "ai": "rejected"},
                {"user": "C++ programmer with 12 years experience", "ai": "selected"}],
    glossary [{"name": "developer", "meaning": "software engineer", "synonyms": "programmer"}]
}
  
agent scheduleInterview {
    instruction "Schedule an interview with the candidate. The interviewer must be one of Susan, Joe and Mat.
If the candidate already has an interview scheduled, choose a different interviewer or a later date.
Interview dates start from 15-Oct-2025 between 9AM and 3PM. The current interview schedule (if any)
will be available in the context, so there’s no need to query it explicitly.",
    tools [hr.core/InterviewSchedule]
}
  
event checkCurrentInterviewSchedule { }
  
workflow checkCurrentInterviewSchedule {
    {InterviewSchedule? {}}
}
  
flow processResume {
    resumeReview --> "selected" checkCurrentInterviewSchedule
    checkCurrentInterviewSchedule --> scheduleInterview
}
  
agent processResume {
    role "You are an agent who processes resumes and schedules interviews for selected candidates"
}

Understanding the Flow

The resumeReview agent remains unchanged — it still decides whether a candidate should move forward. But now, it’s part of a flow.

When you invoke the processResume agent, Agentlang automatically detects that it’s linked to a flow of the same name. That means:

1. The agent starts the processResume flow.
2. The flow invokes resumeReview first.
3. If the result is "selected", it moves to the next step: checkCurrentInterviewSchedule.
4. That workflow step queries the InterviewSchedule entity and passes the current data to the next step.
5. Finally, scheduleInterview uses this context to assign the candidate to a free interviewer and persists a new InterviewSchedule entry.

The agents don’t just “call” each other — they collaborate, passing structured context and decisions downstream. Each agent’s reasoning builds on the previous one, forming a transparent, auditable chain of logic — what we call agentic reliability modeling.

Trying It Out

Let’s test the system in action. Run your HR app and send a few resumes to the processResume agent:

curl -X POST http://localhost:8080/hr.core/processResume \
 -H 'Content-Type: application/json' \
 -d '{"message": "name: Tom, languages: C++, years of experience: 12"}'
 
curl -X POST http://localhost:8080/hr.core/processResume \
 -H 'Content-Type: application/json' \
 -d '{"message": "name: Jake, I am a programmer with 23 years experience"}'

If all goes well, the scheduleInterview agent should automatically schedule interview slots for these candidates. You can verify the result by querying the InterviewSchedule entity:

curl -X GET http://localhost:8080/hr.core/InterviewSchedule \
 -H 'Content-Type: application/json'

If you submit a resume that doesn’t meet the criteria — say, a candidate with no programming background — the system will stop after resumeReview, and no interview will be scheduled.

Why It Matters

This example captures the essence of agentic reliability: each step is intelligent on its own, but when composed into a flow, they form a dependable system.

• resumeReview applies human-like reasoning.
• scheduleInterview executes business logic with contextual awareness.
• The flow ties it all together, ensuring that intent, reasoning, and action align perfectly.

Agentic Flows turn ad-hoc AI behavior into predictable, auditable automation, making your AI-driven systems both powerful and trustworthy.

For a deeper dive into designing reliable agents, see First-class Intelligent Agents.