Even outside of the AI space, many infrastructure systems try to separate the "execution state" from the "business state". For AI applications, this can involve complex abstractions to keep track of information such as current step, next step, wait status, retries, and so on. This separation introduces complexity, and while it may be worthwhile, it may be too small for your use case.
As always, you'll need to decide for yourself what's right for your app. But don't assume that younecessarilyManage them separately.
More clearly:
- execution status (computing): current step, next step, wait status, retry count, etc.
- operational state: What has happened so far in the Intelligentsia workflow (e.g., OpenAI message lists, tool calls, and result lists, etc.).
If possible, simplify - harmonize the two as much as possible.
In fact, you can design your application so that it can infer all execution states from the context window. In many cases, the execution state (current step, wait state, etc.) is just metadata about what has happened so far.
You may have some things that won't fit into the context window, such as session IDs, password contexts, etc., but your goal should be to minimize those things. By adopting the Element 3, you can control what is actually fed into the big language model.
There are several advantages to this approach:
- simplicity: the only true source of all states
- serialize: threads can be easily serialized/deserialized
- adjust components during testing: The entire history at a glance
- dexterity: Easily add a new state by simply adding a new event type
- resumption: Recover from any point by simply loading the thread!
- stellate: threads can be forked at any point by copying a subset of the threads into a new context/state ID
- Human-computer interface and observability: Easily convert threads into human-readable Markdown or rich web application UIs!
English 
简体中文 
日本語 
Deutsch 
Português do Brasil