Building a Visa Processing Agent in 15 Minutes

Visa processing is one of those workflows that sounds simple until you are in it. Five documents, a dozen cross-checks, edge cases around group bookings and connecting flights, and the whole thing needs to feel coherent from the applicant's perspective. At most embassies, a human officer spends 20 to 40 minutes per application doing exactly this work.

In this post I am going to walk you through the Thailand tourist visa agent we built for Indian passport holders. The agent handles the full applicant interaction — greeting, document collection, verification, fraud detection, and decision recommendation. No code was written for it. It exists entirely as a configuration, and you can build something like it in about 15 minutes.

What Intelligent Agents Are

Before getting into the specifics of the visa agent, it helps to understand what agents in 9thSense actually are.

An intelligent agent is a verification workflow defined in configuration. You specify what documents it needs to collect, what business rules must pass before the workflow completes, what happens when a rule fails, how the agent should communicate, and what fraud checks should run. The platform handles everything else: collecting documents from applicants, routing them through the appropriate extraction and validation pipeline, evaluating your rules against the extracted data, managing retries, and guiding the applicant toward completion.

The agent is not an LLM doing freeform reasoning. It is a structured workflow with well-defined rules, where the LLM plays a specific role: communicating naturally with the applicant, handling flexible inputs like informal document descriptions, and making judgment calls on ambiguous cases where rigid string matching would fail. The business rules are yours. The platform enforces them.

The Visa Agent: What It Does

The Thailand tourist visa agent — let us call her Maya, which is the name we gave her — handles the complete application flow for Indian passport holders.

Maya greets the applicant in character as a visa processing officer. She explains what documents are needed, in what format, and what the requirements are. The greeting is warm, professional, and specific — not a generic "please upload your documents."

She collects five document types in any order: an Indian passport (biographical data page), an outbound flight ticket to Thailand, a return flight ticket back to India, a hotel booking confirmation in Thailand, and a recent bank statement. Because the platform handles automatic document classification, applicants can upload in any order and do not need to tell the system what they are submitting — Maya identifies the document type and acknowledges it appropriately.

She extracts and verifies each document. As each document arrives, the platform extracts its structured fields. Maya confirms what she has found in natural language — "Your passport is valid until November 2029" — without exposing any field names, internal identifiers, or system details to the applicant.

She enforces business rules. Two categories of rules govern the application. Hard rules are absolute requirements: if a rule fails, the application cannot proceed regardless of other documents or arguments. Only Indian nationals qualify for this visa pathway — if the passport shows a different nationality, the application is terminated immediately. The passport must have at least six months of remaining validity — if it does not, the application stops and the applicant is directed to renew before reapplying.

Soft rules allow for remediation. The bank statement must show sufficient funds. If it does not, Maya explains what is required and gives the applicant a limited number of opportunities to submit a different statement. The applicant might have funds in a second account, or might need to provide a more recent statement. Unlike a nationality mismatch — which has no legitimate workaround — insufficient funds is a condition that can be genuinely resolved.

She cross-validates documents against each other. The name on the hotel booking must match the name on the passport. The hotel check-in date must fall on or after the outbound flight departure date. The return flight must be scheduled on or after the hotel checkout date. These consistency checks catch both honest errors and application inconsistencies that a human officer would catch.

Name matching is handled intelligently. A passport showing "SHARMA PRIYA KAVITHA" and a hotel booking showing "Priya Sharma" are the same person — the agent understands name equivalence, including format variations, capitalization differences, and omitted middle names. A rigid string comparison would fail this incorrectly.

Flight ticket destination handling also uses intelligent interpretation. A ticket routing through Kuala Lumpur on the way to Bangkok is a Bangkok ticket. The agent understands that transit cities are not destinations. This matters for real-world itineraries, which often involve connections.

