Skip to content
CuratorNote Request access
CuratorNote guide

A human-review workflow for notes and AI agents

A useful AI workflow begins with a source note, a bounded task, and a person who remains responsible for the result. This illustrative Kanban pattern makes backlog, active work, review, completion, limitations, and follow-up visible without pretending that an agent can replace accountable judgment.

CuratorNotePublished Updated

Key takeaways

  • A source note defines context and boundaries.
  • Backlog, Doing, Review, and Done make responsibility visible.
  • A human reviewer remains accountable for accepting the result.

Human review is the control point

Human review is not a decorative final checkbox. It is the point where someone compares an output with its instruction, evidence, intended audience, and possible consequences. A workflow should identify that reviewer before work starts and give them enough context to reject or revise the result. If the reviewer cannot see the source record, the task boundary, or the changes an assistant made, a Kanban column labeled Review adds ceremony without adding meaningful control.

The NIST AI Risk Management Framework emphasizes ongoing governance, measurement, and management rather than a one-time declaration that a system is safe. A small-team workflow can apply that idea without becoming bureaucratic. The operator defines what the assistant may do, records known uncertainties, checks output against a clear completion condition, and preserves the decision. CuratorNote's note-centered direction is intended to make those steps visible in the ordinary place where the work already lives.

Notes establish the source record

Start with a note that contains the problem, relevant sources, constraints, and desired form of the result. Separate supplied facts from assumptions and label information that may be stale. The note should be understandable by a future reviewer who did not participate in the original conversation. This discipline improves human collaboration as much as machine assistance. It also creates a stable place to record why a prompt changed or why a tempting output was rejected.

A source record should not automatically expose an entire workspace. Give the task only the context it needs, especially when records contain customer, financial, strategic, or personal material. Scoped context reduces accidental disclosure and helps the reviewer understand what the assistant could reasonably have known. If new evidence appears during the task, add it deliberately and document its origin. A large undifferentiated context window is not a substitute for selecting reliable inputs.

Backlog defines a bounded task

In the Backlog state, write an actionable request with a named owner, review standard, and stopping condition. A task such as research competitors is too broad because nobody can tell when it is finished. A better task identifies the market segment, approved sources, comparison dimensions, date boundary, and required output. It also says what the assistant must not do, such as contacting people, publishing content, or changing production data without additional authorization.

Backlog is also the right place to classify risk. A low-impact internal outline can tolerate a different review process from legal copy, account permissions, or financial decisions. Note dependencies and identify the person who can resolve missing information. If the task relies on current external facts, require source links and dates. If it transforms private records, decide which fields may be included. Clear boundaries make later review faster because deviations become visible instead of debatable.

Doing records the active attempt

Move work to Doing when an assistant or person actually begins. Preserve the instruction, relevant tool actions, source notes, and interim decisions. The goal is not to archive every transient token; it is to retain enough evidence to reconstruct the important path. If the task changes materially, update the source note or create a follow-up rather than silently expanding scope. A visible state should tell collaborators that the request is active and who is expected to act next.

Active work needs interruption rules. An assistant should stop when credentials are missing, sources conflict, a destructive action exceeds authorization, or the output would depend on an unresolved owner decision. It should not disguise the gap with invented specifics. The Kanban record can describe the blocker and return the task to an appropriate queue. This behavior is particularly important for privacy, deployment, or external communication, where a plausible guess may cause a real commitment.

Review tests the result

In Review, compare the output with the original acceptance conditions. Check facts against cited primary sources, inspect changed files, run relevant tests, and look for unrequested scope. Review both the visible result and the boundaries around it: metadata, accessibility, responsive behavior, privacy claims, and failure states can matter as much as the happy path. A reviewer should be able to send precise corrections back to Doing without rewriting the task from memory.

AI output deserves special skepticism when it sounds polished. Fluency can obscure a missing source, invalid inference, or unsupported measurement. The generative-AI profile associated with the NIST framework discusses risks particular to generative systems and reinforces the need for context-sensitive management. A practical reviewer asks what evidence supports the claim, what might have been omitted, how the result fails, and whether a person affected by the decision would receive an understandable explanation.

Done preserves the decision

Move a task to Done only after the responsible person accepts it and required verification passes. Record the final artifact, review decision, relevant test evidence, and any limitations that remain. Completion does not mean the subject can never change. It means the stated scope was satisfied at a specific time. When later evidence invalidates the result, open a new task linked to the original record so the history stays legible.

A useful completion note distinguishes shipped behavior from a roadmap intention. It also avoids promoting a proposed publication date, policy, or external claim before the responsible owner approves it. For deployable software, completion may require a committed revision, artifact checks, and a production smoke test. For content, it may require legal or editorial review. The board should reflect those real gates instead of using Done as a place to hide unresolved work.

Illustrative scenario

Imagine a solo operator preparing a security explainer. The source note lists the current browser storage, authentication, and Worker implementation facts, along with approved public references. The Backlog card requests a plain-language draft, forbids unverified compliance claims, and names the operator as reviewer. During Doing, the assistant maps each statement to code or a source and marks unknown provider and retention details as pending. It stops instead of inventing a controller address.

In Review, the operator checks the draft against current code, tests every route and citation, and verifies every release-sensitive fact against its canonical approval record. Corrections return to Doing with specific evidence. The card reaches Done only when technical checks pass and the owner grants publication approval. If an approval is outstanding, the implementation can remain clearly labeled without treating a built page as an authorized policy. The workflow makes that distinction obvious and remains accurate after approval is recorded.

Roadmap and current limitations

This workflow is illustrative product direction. CuratorNote currently provides the note, authentication, local data, and encrypted-service foundations, but broad autonomous agent orchestration should not be inferred from the diagram. Agent Kanban, richer task assignment, scoped context controls, and review evidence are areas for validation. Exact interaction patterns may change as real operators test whether the board improves understanding or merely adds administration.

Kanban cannot guarantee good judgment, correct sources, safe prompts, or compliant decisions. It cannot prevent a reviewer from approving weak work, and it does not secure plaintext sent to another provider. Complex tasks may need specialized review, separation of duties, or tools beyond a note workspace. Use the product overview, security-model guide, and How it works page to understand the current foundation. Treat every roadmap label as a direction to evaluate, not a feature already delivered.

Release source notes

Current-versus-roadmap claims were checked against the active app route shell, worker routes, README architecture, and the approved SEO launch capability-status contract.

The scenario is explicitly illustrative; it is not evidence that autonomous agent orchestration is generally available in the current alpha.

Sources

Primary and standards-based references used for this guide: