Skip to content
Coral Garden Software Coral Garden Email us
← Blog

What makes up an AI workflow

· 8 minute read

In this article

An AI assistant can know how to write a good invoice reminder and still send the wrong one. The amount may have changed since the draft was written. The customer may have raised a dispute. The person who asked for the draft may never have authorised it to be sent.

When I think through work like this, I want to be able to describe those responsibilities separately. A procedure tells the assistant how to write the reminder. The accounts supply the current balance. Permission to send it comes from the person responsible for the account.

I've been working with eight building blocks for this: Intent, Knowledge, Instructions, Tools, Work state, Artifacts, Checks and Authority.

The example throughout this post is an overdue invoice, INV-1042, for £1,200. The customer pays £400, then disputes the remaining £800. An assistant is helping with the reminders.

How the parts work together

The executor uses the intended outcome, available information, instructions and current state to propose its next action. Before the action happens, code outside the model checks whether the preconditions hold and whether the action is permitted. It also checks where the proposed arguments came from.

Afterwards, the workflow needs to establish what happened. The result becomes evidence, and the work state changes to reflect it. If there is more to do, the next step starts from that updated state.

Intent, Knowledge, Instructions and Work state provide context to the executor. It proposes an action with provenance for each argument. An action gate checks preconditions, provenance and authority, then allows, blocks or waits for approval. Allowed actions run through Tools with a durable operation ID. Checks establish the result, which produces Artifacts and updated Work state. Continuing work returns to the executor; promoting an artifact to Knowledge or Instructions returns through the action gate.
Open the flow diagram at full size

The eight parts

Intent

Intent describes what should become true, the scope of the work and how to know it is finished.

For INV-1042, the intent is to resolve the correct outstanding balance. That might finish with the accounts showing it paid, or with the owner deciding how to close the dispute. Sending a reminder is a step towards that outcome.

Knowledge

Knowledge is the information available to the system: facts, records, sources and relevant preferences. It needs provenance and freshness, so the assistant can tell where something came from and whether it is still current.

The accounts record an £800 balance. The customer's email says the balance is disputed. Both matter, but they establish different things. The email is evidence of the customer's position; the recorded balance still comes from the accounts.

Instructions

Instructions describe how the work should be done. They include procedures, conventions and examples.

The collections procedure might call for a polite tone, the invoice number in every message and seven days between reminders. It can also describe how to prepare a credit note. Permission to issue that credit note belongs under Authority.

Tools

Tools are the operations the system can perform. Reading an invoice, drafting a reminder and sending an email are separate capabilities.

Each needs a clear description of its effects. A draft can be changed before anyone sees it. Once an email has been delivered, editing the draft will not change what the recipient received. That difference matters when deciding how the workflow should handle mistakes.

Work state

Work state describes where matters stand now. I find it useful to distinguish three kinds, because they have different owners.

The accounting system owns the business state: £800 remains outstanding. The workflow owns the execution state: the reminder is paused. The owner has a decision to make about the dispute. Recording only “waiting” would lose the information needed to continue.

Artifacts

Artifacts are the things the work produces: notes, drafts, reports, code, receipts and other evidence.

The reminder draft quotes £800. The payment receipt records the £400 already received. Their status matters when reviewing the work. The draft shows what was prepared; it does not establish that a message was sent.

Checks

Checks establish whether the work is acceptable, before and after an action. Depending on the task, that can involve tests, citations, reconciliation or review.

Before sending the reminder, check the current balance and whether the dispute prevents it from going out. After sending, record the result. AI review can help assess a draft, but the software carrying out the action must enforce the limits on what it may do.

Authority

Authority describes what the system may decide or change, and on whose behalf. It includes delegated permissions, limits and actions that require approval.

The owner may have delegated routine reminders while reserving credit notes for a separate decision. The assistant can know the procedure and have access to the tool without having permission to issue one. I want that distinction to be explicit before the workflow reaches the action.

