Every thunk represents a workflow. It models a business process as a sequence of steps. At runtime, each workflow request will run as a separate workflow instance following the sequence of steps in the plan.
For example, the snapshot below shows the workflow plan for a thunk that automates the approval of expense receipts. It has three steps that form the workflow plan definition. The input to the workflow is an Expense Receipt.
There is nothing particularly “AI” about this linear sequence of steps acting on an input. It is intentionally a deterministic and dependable sequence of steps. The logic of each step itself is described in a flexible way so that an AI agent can intelligently interpret the logic at runtime in order to execute the step. The representation of the overall workflow, the individual steps, and their descriptions is collectively called a “Workflow Plan”.
Steps with AI Instructions
The logic to run each step in the plan is described by "AI Instructions". The AI Instructions are the primary "programming logic" representation for AI in the platform. AI instructions can be very simple — just a few natural language sentences providing instruction, or they could be refined to complex and specific instructions including prompts, examples, input and output state bindings, tool configuration, human-in-the-loop settings, model choices and other configuration options. Read the article on AI Instructions to learn more.
Dividing the work into steps
A good plan follows the stages of the business process, not the mechanics of running it. These rules apply whether you write the plan yourself or Thunk.AI drafts it from your description.
Keep the steps the process already has
If the process already has a list of steps (in an SOP, a checklist or your description), keep those steps: no more and no fewer. Otherwise, divide the work into the stages a person would recognize, usually between 2 and 10.
Make each step one stage of work
Each step is a stage that could be handed to one person: checking an application against the requirements, visiting the site, making the decision. A step that mixes two stages is harder to instruct and harder to check. Many small steps that each do one action make the plan long without making it clearer.
Write each step for every work item
The plan runs once for each work item, so a step says "Check the receipt against the expense policy", not "For each receipt, check it…". This is about the work items themselves; when one work item holds a list (the line items on an invoice), the step's instructions still say "for each line item".
Give each step a short title and a clear description
Title each step in a few words. The description says what the step decides and how: the information it looks at, the choices it can make, what a good result looks like. It describes the work for a person reading the plan, not the software that does it: no pseudo-code and no tool names. You choose the tools when you configure the step, and each step's AI instructions carry the detail; see How to Write Effective AI Instructions.
Leave out what the platform does for you
Do not plan steps for things the platform already handles:
Reading the input. The steps that need the work item's input files and data read them as part of their work, so there is no separate "read the file" step. AI agents read images and documents directly; you do not need an OCR step.
Recording progress. Each step updates the work item's status when it finishes, so there is no step that only records or updates the status.
Storing data. The work item's properties hold the workflow's data, so there is no step that only saves results somewhere.
Workflow State
Each workflow instance may be long-running — it may involve multiple steps, it might have to wait for humans to engage, it may have to handoff work from one person to another person (or their AI agent). As a result, each workflow instance maintains state to capture the progress of the work between steps. The input and output state data for every step is schematized – it has an expected structure. This structured or schematized state definition is an important part of the workflow plan.
If you are familiar with database applications, you might think of each workflow request being associated with a "structured database row" that gradually gets filled in as the workflow process is executed. For example, an expense report approval workflow might have structured state like this:
Input: EmployeeName, ExpenseDate, ExpenseReceipt
Step 1 (“Get Details”): ExpenseTotal, LineItems, Taxes
Step 2 (“Categorization”): ExpenseCategory
Step 3 (“Approval/Rejection”): ApprovalDecision
Each workflow instance is represented by a “row” with 8 properties (EmployeeName, ExpenseDate, ExpenseReceipt, ExpenseTotal, LineItems, Taxes, ExpenseCategory, ApprovalDecision)
More schematization leads to greater AI reliability. The schema or structure of each of these properties is important because it provides important control information to the AI agent. “ExpenseReceipt” is not just any arbitrary data. You may know it will be a link to a file. You might be know that you expect it to be a PDF file. You might know that it contains receipts for expenses in USD. Now, when your AI agent needs to look at and understand a receipt in Step 1, it can do a better job because it knows to expect a PDF file with expenses in a particular currency. Likewise, the ExpenseCategory may not be arbitrary. Your company may have six specific categories and listing those makes the structure much more specific. When your AI agent needs to categorize the expense in Step 2, it will only choose from one of the enumerated categories.
Schematization Elements
Every state property has these different elements of schematization:
Name: always pick a semantically meaningful name for the property. Obscure “internal” names (eg: “Property_123”) cannot be interpreted by the AI agents. On the other hand, a name that appropriately captures what it is supposed to represent (eg: “EmployeeName”) helps steer the work of the AI agent.
Description: The property description is also very important as it is a longer and more detailed way to describe the data that will be persisted in an instance of this property. The description can serve to specialize input properties (eg: “This is a PDF file or 3 or less pages, representing an invoice from one of our Malaysian customers”). It can also serve to constraint the work of the AI agent when it computes and persists output properties (eg: “This property holds the email address of our team sales rep for this customer”.
Type: Just as in a database or project system, each property can have a type (Number, Text, File, Image, etc.). Thunk.AI supports a growing number of property types. By choosing the most appropriate type, the thunk designer steers the AI agents with additional information, controls the updates of the AI agents to fit the type, and influences the UI presentation of data based on the type. A special kind of type is a List type. If a property is specified to be a List of Text, then the state maintained can be more complex with a nested list maintained for this property.
Type Constraints: based on the choice of the type, further type constraints can be specified. For example, a Number can be constrained with min and max values. It is very common for Text to be constrained with a fixed enumeration of allowed values.
Required: One special constraint indicates if the property is required or not. This is relevant for the initial input properties of a workflow request and for the output properties of a workflow step. If one of these properties is marked as “Required”, then it has to be provided in order for work to continue. This becomes an important way to validate the inputs to a workflow, and also to validate if a step has successfully completed.