Read-Only, Draft-and-Approve, or Full Access: Pick the Right Level

Start at draft-and-approve for anything a customer reads, and reserve full access for narrow tasks that you have already watched your teammate handle well over time.

What does read-only access genuinely mean?

At read-only, the teammate observes a channel such as a shared inbox, a text line, or a calendar, and it reports what it sees and what it would do. It never sends anything or changes a record on its own, which makes this level a safe place to observe.

Take a contractor who receives requests through a website form and a shared inbox. At read-only, the teammate can produce a morning summary that lists which requests arrived overnight, which ones mention an address, and which ones lack a callback number. Nothing is answered for the customer, so you read the summary and determine what to do next.

That is the point of this level. You see how the teammate's judgment compares with yours on real messages before it touches a customer conversation, and the places where the two readings diverge inform you which rules to write during setup.

The trade-off is that read-only saves you very little time, because you still write every reply yourself. Its value is information rather than labor, so treat it as a short observation period, not a working setup. If a task is already scripted and low risk, a long stretch at read-only only delays the time you get back.

What does draft-and-approve look like in daily use?

At draft-and-approve, the teammate writes the reply, confirms the appointment, or drafts the quote follow-up, and then it waits until a person approves the draft before anything goes out.

Here is an illustrative workflow for a cleaning business. A customer writes, "Can you give me a quote for a spring cleanup?" The teammate sorts the inquiry, notes that the address and the approximate size of the home are missing, and verifies whether the customer attached any photos. It then drafts a reply asking for those details, and a person reads the draft, edits it if needed, and approves it before anything is sent.

The majority of the time savings come from reviewing instead of writing from scratch. You are editing a draft that already has the right structure, the missing questions, and the customer's details in place, and the risk stays low because a weak draft gets caught before a customer ever sees it.

The trade-off is that you still have to be available to approve. If nobody verifies the queue, drafts wait, and a slow queue can make a rapid inquiry feel slow to the customer. Draft-and-approve moves the work from writing to approving, which is a real gain, but it is not a hands-off one.

When does full access make sense?

Full access makes sense for a narrow, repetitive task that you have already reviewed at draft-and-approve and that the teammate handled correctly every time you checked it. At this level, the teammate sends and acts within the scope you defined, without waiting for a click.

A lawn care business is a good example. Appointment confirmations for jobs already on the calendar are low stakes and highly scripted, so a message such as "Your mowing is still set for Tuesday at 9 AM. Reply here if you need to move it" carries little risk. If the customer replies with a change, the teammate can route that reply back to you instead of answering it itself.

Compare that with a request for a discount on a commercial contract. That request involves money, judgment, and a relationship, so it belongs at draft-and-approve or behind a rule that always returns it to you first.

The honest trade-off is that a mistake goes out before anyone catches it. AI can make mistakes, which is why review and explicit limits are part of setup rather than an afterthought. Full access also depends on well-written approval rules, because when the scope is vague, the teammate ends up making judgment calls that should have been your decision. Full access does not fit pricing decisions, refunds, complaints, legal questions, or any task you have not yet watched the teammate handle.

How do the three access levels compare side by side?

Each level adds one step of permission, and the table demonstrates where a person stays in the loop. The last column is the one to verify before you assign any task.

The table is a simplified view, and access level is set per task, so the same teammate can operate at different levels in different workflows. The question to ask honestly is whether a person or a written rule makes the final call before a customer reads the message.

Which access level should you start at?

Start at draft-and-approve for anything a customer reads directly, and utilize read-only first only if you want to observe the teammate's judgment before it writes a single draft. For most small businesses, draft-and-approve is the sensible default, since it keeps a person on every outgoing message while still removing the blank-page work.

Use this sequence to decide:

1. List every task you might hand the teammate, and mark whether a customer reads the output. Anything a customer reads begins at draft-and-approve.
2. Mark tasks that involve money, commitments, complaints, or legal language. These stay at draft-and-approve or return to you first, even after they prove reliable.
3. Mark tasks that are scripted and repetitive, such as confirmations and reminders for jobs already booked. These are the only candidates for full access.
4. Operate the candidates at draft-and-approve across a real stretch of work. Compare each draft with what you would have sent yourself.
5. Move a task to full access only when its drafts have been right and the approval rules name exactly what it may do alone.

The trade-off is that starting narrow and widening is easier than starting wide and pulling back. A business that begins at full access everywhere discovers its mistakes in front of customers, whereas a business that begins at draft-and-approve discovers them in the queue, where each one costs a minute. The price of starting narrow is an extra stretch of reviewing drafts, which is a small one.

This advice does not apply in every case. If you already review every outgoing message by hand and have little volume to offload, the time gain is small at any level, so in that situation choose the level that keeps your review habit intact.

Can you set different access levels for different tasks?

Yes. Access level is set per task rather than as one global switch, so the same teammate can operate at different levels in different workflows.

A lawn care business might set appointment confirmations to full access, because the message is scripted and the job is already on the calendar. It might keep new-customer pricing questions at draft-and-approve, because the answer depends on the property and crew availability. It might keep anything about a complaint at read-only, so the teammate flags it without replying at all.

