Where AI Belongs in an Automated Workflow

A parent asking, “How much do I still owe?” creates several different problems.

The system needs to understand the message, identify the parent, determine which student they mean, verify that the parent is allowed to access that student’s information, and retrieve the correct balance. Those steps should not all be delegated to one model prompt.

Language interpretation is a useful place for AI. Identity, authorization, database access, and arithmetic require explicit application rules.

My Secure AI WhatsApp Assistant connects these concerns through an intent-routing workflow. The model helps classify what the parent is asking, while structured records handle student information and a retrieval system supports questions about school policies.

Anthropic distinguishes predefined workflows from agents that dynamically direct their own processes and tools. That distinction provides a useful architectural rule: use a controlled sequence when the process is known, and introduce model-directed decisions only where flexibility is valuable.

For a fee request, the model can identify the intent and detect missing information. The application must then resolve the authenticated user’s permitted student records and apply that scope to the database query.

A student identifier supplied in a message must never become proof of access.

An OTP verifies control of a phone number or destination. It does not establish that the person controlling that number has permission to access every student record. That relationship must come from trusted enrollment data or a verified enrollment process.

This distinction is easy to miss when designing the happy path.

The response must also preserve the meaning of the underlying data. “No record found” is different from “zero balance.” A fluent answer that erases that distinction can mislead the parent even when the system appears to be working.

Different questions need different retrieval paths.

A balance or attendance request should use a deterministic query against an authorized student record. A question about admissions requirements or school policies can use retrieval-augmented generation grounded in approved documents.

The model can help select the route, but the application must validate the required fields before executing it.

This gives the model a focused responsibility:

• Interpret the language.
• Return a supported intent.
• Extract the required structured fields.
• Ask for clarification when information is missing.

The surrounding system keeps responsibility for permissions, record selection, database operations, and consequential actions.

Consider three failures:

• The parent has two linked students.
• The database is temporarily unavailable.
• The model classifies a complaint as a balance inquiry.

Each failure needs a different response.

The system should ask the parent to choose a student, report a temporary retrieval problem, or route the message for correction. Sending all three failures through a generic retry would hide what actually went wrong.

This is why I would evaluate authorization separately from response quality.

A useful test set should include:

• Unauthorized requests for another student
• Ambiguous student names
• Missing balance records
• Paraphrased intents
• Prompt-injection attempts
• Requests that fall outside supported categories
• Retrieval results that conflict with generated wording

The logs should preserve the tool result and the final answer so an evaluator can distinguish bad retrieval from bad wording.

Repeating a read is different from repeating a payment, complaint submission, or record update.

If a write request times out, the application should not automatically assume that it failed and execute it again. The operation needs a stable identifier, and the workflow should verify the existing outcome before retrying.

Consequential actions may also require human approval before execution. The approval must refer to a specific proposed action, user, record, and state.

The engineering goal is a system whose decisions can be explained and tested. A model can make the interface flexible while the surrounding application keeps access and actions controlled.