Workflow architecture
When should a recurring task become a workflow?
Repetition is a useful signal. Stable inputs, explicit decisions, and known failure handling determine what is ready to automate.
Repeating a task does not make it predictable
A weekly report may use the same name every week while its inputs, definitions, and exceptions continue to change. A person resolves those differences almost unconsciously. Turning the task into a scheduled process before making those decisions explicit can automate an assumption the team never agreed to.
Proto supports several ways to handle repeat work. You can run a task with current context, save a process as a skill, or build an ERP•AI app and workflow. The right choice depends on where the work runs and how much of it has become stable.
Three different forms of reuse
| Form | What you reuse | When it is useful |
|---|---|---|
| Agent task | The goal and the current evidence | Inputs vary or investigation is still required |
| Skill | Instructions, conventions, and an expected output | The method repeats but needs context and judgment on each run |
| ERP•AI workflow | A configured process with a schedule or record-change trigger | Inputs, actions, and exception handling are sufficiently defined |
A skill makes instructions available for future tasks. It does not by itself establish a scheduled service. Likewise, a desktop task using local files and a signed-in browser is not equivalent to a workflow executing in ERP•AI. Decide which environment owns each step before deciding how it will be triggered.
Extract the stable core
Take an illustrative weekly inventory review. Reading a current export and checking its columns may be repeatable. Resolving a new item-code convention may require investigation. Calculating coverage can be defined precisely, while deciding whether to expedite an order may remain a planner’s decision.
Write down the input contract: required fields, record identity, time window, acceptable freshness, and treatment of missing values. Then write the output contract: calculations, affected records, supporting evidence, and conditions under which no action should occur. These contracts expose what a person currently supplies between the lines.
Design the failure path before the schedule
Ask what happens when the source is empty, a credential expires, or the same input arrives twice. Identify who owns a failure and what evidence they need to investigate it. If an action can create a duplicate message or record, establish how the surrounding system will identify work already performed.
These are architecture questions to verify in your implementation, not blanket guarantees about Proto or every workflow it creates. The ERP•AI integration guide describes the product boundary. Confirm available controls in the actual app and workflow before relying on them operationally.
Keep the first version in draft
Proto can build ERP•AI workflows, test the saved version with representative trigger data, and switch on a trigger-driven workflow when the test passes. If you want a review stage, explicitly ask for a draft that stays off. While inactive, the test previews intended changes and sends. It does not prove a live external effect or cover every later record.
Review the trigger, selected records, destination, and side effects. Exercise a representative normal case and a case that should produce no action. Inspect the preview’s intended effects; after activation, verify a real run in the destination system. For work that remains partly manual, define a clear handoff to the responsible person.
Promote only what has earned repetition
Keep exploratory steps as agent tasks until their rules settle. Use a skill to capture a method that benefits from consistent instructions. Move stable, understood work into an ERP•AI workflow when its operating owner can explain both the normal path and what happens when it fails. The result is a process that remains understandable as its frequency increases.