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.
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, EspenseDate, ExpenseReceipt, ExpenseTotal, LineItems, Taxes, ExpenseCategory, ApprovalDecision)
When you open the “Data” view of the thunk (click on it in the left control pane in the Run section), you will see a familar tabular view of all the running workflow instances. If you move the mouse over the column headers, you will see a properties menu (“three vertical dots”) which allows you to view the Column Properties. This is where you can see and change the definition of each state property, you can add new columns, and you can delete existing columns.
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 EspenseCategory may not be arbitrary. Your company may have six specific categories and listing those makes the structure much more specific. Now when your AI agent needs to categorize the expense in Step 2, it will only choose from one of the enumerated categories.
More schematization leads to greater AI reliability
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.