Workflows in 📝MythOS are repeatable agent processes written as memos — what starts one, which memos it must load, and the steps it runs — and they are an upcoming extension of 📝Augmentation, the identity layer your AI already carries into every session. Every agent run drags a payload of context nobody can see, so the same process costs a different amount each time it fires and no one can say afterwards which memos actually arrived; a workflow makes that payload a declared contract, classed by what guarantees each load and measured in tokens and characters before anything runs. It is built for 📝Oracle creators who run the same process often enough that its context and its cost are worth pinning down.
Key Capabilities
- The definition is a memo — no second record, so an agent amends a workflow through the same object it reads
- A declared load contract — every memo a run receives, classed as hook, gate, trigger, or search
- Weight before the run — tokens and characters per memo, per class, per workflow, and across a whole portfolio
- A canvas and a memo view — one definition read either as a step graph or as the document it actually is
- A portfolio dashboard — state, mechanism counts and context weight per workflow, filed into folders and pinned
- Execution arrives with the engine — the surface renders and measures definitions; running them is the next build
Getting Started
Workflows is in build and not yet live on mythos.one. When it opens it will be an Oracle-tier surface reached from the Workflows tab; a workflow is created from a starting template and never fires the moment it exists, so a definition can be read and weighed before it is armed.
FAQ
- How is a workflow different from an ordinary memo? It is an ordinary memo. Marking a memo as a workflow is what puts it on the surface; the trigger, the load contract and the steps are sections in its body.
- What is a load contract? The set of memos a run receives, each classed by what guarantees it: a hook is injected every run, a gate must resolve or the run aborts, a trigger fires on a named condition, and a search retrieves at run time. Only hooks and gates are certain to be there.
- Why does one workflow report two weights? The first is what always lands before step one; the second is the ceiling, adding everything a conditional or retrieved load could add. An uncapped retrieval makes that ceiling unbounded rather than a number.
- Where does the weight come from? It is measured per memo version and cached rather than counted on render, so a portfolio can be sorted by context weight without the cheapest view becoming the most expensive one.
- Do workflows run themselves yet? Not yet. The surface reads, renders, measures and files definitions; the engine that dispatches a trigger and sequences the steps behind it is a separate build.
Related
- 📝Implicit Loading — the sibling mechanism that guarantees your identity context loads before an agent acts
- 📝Semantic Search — the retrieval behind a search-class entry in a load contract