Email and invoice workflows are attractive places to use AI because the repetitive work is obvious. They are also poor places to begin with broad authority. A plausible draft sent to the wrong person cannot be unsent. A financial action against the wrong record creates a second workflow just to repair the first.
The rule is simple: let the agent prepare the work, then ask before anything consequential happens.
Start with the action boundary
A workflow map usually mixes three different kinds of step:
- Reading and organizing information.
- Recommending what should happen next.
- Causing something to happen outside the system.
The third category deserves separate treatment. Sending a message, changing a financial record, or notifying another person has a different consequence from summarizing an inbox.
Mark that boundary before choosing a model or writing a prompt. It tells the team which steps can run quietly and where authorization belongs.
Treat model output as a proposal
A model can draft an email, identify a likely recipient, summarize supporting records, and recommend a next step. None of those outputs should count as permission to act.
That distinction matters when the input itself is untrusted. An email body, attachment, meeting note, or retrieved web page may contain instructions. Those words can inform the proposed response. They should not be able to grant the workflow new authority.
A useful design rule is to make the agent produce a proposal with explicit fields. For an email, those fields might be the sending account, recipient, subject, body, and source record. For an invoice review, they might be the bill, the supporting entries, the proposed transition, and the reason it is ready.
The proposal should be reviewable as data, not buried inside a paragraph that another component must interpret.
Keep execution narrower than generation
The model can write almost anything. The execution layer should be able to do very few things.
Language generation should prepare content and recommendations. Ordinary application code should handle a defined provider operation. Use a small catalog of allowed actions, give each action a narrow input contract, and keep provider credentials inside the application rather than in the prompt.
Adding a new skill should not quietly add a new power. The set of actions should remain visible, reviewable, and testable outside the model's instructions.
Keep the approval control outside generated content
A person should approve the action, not the agent's description of the action.
The review screen should make the proposed recipient, record, and effect visible. Its Send, Approve, or Confirm control should come from application code. Generated content should not be able to add a button, rename the action, or decide which validation rules apply.
When the person acts, check the live record again. A proposal can become stale between preparation and review. The recipient may change, a bill may already be handled, or another process may update the underlying record.
This is the difference between a confirmation dialog and an authorization boundary. The first asks whether a screen looks acceptable. The second verifies whether the specific action is still permitted.
Store enough evidence to explain the action
A consequential workflow should be able to answer five questions:
- What was proposed?
- Which source record produced it?
- Who or what was the target?
- Who authorized it?
- What result came back?
Store the proposal before execution and the result after execution. Provider identifiers, timestamps, and errors belong with the same work record when they are available.
This makes review concrete and retries safer. A person is not approving a vague instruction such as “handle the invoice.” They are authorizing one visible action against one visible record.
Split batch work into individual actions
Batch approval can hide changing scope. A card might say “send the notices” while the implementation loops over a recipient list that changed after the card was prepared.
Prefer one proposed action per target. A review surface can group them for convenience, but each action should retain its own input, result, and completion state.
That structure also makes partial failure easier to handle. If three messages send and a fourth fails, the workflow can retry the failed action without guessing whether the first three should run again.
Put the human only where consequence begins
Human approval is expensive when it is attached to every step. Reading records, classifying routine input, reconciling known fields, and preparing drafts can often run without interruption.
KZN's alerting workflow follows the same broader principle. Specialized jobs collect findings, while a shared attention policy determines what reaches a person. Separating observation from interruption keeps routine work quiet without giving up control over consequential decisions.
Keep the gate for the point where the work becomes outward-facing or difficult to reverse. That preserves the value of automation while keeping the decision with the person accountable for it.
The resulting workflow has a clear division of responsibility:
- The agent gathers context and prepares a proposal.
- The application validates the proposal against an allowed action.
- A person authorizes the exact action when required.
- Deterministic code performs it.
- The result returns to the work record.
Bring one real workflow
If you are deciding where an agent can act inside finance or communications, bring us one real workflow. We will map which steps can run unattended, which need a server-side check, and where a person should make the final call.
Design that action boundary first. It is the difference between an agent that helps with important work and one that merely moves risk faster.