Giving permission without approving every step

A useful assistant needs room to carry out the work it has been given. Asking the owner to approve every routine reminder would add another recurring job to their day. The delegation can instead describe a bounded set of actions that the software permits.

For the invoice example, that could look like this:

principal: owner
operation: email.send
purpose:   invoice reminder
to:        contact recorded on the invoice
balance:   up to £2,000
rate:      once per 7 days per invoice
condition: no unresolved dispute

The principal is the person or organisation on whose behalf the action happens. Here, the owner has allowed reminders under specific conditions. The open dispute puts INV-1042 outside those conditions, so the workflow pauses.

An exact approval covers one specified action. If the owner decides to issue a £150 credit note, the approval should identify the invoice and amount:

principal: owner
operation: credit_note.create
invoice:   INV-1042
amount:    £150
status:    waiting for owner approval

A material change requires a new approval. Approval also has to stay within the surrounding system's policy; it cannot override a prohibited action.

Reversibility needs recording separately. A routine email can be covered by delegation even though sending it has effects that cannot be undone. A refund is a further action with its own record. Compensating transactions describe this kind of recovery, where further work may be needed and the original state may not be recoverable.

Knowing where a value came from

Suppose the customer's email asks for future correspondence to go to a new address. The assistant may extract the address perfectly. There is still a decision about whether that address should receive the invoice details.

The action gate needs to know where the proposed recipient came from. The policy might require the contact already recorded on the invoice, or an approved change to that contact. If the email address loses its provenance during extraction, the gate loses information it needs to make that decision.

This is why provenance has to follow values through the work, including after summarisation or other transformations. The CaMeL paper describes an interpreter that tracks dependencies and applies policies when tools are called.

In that design, a separate reader processes untrusted text without access to tools. Its output still needs checking: it can return an attacker-chosen address even though it cannot send an email itself. The runtime maintains the provenance used by the gate. A model's claim that a value is trusted is insufficient.

What belongs in memory

“Memory” covers several different kinds of material. A fact about a customer and an instruction about how to write to them may both survive between sessions, but they need different rules for updating and using them.

I would organise them like this:

Retained material Part
Personal facts and accumulated understanding Knowledge
Behavioural preferences Instructions
Learned procedures Instructions
Open commitments Work state
Historical events and supporting evidence Artifacts

The CoALA paper distinguishes working, semantic, episodic and procedural memory. The table is my mapping of those kinds of responsibilities into this vocabulary.

There is a further decision when an observation or draft becomes something future work should follow. A request to change one reminder should not silently become a rule for every customer. Promoting it to standing Knowledge or Instructions is a write, and in this design it passes through the same action gate.

The gate checks who may make the change and how widely it should apply. That matters because malicious material stored in memory can influence later sessions after the original context has gone. OWASP's Agent Memory Guard project describes that persistence risk.

When the result is uncertain

Consider what happens when the £400 payment arrives. The assistant asks an integration to record it, but the connection times out. The payment may have been recorded before the response was lost.

The next step is to reconcile the result with the accounting system. Retrying immediately could record the payment twice. Until the result is known, the execution state needs to remain uncertain.

Each logical operation should have a durable ID, reused across its retry attempts, and a record of what was attempted. The integration must enforce deduplication for the ID to prevent repeated effects. Temporal's idempotency guide explains the stable-ID pattern and the concurrency problems that can remain around retries.

Provider guarantees also have limits. Stripe API v1, for example, permits pruning keys after they are at least 24 hours old. A workflow that resumes days later still needs its own record of the operation and a way to find out what happened.

For INV-1042, that means the next session can distinguish a confirmed £400 payment from an attempt whose result is still unknown. It can resume from the unresolved question instead of treating the timeout as proof that nothing happened.

References

These sources inform the model. The eight-part vocabulary and the mapping above are my arrangement of the ideas.