An agent and a workflow can work together. The useful question is which parts of the job need exact rules and which parts need interpretation.
Calculating a discount is exact work. Explaining why a customer requested it may need judgment. Giving one layer both jobs makes the result harder to check.
At a glance
- Put arithmetic, threshold comparisons, required fields and permissions in code.
- Use the model to read messy material, summarize findings and draft explanations.
- Give consequential decisions a named owner and show them the evidence.
Split the job by what must stay predictable
| Use code for | Use the model for | Keep a person responsible for |
|---|---|---|
| Comparing a discount with approved bands | Summarizing the reason for the request | Approving an exception |
| Finding a stock-count difference | Explaining a possible cause from available notes | Deciding a write-off |
| Detecting an error-rate threshold breach | Preparing an incident summary | Choosing the response |
| Checking a caller's permission | Explaining why a request was refused | Granting or removing access |
The code still needs correct inputs and tests. The model still needs sources and checks. The split makes responsibilities clearer, rather than making either layer infallible.
A discount request makes the boundary visible
Consider an illustrative policy: discounts up to 10 percent need no additional review, above 10 percent and up to 20 percent go to the sales manager, and larger discounts go to the finance director.
Code calculates the discount from the quote and applies the bands. The model receives that result and prepares a brief: the request, relevant account history and any missing information.
It should not reinterpret the band or announce that the discount is approved. The owner takes the next step in the appropriate system.
- Load the quote
- Apply bands in code
- Explain the request
- Owner reviews
A prompt describes a rule without enforcing it
An instruction such as “send discounts above 20 percent to finance” helps the agent understand its job. It does not provide the same guarantee as a comparison performed outside the model.
The same applies to access. Hubzoid checks restricted tools before they run. The model may request a tool, but the permission decision belongs to code and is recorded.
Use plain language to explain the policy and exact logic to enforce it where the outcome depends on a fixed rule. Keep both aligned when the policy changes.
A workflow connects the parts
Hubzoid code workflows can load data, run exact checks and call the model where explanation helps. Completed steps are recorded so the run can resume after a restart.
That does not guarantee an external action happens only once. A step interrupted while creating a ticket, for example, may be attempted again. Check whether the ticket exists or use a deduplication key supported by the receiving system.
The bundled Watchtower example uses this division: code finds a threshold breach and a model explains it. That is a useful pattern for reports containing many ordinary rows and a few exceptions.
Ask two questions before choosing a layer
- Is there an exact rule? A formula, threshold, permission or required field belongs in code.
- Does it require reading context? A summary, comparison or explanation may benefit from the model.
If both answers are yes, combine the layers. Make the handoff explicit: the facts, the rule applied, what the model added, what is missing and who acts next.
Next step: read code workflows for the implementation pattern.
Watch The daily report, episode 7 (opens in a new tab) to see fixed steps combined with an agent.