She runs fraud detection automatically. Once all five documents are submitted and all business rules pass, Shield Sense runs fraud checks without any action required from the applicant. Maya informs the applicant that final security checks are in progress. If fraud checks detect issues, they are handled as configured — with appropriate messaging that does not reveal what the detection system found or what thresholds it uses.

She delivers a decision recommendation. When the application is complete and all checks have passed, Maya presents a natural-language summary of the verified information and issues a recommendation. The recommendation goes to an officer for final approval — the agent does not make autonomous decisions, it produces a well-documented recommendation that a human can act on quickly.

How Rules Work

The business logic in an agent is expressed as a set of rules, each with a type and a consequence.

Some rules are hard stops. When a hard-stop rule fails, the workflow ends. The agent explains what failed in plain language and does not offer a retry path. Hard stops are appropriate for eligibility criteria that have no legitimate exception — wrong nationality, invalid document, expired passport. Giving an applicant multiple attempts at a hard stop serves no purpose and creates noise.

Other rules are managed failures. When these fail, the agent explains what is needed and the applicant can try again, up to a configured limit. Managed failures are appropriate for conditions that can be genuinely remediated — insufficient funds, a statement that is too old, a document with missing information that a fresh submission might resolve.

The right choice between hard stop and managed failure depends on the nature of the rule. Fraud detection checks are hard stops — there is no legitimate reason for a genuine applicant to fail deepfake detection repeatedly. Financial sufficiency checks allow retries — a legitimate applicant may simply have submitted the wrong statement first.

This structure — clear rule types, clear failure modes, configured retry limits — is what allows an agent to handle exceptions gracefully without requiring custom code for each scenario.

The Configuration Insight

The entire Maya agent — the persona, the greeting, the document requirements, the business rules, the cross-document checks, the retry configuration, the fraud detection policy — is a single configuration object. There is no code.

This is the practical implication of a platform designed around configuration. A visa processing agent and a merchant KYC agent and a loan origination agent are the same underlying machinery. What makes them different is what you put in the configuration: which document types you require, what your business rules say, what the agent's communication style is.

If you want to build a similar agent for UAE golden visa applications, you define your document requirements for that application type, write the eligibility rules that apply, specify your fraud detection requirements, and create the agent. The platform handles orchestration, extraction, rule evaluation, retry management, and conversation. You do not touch any of that.

The iteration speed this enables is significant. When a compliance rule changes — a new minimum balance requirement, a passport validity threshold update, an additional document requirement — you update the configuration. No deployment. No engineering sprint. The change takes effect immediately.

What an Agent Is Not

It is worth being explicit about what agents in 9thSense are not, because the category overlaps with other things in the market.

They are not chatbots. A chatbot is primarily a conversation interface. An agent is primarily a workflow with a conversation interface as one of its components.

They are not autonomous decision-makers. Agents produce recommendations backed by documented evidence — extracted fields, rule pass/fail results, fraud check verdicts. The final decision remains with a human or a downstream system. The agent's job is to produce a well-substantiated, complete, auditable package that makes the human decision fast and confident.

They are not LLM prompt chains. The business rules are explicit and configured, not inferred by the model. The LLM in a Level 2 agent handles communication, handles ambiguous inputs, and handles judgment calls the rule system cannot express cleanly. It does not invent the rules or override them.

Getting Started

If you want to build a verification agent, the starting point is defining what you need it to collect, what rules the completed submission must satisfy, and what the failure behavior should be for each rule.

Those three things are the core of every agent configuration. Everything else — the communication, the orchestration, the extraction, the fraud detection — the platform provides.

The Thailand visa example described in this post is a complete working configuration. The document types it uses — passport, flight ticket, hotel booking, bank statement — are all in the built-in library. The rule types it uses — field checks, date comparisons, cross-document name matching — are all available in the agent framework. There is nothing custom here. It is built entirely from the platform's standard capabilities, configured for a specific use case.

That is the point. The specific use case is yours. The platform is the machinery underneath it.

Agent docs → | Get API access →