These decisions happen during setup, which has three stages. Stitch is an intake conversation about how work comes in, which tools you utilize, and where the busywork piles up. Press is go-live, when you write the approval rules that say what the teammate may read, draft, or do alone, and what always comes back to you first. You then observe it handle real examples before anything touches a customer. Mend is ongoing tuning, supported by a client portal that demonstrates what the teammate is doing and why. The full setup flow is described on how it works.

Access levels are decided in Press and change later through human-directed tuning in Mend, and the teammate does not widen its own permissions. A level changes because you decided it should.

The trade-off is that per-task levels mean more rules to write up front. A short list of clearly named tasks is easier to keep right than a long, vague one, and if a task is difficult to describe in a sentence, that is a sign it belongs at draft-and-approve for now.

Does a higher access level make the teammate smarter?

No. Access level is a permission setting, and it does not change how well the teammate understands the work.

Hey Button operates on OpenClaw, an open automation framework, with Hermes as part of the underlying runtime. Models such as Claude and GPT answer through that runtime, depending on the task, and Hey Button does not utilize a proprietary model built from scratch. The same system powers all three access levels, so moving a task from draft-and-approve to full access changes what the teammate may do without asking first, not how it reads the request.

Model routing selects the cheapest model that can still do the job right, and if the first-choice model is slow or unavailable, work can fall back to another capable model. A model switch never changes the teammate's instructions, business facts, or access boundaries, which means routing is a reliability mechanism rather than a permission change.

This is why the access decision belongs to you. A better model will not fix an approval rule that is too loose, because draft quality and access are separate questions, and you should verify each one on its own. For the basics of what an AI teammate is before you choose a level, read What Is an AI Teammate?

Any software subscription or usage charge is identified before you commit, so the access decision is never hidden inside a surprise line item.

How do you move a task between access levels?

You move a task up when its drafts have been right, its edge cases are written down, and its stop rules are clear. You move it down when a draft or action misses in a way the rules did not anticipate.

Verify these criteria before moving a task up, one task at a time:

• The drafts for that task matched what you would have sent across a real operate of examples.
• Every edge case you have seen is named in the approval rules, with what the teammate should do about it.
• The stop rule is explicit. A complaint, a price, a refund, or an unfamiliar request returns to you.
• The client portal demonstrates the teammate's actions on that task, so you can verify them after the fact.

Move a task down when any of these happens:

• A customer received a message you would not have sent.
• The teammate acted on a case the rules should have caught.
• A new kind of request arrived that the rules do not cover.

Moving down is not a failure. It is the setup working as designed, so fix the rule, operate the task at the lower level until the drafts are right again, and then move it back up.

The trade-off is that a full-access task needs scheduled review, not just review when something goes wrong, because otherwise a small drift can operate unnoticed for weeks. When this does not apply, consider a task that changes frequently, such as a seasonal promotion. It may never become stable enough for full access, and that is a good reason to keep it at draft-and-approve.

How should a contractor or law office apply these levels?

Both should start every client-facing task at draft-and-approve, and they should keep anything involving bids, payments, or legal matters out of full access until the teammate has handled those cases many times over.

A contractor might utilize draft-and-approve for quote follow-ups and bid revisions, because each one depends on scope and pricing. Site visit reminders for jobs already booked could move to full access once the drafts have been right for a stretch, and any customer question about a change order should return to the owner before a reply goes out.

A small law office might allow the teammate to organize intake forms and draft a first response for review. Appointment reminders are a candidate for full access once proven, while anything touching a live legal matter should stay at read-only, so the teammate flags it and does not reply. Verify any client-facing wording against your own professional obligations before you approve it.

The trade-off is that these businesses carry more risk per message, so their approval rules need to be stricter. The payoff matches a lawn care business: you stop writing routine replies from scratch and spend your attention on the cases that need it.

Frequently Asked Questions

Can a teammate make or take phone calls at full access? No — Hey Button teammates work through text, email, and forms. Phone calls are not a feature at any access level, so full access only changes what the teammate may send in those channels, not which channels it utilizes.

Is an AI teammate the same thing as an AI employee? No — Hey Button rejects the term AI employee, which implies a fixed role with open-ended autonomy. An AI teammate works inside the access level and approval rules you set for each task, and a person stays in charge of what it may do.

Who approves a draft when I am not available? Typically the draft waits in the queue until you, or whoever you assign to approve, reviews it. Nothing is sent in the meantime, because draft-and-approve never sends a customer message without a person approving it first.

What should go into my approval rules? Start with three groups: what the teammate may do alone, what it may only draft, and what always comes back to you first. Name each task in plain language and add stop words, such as refund or complaint, that trigger a return.

Can I change an access level after setup? Yes — access levels are set per task and can change later. Changes happen through human-directed tuning in the Mend stage, so the teammate never widens its own permissions. Move a task up only after its drafts have been right.

Ready to choose your level task by task? Start the setup questionnaire to select the right access level for each workflow.