Some agent jobs start with a specific input. Some start with a question in plain language. Others start when a clock or event fires. Those differences determine what a useful answer looks like and what can go wrong.
Choose the shape of the work before choosing the interface.
At a glance
- A task agent needs clear inputs and a predictable output structure.
- A question-answering agent needs current sources, follow-up questions and honest limits.
- Background work needs a trigger, a run record and a plan for failure or repetition.
Choose by how the work starts
| Shape | Example | What it needs most |
|---|---|---|
| Specific task | Check this invoice against its purchase order | Named inputs and an agreed result format |
| Question-answering | What is our current returns policy? | Relevant knowledge and a source for the answer |
| Background work | Prepare the report every weekday morning | A schedule, bounded runs and an owner |
These are useful patterns, not mutually exclusive product categories. A chat can request an invoice check. A workflow can use an agent to explain exceptions. A connected assistant can do either through MCP.
Specific tasks need a contract
A useful invoice check says what it expects: an invoice, a purchase order and the current matching rules. It returns matched lines, mismatches and any missing document.
Use code for exact comparisons and arithmetic. If the model interprets messy text, check its extraction before treating it as fact. A fixed output format does not make every model-generated value deterministic.
If the result feeds another process, validate the structure and give failures their own explicit outcome. A paragraph that looks convincing is not a reliable contract.
Questions need sources and room to clarify
People ask policy questions in many forms. A useful chat agent finds the current policy, names the source and asks a follow-up when the answer depends on missing details.
For example, a returns question may need the purchase date, product condition or account type. Guessing those details can change the answer.
Test the refusal too. Ask for a metric the Hub does not hold and check that the agent states what is missing instead of estimating it from unrelated data.
Background work needs a failure plan
When nobody is watching, a duplicate report or silent failure can go unnoticed for days. Decide:
- What starts the work and which timezone applies?
- Which account does the run act as, and what may it access?
- Where does the result appear and who reviews it?
- What happens if an input fails or the process restarts?
- Could repeating a step send a second message or change a record twice?
Hubzoid supports plain-language scheduled tasks and code workflows. Use a task for a job you can describe as instructions. Use a code workflow where exact steps, thresholds or timing need more control.
Finished workflow steps can be restored after a restart. An interrupted step may run again, so external actions need their own protection against duplicates.
Three ways into the same Hub
Hubzoid's chat, workflows and connected assistants are ways to use the shared foundation. They are not a one-to-one mapping to the three job shapes above.
A teammate can ask for the stock position in chat. A scheduled workflow can produce the daily stock report. Someone's own assistant can request the same definitions and stock tool through MCP. Relevant context is reused while access and conversation history keep their own boundaries.
Next step: choose one job and write its input, output, trigger and failure behavior. Then compare workflows and schedules.
Watch Three types of AI agents, one brain, episode 4 (opens in a new tab) for the three Hubzoid experiences.