Skip to main content
This recipe lets your support Agent learn between Sessions. Every night at 03:00 UTC it reads the support Agent’s Sessions it has not processed yet and the current /lessons.md from a Memory store. A Curator Agent returns the updated document, a Model block answers “Are these lessons safe, accurate and free of private data?”, and Yes writes the new version.
The write uses mode: update with the sha256 the read returned, so it never overwrites a version it did not read. When the check says No, the run still ends normally: those Sessions count as processed and their lessons are dropped. Wire the no exit to another block if you want to review them. To retire a document the Curator says no longer holds, add a forget boolean to its output_schema, an If block after save that checks {{lessons.output.forget}}, a read of that document, and a remove block with expected_sha256: "{{<read>.sha256}}". Like the write, the remove refuses when someone changed the document after the read. A store that reviews changes can’t take a remove yet.
The Checkfu CLI and TypeScript SDK are private-alpha artifacts with no self-service public installation channel. Part of this flow is behind a rollout fence; a deployment that has not enabled it refuses the request rather than running it. Confirm capability status before making availability part of your application’s contract.

Before you start

You need:
  • An API key with the admin or root role in CHECKFU_API_KEY.
  • A service account for the Automation to run as (SUPPORT_BOT) and the person who authors it (AUTHOR). An API key is not a person, so a create through an API key names the author.
  • The support Agent whose Sessions are read (SUPPORT_AGENT) and the Curator Agent (CURATOR_AGENT).
  • The Memory store (SUPPORT_MEMORY, a memstore_…) and the Environment the Curator runs in (ENVIRONMENT). When the Workspace has exactly one, delete the environment_id line and leave out ENVIRONMENT.
  • A model routing profile with the key fast-judge, or change route.profile to one you have.
Create /lessons.md in the store once. It can be empty:
The CLI examples use CLI access and the TypeScript examples use the TypeScript SDK.
1

Create the draft

Save the recipe as dreaming.yaml. It is the published dreaming.yaml with created_by_principal_id added:
dreaming.yaml
Keep the auto_… id it returns in AUTOMATION.
2

Grant what it needs

The service account needs observe on the support Agent to see its Sessions, read and write on the Memory store, act_as on the Curator and use_model on the route. GET /v1/automations/{id}/access lists each one with its status:
Grant a missing one with a PermissionAssignment. For example, to let it see the support Agent’s Sessions:
A grant that already exists answers 409.The account sees only the Sessions its grants allow. The recent block reports how many it skipped in skipped.
3

Publish

Testing a draft whose Sessions block reads real Sessions is not available yet, so publish and run it.
The summary names the schedule and the next run, for example “Runs on the schedule 0 3 * * * in UTC; the next run is at 2026-10-29T03:00:00.000Z”.
4

Run it now and read the result

You don’t have to wait for 03:00. A manual run reads the same unprocessed Sessions:
List the runs and their status:
When there are no new Sessions, recent takes its none exit and the run ends there. If the store reviews changes, the save block creates a proposal instead of writing, and its status is proposed.
See Automations for every block and field, and Memory for how stores and proposals work.