Give it one clear responsibility

A responsibility is a result you can review

“Be proactive” is not a job description. “Prepare a Friday list of unresolved customer questions” is a useful starting point because you can see whether it happened and whether it helped.

Choose something you already understand well enough to judge. Starting with your least understood, highest-stakes problem makes it difficult to separate a helpful result from a confident mistake.

Define done before work begins

A practical responsibility has four parts:

• Input: the specific information to review.
• Work: the analysis or preparation to perform.
• Output: the document, table, or recommendation to return.
• Finish line: what should be present, checked, or left unresolved.

For example: “Review these five project notes. List unfinished commitments, their named owner, and any stated deadline. Cite the source note. If an owner or date is missing, write ‘not specified.’ Finish with the three decisions that need my attention.”

This avoids a common failure: a polished summary that never identifies what to do next.

Keep review separate from action

A helper can prepare a response without being authorized to send it. It can suggest a change without applying it. Name those stages separately in the brief so “follow through” does not silently expand into contacting people or changing shared systems.

Our recipes start with review and preparation. They are reusable job descriptions, not separate agents deployed by this website.

Choose a cadence deliberately

“Weekly” is a useful intention, but it needs a day, time zone, source window, and a definition of what counts as new. Begin by requesting one run yourself. Only consider recurring work after you can review a good example.

A cadence written in our builder does not create a schedule or automation. Configure any recurring task separately in the actual product and verify that its timing and notifications match your intention.

Try this now

Complete this sentence:

Review [one small input], prepare [one observable output], and stop before [the next consequential action].

Then write a first test small enough to check every item. Three invented customer records or a single non-production project note is enough. Compare the result with your own assessment before expanding the source set.

Common mistakes

Bundling five jobs together. Separate unrelated outcomes. You will learn more from one complete responsibility than five partial ones.

Using “handle it” as a finish line. Specify what the helper should return and when it should stop.

Making the output uncheckable. Require references, unknowns, and a short explanation for recommendations.

Scaling before reviewing. A successful small test gives you something to improve; it does not prove every future case is safe.

Your next dot

Now decide which actions may proceed and which need you. Continue to Set boundaries before giving more responsibility.