Agent assignment guidelines

1. Ask only for one-click sign-ins

Every connection your agent needs should be OAuth (Google, Slack, Notion, HubSpot…) or need no account at all (RSS, public pages, webhooks). Assume the person using your agent is non-technical and does not know what an API key is. If a source offers two paths, take the OAuth one.

2. Questions to ask the user: preferably four or fewer

These are how your agent gathers the context from people which it needs to run. Ask for what the agent genuinely cannot work without as part of the flow, in plain language. Four questions are the max you should aim for, but it can be more if the agent really demands it.

The agent itself can be as deep as the assignment demands — the limit is on questions, not on the flow. See Builder questions for how to select and write them well.

3. Create everything the agent needs yourself

If your agent works off a sheet, folder, or database, do not ask the user to make one. On its first run, the agent should check whether it exists, and if not, create it:

• the exact columns it expects,
• one example row filled in to show the format,
• and a message to the user with the link and a single line on what to add.

From then on, the user only enters data, never structure.

4. Never make people take extra effort, they just won't do it

Users will not do homework for your agent. Take a simple example: an expense tracker that says "upload your bank statement every month." The user does it once, maybe twice, then forgets forever, and the agent goes quiet.

Now it looks like Gravity stopped working, when really the agent was waiting to be fed. The fix is to remove the homework completely. That bank statement already arrives in their Gmail every month. The agent should find it there by itself. Same for receipts, invoices, bookings, job alerts: almost everything an agent needs is already sitting in the user's inbox, calendar, or Drive. Go get it.

Only ask the user to do something repeatedly in two cases: when they get something back immediately (they add a product, listings appear) or when they are simply replying to a question your agent asked. Everything else, the agent fetches on its own. That is what lets it keep running for months without the user lifting a finger.

5. Give it a real trigger

A schedule, an inbox event, a file drop, a new sheet row, a webhook. It should be set up once and never need to be started again. The trigger is what makes it an agent instead of a tool.

6. Make it remember

Each run should save what it did — using the Storage piece, or a hidden tab in its own sheet — so the next run builds on it instead of repeating it. An invoice chaser that forgets it already sent yesterday's reminder spams the client daily. One stored line is the difference between a professional and a spammer.

7. Put approval gates where they belong

Anything that messages a third party or touches money should wait for a one-tap yes. Everything internal (updating sheets, drafting, logging) runs free. Rule 10 covers the approval patterns and when to use each.

8. Check AI-built work before you upload it

Building with Claude or ChatGPT is fine, but treat the output as a first draft, not a finished agent. AI assistants confidently reference pieces that do not exist, misname actions, and invent settings that look right. Before uploading, run the whole flow on real data and watch every step succeed with your own eyes. A workflow that has never had a green end-to-end run is not done, no matter how complete it looks.

9. Never hardcode anything

Anything that changes from user to user (an email address, a sheet, a price, a date) should be a variable that holds the user's own input or a fresh fetch, never a value you typed in while testing. Before uploading, look through your steps for anything specific to you and replace it with a variable.

10. Put approval gates where they belong

An approval is how your agent waits for a human yes before doing something it should not do alone. Anything that messages a third party or touches money should wait for one; everything internal — updating sheets, drafting content, logging — runs free, with no approval needed. The platform holds a paused run for hours or days at no cost, so waiting is always safe. There are four patterns, and picking the right one matters more than any other design choice in your agent.

The four patterns

• Approval email. The Gmail piece (and Outlook, for users who live there) has a Request Approval in Email action: it sends the user an email showing exactly what is about to happen, with Approve and Reject links, and pauses the flow until one is clicked. This is the default pattern. The email must show the actual thing being approved — the full drafted message, the amount, the recipient — never a vague "your agent wants to proceed". For a batch, send one approval email summarizing all of it, not one email per item; ten approval emails a day is how users stop reading approval emails.
• Slack approval. The Slack piece has the same request-approval actions as buttons in a DM or channel, plus a request-action variant with custom buttons for decisions that are not a plain yes or no ("Send now / Skip / Ask me later"). Use it when the user already lives in Slack; otherwise use approval email. Equivalent actions exist for Microsoft Teams, Discord, and Telegram when a bounty's audience lives there.
• Editable draft. Approve and Reject links are binary — the user cannot change the message before it goes. When your bounty says the user tweaks drafts, or the agent learns from edits, do not use an approval email. Create the draft in the user's own Gmail drafts folder instead: they edit and send it themselves, and your agent watches sent mail to see what actually went out. The difference between the draft and the sent version is also your learning signal.
• Reply confirmation. When the agent needs information rather than permission — "did this client pay you?", "which folder do you keep these in?" — it asks by email and reads the reply in the same thread. Write questions a person can answer in one line.

Which pattern when

Rules that apply to every pattern

• An approval that never comes back must not break anything: the run should time out gracefully, remind once at most, and never act as if silence meant yes.
• If your agent supports graduation — routine messages earning auto-send after repeated unedited approvals — graduation applies to one specific approved template, the user switches it on explicitly, and rejections, offers, negative-review replies, and anything involving money can never graduate. The one narrow exception is defined by the bounty catalog itself: post-payment receipts on a once-approved template, only on an exact invoice-and-amount match.

Two things to avoidDo not use

• The piece named "Approval (Legacy)". It is deprecated and marked legacy in the piece catalog. AI assistants building workflows reach for it first because of its name — do not let them. Use the channel-native approval actions above instead.
• The Chat UI trigger (on the Human Input piece). Published agents cannot use it; use the Web Form trigger when a flow needs structured human input at its start.