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.
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 reqeusts 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.