How should I structure a workflow that combines an LLM with multiple APIs?

I'm working on an application where users interact with the system using natural language, and the application needs to perform multi-step operations through several APIs.

For example, a user might say:

"I'd like to schedule an appointment next week."

The system needs to understand the request, collect any missing information, check available time slots through an API, apply some business rules, and then create the appointment.

I'm currently thinking about separating the system into a few layers:

• An LLM for understanding the user's request
• A workflow layer for managing the steps
• Application code for validation and business rules
• API adapters for communicating with external services

The part I'm unsure about is how much responsibility should be given to the LLM.

My initial idea is to have the LLM return structured information such as:

{
  "intent": "schedule",
  "date": "...",
  "time": "...",
  "type": "..."
}

The application would then validate this data and decide which operations are actually allowed. The LLM would never directly execute an external API operation.

For longer workflows, I also need to deal with things such as:

• Maintaining state between steps
• API timeouts and retries
• Avoiding duplicate operations
• Handling partially completed workflows
• Validating data returned by external services
• Allowing a user to change their request midway through a workflow
• Logging actions for debugging

What architecture or design patterns would be appropriate for this type of system?

Would it be better to implement the workflow using a state machine, a workflow engine, or ordinary application services?

I'm particularly interested in approaches that keep the LLM loosely coupled from the business logic and make the overall workflow easy to test without relying on the LLM.